Nothing in that software even knows how many nodes are connected. Canbus doesn’t work like ethernet - there is no arp or global identification system - 10 messages from 10 different nodes is indistinguishable from 10 messages from a single node at that layer.
If I understand your previous message, wiring 3 toolheads causes the system to stop operating - even if there is no configuration for those nodes in the software. FWIW, this basically rules out the software, because the software doesn’t know about the existence of those nodes unless you configure them.
If I misunderstood your previous message, then I suggest running that test: wire up all 4 toolheads, but don’t configure two of them in the printer.cfg file. You can also try wiring all 4 toolheads, not configuring them and not applying power to them.
Separately, on the software side, you might want to double check that the canbus_query.py tool isn’t being run inadvertently as mentioned at CANBUS Troubleshooting - Klipper documentation .
Finally, there are some things I’d test if I was having a similar issue:
I’d try attaching an oscilliscope to the canh and canl wires. A differential probe is not needed, as in practice the voltage swings are identifiable by eye. I’d look for changes between the working 2 toolhead case and the non-working 3 toolhead case. In particular I’d look at the absolute voltage swing, amount of ringing, and the rise/fall times. If a 2-channel oscilloscope isn’t readily available, I’d try hooking up a $10 logic analyzer to the can_rx/tx wires of one of the nodes - it won’t have as much info as an oscilloscope but it can still provide an independent validation on message traffic.
I’d try temporarily wiring all the nodes without a “hub” - I’d try a simple “daisy chaining” of the canh/canl wires with terminating resistors at the ends of that chain. A “hub” in general is not the recommended wiring for canbus, and although I’m sure it can work, I’d verify the simpler wiring if I was having issues with it.
Kevin, thank you.
Yes, you understood correctly, having three or more SB2209 on the bus causes it to crash independently of having them all configured in printer.cfg or just one or two. I mean if I only have this in printer.cfg
[mcu ebb0]
canbus_uuid = 410ab0ed9fb3
the bus will still crash if there were other two or three heads besides that one connected. You say this rules out the SW because it is not even aware of these nodes, I understand that by “the software” you mean Klipper. But being you the developer of can2040 do you think that assertions like the one I made regarding the limited handling of CAN bus error protocols or some subtle timing issue are valid concerns that could be in play here? Also, are you aware and could you point me to any working configuration of more than two rp2040 powered nodes using can2040 on the same bus?
I’m not running canbus_query.py on any startup script or anything of the sorts, I only used it to get the UUID and used those UUIDs to flash the toolhead boards and configure the printer. I saved them in a text file and I’ve had not run the query again.
I have a decent Rigol DHO814 oscilloscope and will try to take some measurements to see if there is evidence of what you suggest.
Finally a “hub” may not be the best name to describe the topology of Isik’s tech MOAR_CAN or my attempt at one. It is a device that simplifies connecting the devices on a bus configuration but it definitely is CAN bus compliant. The manual explains it quite well.
I forgot to add that I haven’t tested nodes in circuit but not powered up. They use a single connector with power and CAN bus together at both ends, so it’s cumbersome to separate power and data. Do you really think it could add something valuable to the analysis?
I’m not aware of anything that could cause an issue like that. As before, can2040 has no way of knowing how many mcus are on the bus.
It’s certainly possible that bit timing, reflections, line noise, improper impedance, resistance, etc. could make the line unusable to can2040. That just brings us back to concerns with wiring though.
That’s not something I’ve tracked. The rp2040 is a very popular toolhead mcu and can2040 is also used in other projects (like model trains). I’ve not seen reports like this before.
It’s notably more complicated than traditional wiring. If it was me, I’d reproduce the problem with very simple wiring.
You’ll need to make the call on what’s worthwhile to test. As I said earlier, I do not know what the root cause of your issue is - I can only make general suggestions.
Hi, I have been a little busier than usual. I had a little time to make a few tests now but I won’t be able to do more at this moment. I started with the very basic tests Kevin suggested in his first reply. I rechecked very thoroughly the termination resistors, I measured at the resistors themselves, at the beginning and end of bus and also at each toolhead it reads 60.2 Ohms +/- .2 . I also tried lowering the bus speed to 100K to make completely sure the speed was not the cause. The system behaved the same way I’ve been reporting all the time, two heads on the bus work fine, three or more fail. I don’t have the time at the moment but I will try connecting the heads together in bus configuration without the hub and also probe with the scope and I’ll report the results. Once again thanks to all.
Hi, more news, good ones this time. Without making any changes to the last tried configuration (ucan controller, 100K speed, same HUB, same wiring, etc). I connected and configured second CAN bus controller to Raspberry Pi. For the first two heads I left them as they were, I split the moar_can by not jumpering an empty place and putting an extra terminating resistor at the end of the first segment. Then connected the second controller CAN to the second half of moar_can and heads 3 & 4 on this section too together with the terminating resistor of moar_can itself. I haven’t done real world test yet, but Klipper boots correctly and shows all head boards ready. I’d really appreciate your input on this news. What does it really show about the previous behaviour? Should I just up the bitrate and try it for real? Should I do some specific tests first like trying to power fans, heaters, extruders by themselves? Should I keep at it trying to fix the all heads in one bus issue? If so, how?
Double wires to each node (except the “master” and no branching (except the toolboard trace to the transceiver. The second resistor is at the extreme end of the bus.
His functioning arrangement has the 2nd CAN adapter as node 4 (terminated) below.
Quite good thanks. Segment 1: Node 1 would be UCAN, node 2 head 1 and node 3 head 2. Segment 2: Node 4 would be U2C (terminated), node 5 head 3 and node 6 head 4
thnx, yes I think it is. After so much time debugging this setup I do know how a CAN bus is supposed to be wired. What makes no sense to me is that if you were to keep everything the same, and just remove the second can adapter (U2C) in CAN4 and the resistor in CAN3 position while jumpering CAN3 and CAN4 it won’t work!
Hi, I kept thinking about the issue and weighing all the evidence from my own tests and measurements and all the great info from all your replies. After my test with two CAN bus adapters on the Pi I decided there was no way my wiring was bad or my hub was bad or my sw config was bad and by some chance it worked everytime I had less than two can2040 devices on one bus. So I bought 4 ebb sb2209 stm32 boards, they arrived during the week and yesterday late at night I was able to flash Katapult and Klipper on all of them and started replacing the rp2040 versions with the stm32 versions. I only tried the same two buses, two devices per bus at 100,000 config and it worked the same with the new boards. I’ve just now removed one termination resistor and jumpered empty positions on the hub so all 4 heads are on the same bus and it works - the same configuration on my previous post diagram where rp2040 boards didn’t work. I still have to up the bandwidth and test real commands to the heads, i.e. finish configuring Stealthchanger, but I’m on a platform that looks much more promising than before. No intention to disparage can2040 or rp2040 based HW but it seems that they’re just not suited for a configuration like mine. Thanks for the help.
