Finished installing CanBus and hooked up some other odds and ends on my machine, Did my PID tunes, and had my first extrusion of plastic from the hotend. YAY!
Began my first print, and got the error of MCU shutdown, Timer Too Close. I thought it might be related to my can cable, so I replaced it with 3DO’s 4 wire cable. I crimped the pins, Checked with a multimeter they were good connections and connected the drain wire to ground. I even went as far as getting a ferrite choke and putting it around the H/L wires. I’m running the umbillical from the A motor, so Im not sure how to avoid running the can wire next to the A/B stepper wires in the drag chain going to the gantry.
No Change.
Should the ferrite bead be around all 4 conductors of the cable? Just H/L?
What next thing should I check?
I’ve read the advanced troubleshooting, I thought I would try the most simple thing and try to address the can cable. The problem only happens during a print, Heating, Homing, QGL, and meshing are all okay. about 5 to 10 minutes into a print… nope.
If the sd card is dying, how do I know it has a problem? Get a new sd and do fresh installs of everything to it and just see?
I did take a look at the graphing github and saw some spikes and high memory usage, but not entirely sure what those things indicate.
As it stands, I use a headless setup and do not use a webcam. I do not think it is a USB issue, the only device is the U2C.
Where do you recommend placing the beads?
How close is too close? I have the can cable which has the HL in a foil shield, 24v power, and a second foil wrapping all 4 wires
Just looking through the klippy.log and a couple of things jump out at me.
When you do the failing run, it looks like your gcode issues a “T0” and “START_PRINT” command which are not recognized (I don’t know about “T0” but I suspect that “START_PRINT” is supposed to be “PRINT_START”). Can you explain this?
Next, you seem to try and start up again but the CAN connection fails - that looks like a disconnected wire to me.
Then, things upchuck because:
UndefinedError: 'extras.gcode_macro.GetStatusWrapper object' has no attribute 'temperature_sensor raspberry_pi'
Maybe you can explain what is happening here?
It appears you’re using a U2C board - why aren’t you using the CAN driver built into the Manta M8P?
Why would you put a ferrite choke on the cables? I disagree with @EddyMI3D in that they’re always a good idea - they rarely are. They are used for suppressing RF emissions from a cable (most often used by OEMs to ensure their products meet FCC regulations); putting it on the CAN cable will NOT help shield the CAN lines from the motors. Sorry.
If you feel the CAN cable is being influenced by the stepper motors, then I suggest you experiment by running the CAN cable outside the drag chain and then trying to do a print. If you don’t have a problem then put the cable into the drag chain and try again.
I’d suggest you go through the following steps:
Clean up the issues noted above
“Rollover” the klippy.log so that the issues are no longer included there
Run the test with the CAN cable outside the drag chain
Run the test with the CAN cable inside the drag chain
Report the results with the new klippy.log
From there we can figure out the problem with the results of two test cases suggested without any of the issues observed above.
Using Cura, I guess old habits die hard… The T0 comes from the slicer. I think its a “Tool” callout. The reversed order of Print start is just the starting command I copy pasted from a guide that I found for Cura, I hadn’t delved too deeply into it as I can get the print to start if I preheat the hotend before selecting the file to print.
I’ll lose the ferrite. Pronto.
The manta I have is the first gen 1.0. So it does not have the CanBus header on it. If theres a way to use an available port on the 1.0 for can, please let me know and I will GLADLY ditch the U2C.
So… the only way I can get the CAN network to actually be happy and see the ebb36 is… Start my printer, immediately SSH into the CB1, copy paste this command “sudo systemctl restart systemd-networkd”
and then I am able to work with the printer. If I do not issue that command, the printer stays in a startup state FOREVER and eventually errors out that it cannot connect to the ebb36.
The issue with the temp sensor comes from a script for variable skirt fan speeds that I needed to redefine for the CB1 instead. Complete
Usually near the connectors of the cables that can emit RF like stepper motor cables and those to the heaters (due to PWM). @mykepredko is correct there.
Shielding is also important. Ive seen Ethernet cables used for CAN wiring where every cable pair is shielded. (CAT 7)
While what Eddy and Myke are saying is very true and is the “right” way to do things, CAN bus is surprisingly tolerant of wiring as long as you’re not using something like a lamp cord.
For example, I’m using some 24 awg wire that I twisted by hand so is definitely not per the “equal number of twists per unit measure” standard but it’s worked fine for me for over a year and I’m running 7 CAN Bus boards (7 is a recent thing, was running 3).
I get zero timer faults and the only ones I have had were a result of poor crimping on my part.
I don’t say this as a “It doesn’t honestly matter” statement, if you’re going to do it and you have the right tools/wiring, 100% do it right.
I say it as more of a “Don’t spend your life trying to perfect the wiring when that’s not actually the issue”. CAN bus wiring is very tolerant, it doesn’t have to be PERFECT or it WILL NOT WORK. It has a large wiggle room.
99.99999% of my issues with CAN Bus has been bad crimps
Learned the actual details of crimping Molex Mini/Micro Fit Jr connectors (there is a little portion at the front that looks like it is supposed to be crimped but it is NOT)
(I’m not actually affiliated with Engineer Tools, they’re just Japanese made and SOOOOOOOOOOO much better than the crappy cheapest Chinese made tools. They actually put THOUGHT into the tool and the design is awesome, highly recommended. I’ll give equal shout outs to any well made tool.)
And for reference to the little part on the Molex pin…
Errors out with the Can cable in AND out of the cable track. klippy (10).log (1.3 MB)
It seems to be erroring sooner than it was before, first layer now where as it would get 5-10 layers in before popping error screen
Mr. Giggler,
Well the only reason I started with the cable, is because I felt it was the easiest place to start troubleshooting… my original cable was some cat 6 and silicone 20g wire. These errors happened, So I bought a wire that… looked like it was an easy solution to making it.
I’d say my crimping skills are on par for a task like this. Tug test every crimp, and verify with my multimeter. I used some tiny pliers to tug on each wire after putting them all into the molex connectors.
I used to build encoder cables for CNC machines with 24 wire serial connections. Tiny wires, with heatshrink around each, the braid soldered nicely to a ground wire and all capped off with heat shrink to put the chef’s kiss on it.
No doubt I want a set of some Japanese crimp tools, I am trying to make due with what I have before spending on Ferrari status tools. Trust me though…there is a burning want for them.
I’m starting to think my issue with canbus is in something else. I had to use a mix of guides to get mine to work. Between CANBUS TOOLHEAD INSTALL | klipper_canbus and https://www.youtube.com/watch?v=N9FpPlgPhpY&ab_channel=TheVoronModder.
I especially had issues with my can network not showing up, and so I used Mazor’s guide for networking issues systemd-networkd | klipper_canbus.
This guide is how I am able to get my CAN0 to even start, otherwise when I boot up the machine can0 does not start unless I “restart the stack”
Then everything shows up and communications with the ebb36 work.
I know it doesn’t sound like it, but this is good news. You’ve eliminated running the CAN cable by the stepper motor lines as a possible cause and it is failing consistently.
Now, looking at your klippy.log, I have two questions for you:
In your printer.cfg you have the statement:
[mcu CB1]
serial = /tmp/klipper_host_mcu
I don’t think I’ve ever seen this before and, as far as I know, it’s not necessary. What are you trying to accomplish with this?
Twenty five seconds before the “Timer Too Close”, I see the error:
b'Got error -1 in can write: (105)No buffer space available'
b'Got error -1 in can write: (105)No buffer space available'
b'Got error -1 in can write: (105)No buffer space available'
b'Got error -1 in can write: (105)No buffer space available'
b'Got error -1 in can write: (105)No buffer space available'
b'Got error -1 in can write: (105)No buffer space available'
I have a feeling Linux is filling up it’s CAN buffer for whatever reason and by the time it gets through it to get a signal to the EBB board it’s out of time sync with the Pi and you get the “timer too close” error.
I see Myke asked you about your
/etc/network/interfaces.d/can0
You said you had issues with that? This is the next critical step.
I’m thinking the error isn’t wiring/CAN board, It’s your setup on the Pi.
Your /etc/network… should look something like this…
Also, You’re good regarding the cable, mainly meant don’t spend your life on getting it perfect just to test it. It’s not THAT critical but it sounds like we got that out of the way anyways.
And having a nice crimp tool is definitely a luxury but not totally necessery, I got mine like two months ago so I used worse ones for yeaaaaaaaaaaaaaaars. It’ll be there for when you decide to splurge one day.
Okay, sudo nano /etc/network/interfaces.d/can0 gives: Its easier to copy paste vs screenshot sorry:
allow-hotplug can0
Iface can0 can static
Bitrate 1000000
up ifconfig $IFACE txqueuelen 1024
pre-up ip link set can0 type can bitrate 1000000
pre-up ip link set can0 txqueuelen 1024
I notice Giggler’s pre-up lines are indented… Do I need to update mine to match?
You are correct there are no pins used for the host MCU as I defined that pre-emptively. It was one of those… add it and be able to define pins as needed. Same thing with the exclude object module, I added it from following a guide because Cura has object identification on by default.
Now, correct me if I am wrong, but shouldn’t the CAN0 load by default? If I do
ip addr
I get a list of networks and CAN0 shows a state of down.
If I use sudo systemctl restart systemd-networkd
Then the status will change to UP and reads:
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
That link you sent says not to have a queue longer than 128, Following the guide, they all show 1024, If I shorten this, will I need to reflash my ebb36 to reflect the change?
The second thing I see from the klipper documentation says the “qlen 10” is reporting that my device was not set up properly.
You know what, I didn’t even notice and I’m the one that linked you the guide.
I’ve honestly never had an issue with 1024. You do not have to reflash if you change it, 1024 is just the buffer size in Linux. You might change to 128 and reboot your Pi and see, you can always change it back.
As for the indent, I don’t BELIEVE it matters, I’m fairly certain it’s parsed line by line. But I’m no Linux expert.
and if yours is showing qlen 10 and you have qlen 1024 in your config, something is off somewhere.
Can I sugegest you us the “</>” option for formatting, so what you put in looks like:
allow-hotplug can0
Iface can0 can static
Bitrate 1000000
up ifconfig $IFACE txqueuelen 1024
pre-up ip link set can0 type can bitrate 1000000
pre-up ip link set can0 txqueuelen 1024
I believe they have to be. Could you try indenting them and rebooting and see what happens?
No worries. When I review somebody’s printer.cfg in the klippy.log, I tend to ask about everything that doesn’t make sense.
Personally, I would suggest losing the EXCLUDE_OBJECT and try to keep everything as simple as possible (especially when you’re first bringing up the system).
Looks right, when I check it on one of my systems, I get:
12: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 256
link/can
I wonder about your qlen as well. That’s strange it shows up as 10 rather than 1024. You can see that I use a queue length of 256 without any issues.
