Printer Model: Enderwire
MCU / Printerboard: BTT SKR Mini E3 V3, Mellow Fly SB2040
Host / SBC Rpi 3B+
klippy.log
Twice the same print file died in the middle. From the logs it appears that it is a can error.
Printer has been working fine for a few weeks now, and the issue has just surfaced.
klippy (2).log (4.4 MB)
Thought I did. something must have gone wrong. Had to truncate the log since it was too long, and had two print runs in it anyway. Wonder if there is a way to automatically clear the logs, or rename them when you start a new print so that wonāt happen.
.zip the complete file and post the compressed result.
Please do not truncate your klippy.log in any way.
I removed the part that was from the earlier print that didnāt fail.
klippy.zip (851.6 KB)
Timeout with MCU 'SB2040' (eventtime=4847.699175)
Transition to shutdown state: Lost communication with MCU 'SB2040'
I agree, looks like a CAN problem. What is your other node? Termination good? What kind of cable do you use for your CAN connection and how long is this cable?
Im using the cable that came with the FLY SB2040. IIRC I cut in in half as I didnāt need the entire length. Iād guess itās less than a meter long. I measured the termination with an ohmmeter, got 60 ohms (120 ohms at either end. The cable (two thick wires and two thin wires, not twisted) was run through the woven sleeve that came with the Ender-3 on its cables and then was ran through the cable chains.
The other node is the FLY-UTOC-3, and I used the short USB cable that came with it to go to the RPi. I had no problems setting up the CAN bus in software, and the printer was working fine for several months. What seems strange to me is that the log continues after the error report, as if it took a while for the printer to halt after the error.
I saw the problem twice in a row after about an hour of printing each time. The first time it happened, I lost communications with the Rpi (couldnāt even ping its IP address). The second time it happened, I could still access Mainsail from my computer.
BTW, it looks like Iām running Debian 11, but I know the RPi is now up to Debian 12. IIRC I installed Debian first, then installed Klipper from scratch using KAUAH. I havenāt updated Klipper, Iām probably nearly a year behind current.
I found a better cable than the one that came with the SB2040. It will be a RPITA to replace the cable, will have to disassemble much of the printer enclosure to get at the cable chain. At least the cable doesnāt cost an arm and a leg. Since the failure happened after the printer was working perfectly for several months, Itās not likely a software problem. Unless the SB2040 has gone bad, the most likely failure is the cable due to flexture, and I can just replace it.
https://www.aliexpress.us/item/3256805691804620.html?spm=a2g0o.order_list.order_list_main.4.21ef1802EgJr28&gatewayAdapt=glo2usa
Do you use a 32bit or 64bit OS version?
Regarding the cable, I would look for a cable with a twisted pair data connection Debug document for CAN bus wiring - #2 by mykepredko
IIRC I used the 64 bit version. Is there a way to tell from the Linux shell?
Iāve ordered a replacement cable, just in case.
https://www.aliexpress.us/item/3256805691804620.html?spm=a2g0o.order_list.order_list_main.4.21ef1802EgJr28&gatewayAdapt=glo2usa
The one that came with the board set did not have the wires twisted, and I didnāt twist them. The new cable hopefully does have the data pair wires twisted, or at least bonded parallel. Itās also enclosed in a flex jacket which the original wasnāt (though I did put it in a sleeve).
Do you know for sure, that the data lines of the original cable are not twisted?
Well you canāt twist them by yourself, since itās a multi-core cable.
As a cheap alternative, you may use an old Ethernet cable and build your own cable if you have the connectors available. Use one twisted pair for data. Split the remaining 6 wires for power. I.e. 3 wires for 24V and 3 wires for GND.
The cable that came with the SB2020 was 4 separate wires, two thick and two thin, one end crimped onto the 4 pin plug that goes into the board socket. So yeah, it was obviously NOT twisted. I didnāt know the data wires needed to be twisted so I just laced the four wires together in a bundle using dental floss as a lacing cord. I then slipped the woven sleeve left over from the Ender 3 toolhead wiring over the cable to protect it from the cable chain.
The problem with Ethernet cable is that most CAT5-7 cables have solid wire conductors. For a toolhead cable that is constantly moving, you really need stranded wire, otherwise the cable will fail due to metal fatigue eventually. They might make Ethernet cable with stranded wire for use in patch panels where the wires are swapped around often, but the spools of cable sold for house wiring are solid conductor. OTOH, USB cable might be stranded, but I donāt think you can buy raw USB cable, only made up connectors.
The replacement cable I ordered has a vynal covering overit, just like CAT5 or USB cables do. I assume that they are made up with the data wires twisted, and the plug for the SB2040 socket is molded onto the end of the cable. It comes in a 3 meter length (long enough for a Voron 2.4 350x350 sized printer) so I would cut it to length to fit my Enderwire (about 1 meter or so).
Running power through multiple small wires is a bad idea; the three small-gauge wires might handle the current well enough, but if one wire breaks, the full load lands on the remaining two and likely overloads them, creating heat and potentially melting and a fire issue, and if two break you have a āheating elementā in your wiring harness. Briefly. Then you get to replace the whole cable harness and hope nothing else got damaged!
You can get stranded CAT cable; I believe itās classified as CAT7, though Iād have to check that to be sure. The conductors are stranded, and each pair is shielded separately, as is the entire cable bundle, so double-shielded. I bought a 2 meter cable and cut the ends off so I could use the stuff to carry the signal from the ADXL345 on the Y carriage (bed-slinger printer) to the SBC, which takes care of both the movement in the cable chain to the bed, and the long-ish run of signal cable that would otherwise be susceptible to EM interference. That said, itās still a bad idea to run power through multiple wires, each one of which is underrated for the full load should one or more of those conductors go open. In practical terms it does work well enough, but itās a built-in failure point with some fairly drastic consequences should things go sideways, and since itās to be a moving cable, itās more a matter of when than if.
So Iād use the cat-7 ONLY for data, and then add a pair of stranded wire for power, then lace them all together. Iāve just replaced the cable that was in the printer with the fully enclosed cable I ordered. Iāll try running a print without any filament in it just to see if it fails within a few hours. It had crapped out twice in a row within 1.5 hours before. Iāll clear the logs first as well. Hopefully the non-twisted data lines in the cable was the problem.
I didnāt cut the cable short (yet) and itās about 2x longer than needed, so I just coiled up the excess. Specās on CAN bus limit the cable length to 40 meters at 1mbs, and this cable is only 3 meters long! So other than being ugly, I guess the excess length isnāt an issue (the power wires are thick enough).
klippy (4).log (185.2 KB)
Well things have really gone to shit. I replaced the cable, and I got as far as homing everything. The PZ probe is connected to the SB2040 toolhead, and it worked to detect z home. Also, I saw the 2b2040 and hotend temps. Then I tried a bedmesh, and got lots of probe errors. Finally klipper shut down with a total loss of communication with the SB2040.
The CAN bus wiring still looks good, right impedances and voltages on the cable. The following command fails:
klippy-env/bin/python klipper/scripts/canbus_query.py can0
Total 0 uuids found
I wonder if the toolhead board or the USB-CAN board have failed, but I still see the Can-USB board,
$ lsusb
Bus 001 Device 004: ID 1d50:614e OpenMoko, Inc. stm32g0b1xx
Bus 001 Device 006: ID 1d50:606f OpenMoko, Inc. Geschwister Schneider CAN adapter
*Bus 001 Device 005: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC) *
Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Not sure what to do next. Perhaps this wasnāt the cable, but a gradual failure of the SB2040 toolhead board, or the fly UTOC board.
klippy (4).log (185.2 KB)