@jay_s_uk I do. I'll turn it off and try it in a couple hours.
Latest posts made by Mattq4
-
RE: Stuttered movement at high speed on CAN bus axes
-
Stuttered movement at high speed on CAN bus axes
My machine has two X motors and one Y motor driven by drivers on expansion boards, EXP3HC's. When I request it to move on these axes at high-ish speeds, like 250 mm/s, it does not execute the move smoothly. Instead, it appears to slow down every several dozens of mm and speed back up.
I have worked on isolating the issue, and I can conclude it is definitely not missing steps. For one the total distance is always correct, and it does not make the sound of missed steps. The problem is also not caused by the system not being able to interpret gcodes fast enough, as the problem can easily be reproduced by a single G1 command on one axis.
My hunch right now is that the movement segments aren't getting communicated through the CAN bus fast enough, so expansion boards decide to slow down as the get through the move queue they have already received, until more segments get through.
Any thoughts? How can I make the machine run smoother at high speeds, or have I reached the limit? On previous firmware builds (like 3.2) it has achieved these speeds, and faster, no problem. The machine is cranking out prints successfully but I think there is an opportunity for improvement of print quality here.
-
RE: CAN bus data rate mismatch
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
-
RE: CAN bus data rate mismatch
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: CAN bus data rate mismatch
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
-
RE: CAN bus data rate mismatch
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!
-
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!