# \[Canbus\] Debugging MCU lockups **URL:** \ **Category:** General Discussion\ **Created:** [June 9, 2024, 10:28am UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935 "2024-06-09T10:28:13Z")\ **Posts on this page:** 1\ **Showing post:** 21
**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\ **Post date:** [June 10, 2024, 8:23pm UTC](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935/21 "2024-06-10T20:23:10Z")
> [@Viesturz](#): > > Wow, this went south fast. Agreed. @TheFuzzyGiggler and @NAPCAL you need to take a breath. > [@Viesturz](#): > > The canbus transcievers are just dumb differential to ttl signal level convertors, right? They’re “dumb” from the perspective is that they do not have a processor in them. The functionality they provide isn’t trivial. > [@Viesturz](#): > > The protocol itself, including error handling is still in software? Yes. This can be seen in a printer’s `klippy.log` as “bytes\_retransmit” and “bytes\_invalid”. When everything is running tickety-boo (that’s the technical term) these values will be zero. Now, the discussion between @TheFuzzyGiggler and @NAPCAL comes down to how robust the CAN communications are. @TheFuzzyGiggler is right when he says that all “name” brand 3D printer hardware has the correct wiring for successful, robust and reliable CAN communications. However, people, being people and few being experienced electrical engineers, cannot be relied upon to implement the CAN bus wiring in their printers is a best practices way and @NAPCAL is correct in pointing this out. @NAPCAL is also correct in pointing out that quite a few 3D printer products that provide CAN bus interfaces are pretty marginal. We had a discussion on this point a few months back here: > [@U2C Terminal block](https://klipper.discourse.group/t/u2c-terminal-block/13929): > > Basic Information: Printer Model: Creator 3 Conversion MCU / Printerboard: U2C, EBB42, BTT SKR Pro not a klipper issue Does anyone know why when I connected 24 to the green terminal block on the U2C it was creating a short on the 24 power supply? Also, If I have two EBB42 boards connected to the HL and terminate them both, if that should work? I the U2C and EBB42s all configured and working until I just tried to use the green terminals. I even tried powering through the molex connector a… The net result of this conversation is that the BTT U2C has some USB connectors which are labeled as “CAN TX” and “CAN RX” but should **NOT** be wired into the CAN bus. This is not documented and as confusing as all hell. Going back to the original question from @Viesturz could you: Provide the information that you were originally requested when you started a “General Discussion” thread. Printer ttype, host and main controller board along with your `klippy.log`. I’d also recommend that you share some photographs of your CAN wiring - both ends, at the U2C and the toolhead. I strongly agree with @NAPCAL that CAN wiring should consist of premade twisted pair shielded cable (I get the cable with two power conductors so I’m just stringing one cable) that has the shield grounded at one end (ideally at the main controller) AND the wires are kept as short as possible to the connectors. Finally, to maximize the life of the cable and avoid mechanical fatigue problems, fasten down the cable to what it is attached to like: ![2024.02.17 - myke Toolhead Image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/a/a9a4a3b92b6c59ff40943ded4b98c3452ab7dd77.jpeg) ![2024.02.17 - myke Toolhead Image Rear](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/9/9285d0dc813e4cbd9e80c5389ac29f1fc67c00e6.jpeg) --- _[View the full topic](https://klipper.discourse.group/t/canbus-debugging-mcu-lockups/16935)._