[Canbus] Debugging MCU lockups

[mykepredko]

@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

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:

[NAPCAL]

NAPCAL](/u/napcal) you need to take a breath.

Here is the wiring diagram I worked up on the BTT U2C

The small white connectors are TTL connections for boards like Arduino, STM boards, and others alike.

[TheFuzzyGiggler]

@mykepredko

Agreed. @TheFuzzyGiggler and @NAPCAL you need to take a breath.

Apologies to all, I didn’t mean to come across as arguing. Just wanted to be clear on distinctions between different implementations because like Myke said… In the 3D printing world it’s the wild west as there are no “standards”. The devil is always in the details.

Plus the line between what is “correct” and what “works” is sometimes verrrrry thin. You can get away with a lot of things, it usually just comes down to how long you can get away with it.

But moving on…

@mykepredko

I strongly agree with @NAPCAL that CAN wiring should consist of premade twisted pair shielded cable

Any recommendations for a good cable? I have twisted pair that I hand twisted (horrible I know, especially since I was just talking about standards). It’s worked solidly so far for 7 CAN bus Toolheads @ 1Mbit/s connection. But again… Like I said above… I’m probably just biding my time until issues.

@Viesturz

@Viesturz

The canbus transcievers are just dumb differential to ttl signal level convertors, right?
The protocol itself, including error handling is still in software?

Easiest to just quote TI:

The role of the transceiver is simply to drive and detect data to and from the bus. It converts the single-ended
logic used by the controller to the differential signal transmitted over the bus. It also determines the bus logic
state from the differential voltage, rejects the common-mode noise, and outputs a single-ended logic signal to
the controller. Additionally, many transceivers provide features to isolate the controller from bus conditions such
as electrostatic discharge (ESD) or electrical over-stress (EOS) damage, so that a node would be protected if an
extreme bus condition were to destroy the transceiver.

It also does do some error handling/checking internally outside of the checks in the data side of the protocol.

A rough analogy would be that… The MCU is writing a letter, the transceiver(s) are the Post Office (or your countries equivalent). The transceiver doesn’t need to know how to talk, only how to get the messages in and out.

I guess a better example would be one of the radio operators you see in old WW2 War films, where someone hands them an encoded message and they send it out via morse code. They don’t know what the message says, but they know how to send it and receive others.

They work in tandem and both are needed to actually be considered a CAN node.

[NAPCAL]

For the cables try chainflex® flexible cables for movement | igus®

ChainFlex for umbilical cables.

[mykepredko]

Thank you for making sense of the BTT (and Fly and…), or at least as much sense as can be made of the boards.

However, I think you’ve made a mistake in your drawing. You’re implying that the white connectors have the same signals as the USB A “MCU #” connectors:

But, when I look at the schematics (and I just beeped out one of the boards I have to confirm) they are actually in line with the CAN bus on the bottom of your diagram:

As I said above, you are clearing things up a bit more with your diagram - although I’m still not sure of the use case with the double USB A connector.

From what I can tell, the board provides a single CAN bus for up to three external non-CAN devices. The first non-CAN device communicates through USB C to an STM32 MCU to the CAN bus and the two bastardized USB A connectors provide a serial interface for another device serial data to the single CAN bus.

The single CAN bus has a variety of IO connectors consisting of a screw terminal, two different sized MicroFit connectors, four set of header pins and the two white connectors.

Maybe you can explain why three of the sets of connectors have 120Ω terminating resistors in them when only one is required.

[mykepredko]

I use Tensility 30-2482 (Available at Digi-Key).

The 28 AWG twisted pair impedance is 100Ω which is off by a bit but when you’re talking a metre or so for the cable length it’s fine. The 22 AWG power lines are perfect for the current drawn by a toolhead heater and stepper.

[NAPCAL]

Update: old man who was wrong on the white connectors, sorry @mykepredko

My diagram is via an ohm meter, not the schematics. BTT is known for errors in its schematics.

Example: the GTR’s diag jumpers only connect to the end-stop connectors, but not the driver sockets diag on the other side of the jumper; the end-stops and driver diag are connected so the jumpers were unless. I found this when creating my own schematics since BTT wasn’t releasing the official one.

Here are the schematics I created.
BigTreeTech GTR V1.0

[mykepredko]

As I said, I used an Ohmmeter on my board as well (this is what I meant when I said “beeped out” the lines). I did that because the white connectors have “H L V 5G” on the bottom side silkscreen directly underneath them and it didn’t seem to connect with your block diagram of the board.

I just checked it again - my board mostly matches the schematic. I say “mostly” because there isn’t a straight 5 pin SWD connector, there is a set of 3x2 vias that seems to perform the same function.

If I look back at the schematics with the “VBUS 1” and “VBUS 2”, the way you’ve drawn them it makes the most sense (allowing users to connect through the JST connectors instead of miswired USB) but that’s not what I’m seeing on the physical board or on their schematics.

[NAPCAL]

I’m sorry. You’re right about the white connectors. It’s been a long time; there are too many boards, and I am getting old. I will revise the connection drawing.

I haven’t been called out on them since no one uses them, but the CAN_H, CAN_L, and ground could be used without the 5V from boards like SKR3 and the boards that use CB1/CM4.

[NAPCAL]

The Dropbox link to the U2C connections should be updated with the corrected white connectors connections.

Note: don’t provide 5V to these white connectors since it will power up one of the board CAN bus transceivers. Also, if the Vbus jumper is used then 5V from the USB-C will be provided at the white connector.

[mykepredko]

Looks good - thank you for providing that.

[NAPCAL]

Thanks for that find on the cable.
Are you using it as umbilical, if so how is it holding up?

I wish igus had that AWG in their ChainFlex line.

[mykepredko]

It’s on four printers right now, each with over 2k hours of printing time with no issues at all.