CAN bus data rate mismatch
-
I am unable to connect with my expansion boards right now after trying to increase their CAN data rate. I am not sure what data rate the main board or expansion boards are at right now.
Initially the system was working after the CAN speed change. After the first reset of the main board I have not been able to reestablish contact with the expansion boards. I used M952 to increase the speed since M953 is returning an error that it is not supported.
My main board is running firmware version 3.1.1 and I updated the expansion boards at the same time as the last main board update, but I cannot retrieve their exact firmware version at this time. (both firmware binaries are dated to May 19th)
I'v tried resetting the expansion boards and re-updating the firmware via setting the address to 0 and pressing the reset button (which seemed to work based on LED activity).
I cannot find much info on M952, and even less on M953. I don't know if speed settings are stored on the expansion boards and survive reset, or if speed settings may be stored on the main board.
It's possible the cause for lack of communication is not the data rate, but that is my leading theory based on what happened.
Any thoughts are greatly appreciated!
-
Hi @Mattq4
After the first reset of the main board I have not been able to reestablish contact with the expansion boards
Possibly the reason for this is you did not set the can bus data rate on the main board in config.g?
I'v tried resetting the expansion boards and re-updating the firmware via setting the address to 0 and pressing the reset button (which seemed to work based on LED activity).
I assume when you do that, the normal sequence of the firmware flashing onto the expansion board does not work? What happens with the diag LED? (I also assume you have the expansion board firmware in /sys on the mainboard or Pi)
Have you tried setting the mainboard speed to the new speed you set on the expansion boards and the try the firmware update process on the expansion board
Update the reset procedure should set the data rate on the expansion board back to the default.Separately to that can I ask why you changed the data rate in the first place?
-
Well I haven't found a way to explicitly change the main board data rate in the first place, I think that is done implicitly during a call like M952 B1 A1 S5000. Are you aware of a command that can change the main board data rate? M953 returns a not implemented error and M952 does not accept address 0.
The expansion board's diag LED goes out for a few moments when the reset-button is pressed with the address set to zero. Nothing else happens anywhere in the system. I will say I would expect all the settings to be cleared by a firmware flash, which implies the firmware flashing is not working. but yes I do have the expansion board firmware where it should be.
Separately to that can I ask why you changed the data rate in the first place?
GREAT question. The system had some interesting movement inconsistencies during more complex moves like curves. For example it seemed to move a few mm at a time, stopping in between, like it was making many many small moves. This would happen at speeds the axes could easily accomplish independently. This was improved greatly by reducing the move speed and microstepping factor. So, with no previous CAN experience, I wondered if the CAN bus could be bottlenecking the movement commands. Curiosity killed the cat, I suppose.
Right now I'm working on getting RRF3 to compile/build on my computer. I've found in Canlib where the initialization data rates are assigned. I'm hoping to add different timing parameters for the mainboard that default it to 5Mbit/s. (luckily I know for a fact that's what I set the expansion boards to) If I can just communicate with the expansion boards and set them back to 1Mbit/s I will go back to the official 3.1.1 binary. Kinda of a shot in the dark here lol
@T3P3Tony Thank you so much for your time and thoughts!
-
If you set the expansion board switches to all off (which would be address 0) and reset it, that will reset the CAN bus speed.
M952 should accept address 0. I will check that.
FWIW I do not advise setting the base CAN speed as high as 5Mbit/sec. When we have implemented M953, you will be able to set the FD data rate up to 5Mbit/sec.
-
It looks like a data rate mismatch is likely not the problem. I've reflashed firmware on the main and expansion boards, and isolated the SBC and Duet boards from the printer.
I noticed the "Error: Timeout while waiting for transfer ready pin" was happening frequently on the console around CAN bus timeout errors, so I uploaded a simple config.g that doesn't invoke any expansion boards. I then called something like M950 F2 C"1.io0.out" to force a CAN bus transaction. The "Error: Timeout while waiting for transfer ready pin" happens on every attempt to communicate. Also the diag LED on the main board has its blinking cycle interrupted for about a second when the test M950 is sent.
I remain without communication to my expansion boards. Any information on the CAN bus would greatly appreciated
Thank you guys for everything you've done the Duets are second to none
-
Just deleted the expansion board firmware from the /sys from DWC and attempted to reflash the firmware o the expansion board via the reset button. It failed, reporting the necessary file was not found. When the file was there the firmware flash worked.
This proves the expansion board bootloader (or whatever is running after a reset when the address is set to zero) is able to communicate with the main board over the CAN bus, but not the firmware when allowed to boot with a non zero address.
-
Re-flashing the firmware on the expansion board does not reset the CAN data rate. You need to boot with the switches all off to do that.
-
Yup that's definitely the case. Not sure what I was doing wrong before, maybe cable quality.
Thanks for the input!My initial question that got me into all this remains unanswered. It would be interesting to learn if the CAN bus can be a bottleneck as a hypothetical machine gets more and more motors on expansion/tool boards. There's finite bandwidth, how much machine is too much? Does the microstepping factor and/or feedrate affect bandwidth utilization? I may ask this as a question if I cannot figure it out myself