Duet 3 fails to coordinate motor motion with exp boards

TechNi

Hey all,

I have had some problems with weird motion patterns of my print heads (IDEX printer). The printer does not lose any steps, in fact at the end of the G-code the print head is exactly where it is supposed to be. However, it fails to execute two axis movements at the same time if the motors are connected on different boards. For example in case of the following zigzag movement:

G91											; Relative mode
G1 F{global.defaultFastSpeed}				; Set movement speed
G1 X-30 Y-5
G1 X30 Y-5
G1 X-30	Y-5
G1 X30 Y-5
G1 X-30 Y-5
G1 X30 Y-5
G1 X-30
G90

instead of moving X and Y together, it moves first X and then Y. In addition, since in my case I am using Markforged kinematics, it does not execute X movement properly because the Y carriage moves as well (in order to do the X movement, you need to turn multiple motors synchronously which currently it does not). Note that this is only the case in fast executing consecutive G-code. Single movements work just fine.

So the motors are not turning when they should. I've had the same issue with both expansion board 1 and 2 and also with the other print head. I could solve the issue for this print head by simply connecting the motors to the same board (the main board). However, the extruder motor is still connected to an expansion board and if I want to extrude only (e.g. G1 E20 F300), it does not wait until the extrusion is complete but already continues with the rest of the G-code while the print head is still extruding.

Interesting thing is that if I put "G4 S1" between each movement line of the zigzag code in order to wait a sec, it executes every movement correctly. Hence, I suspect this is some kind of data transfer or CAN communication problem? There are no problems with fans or sensors connected to the expansion boards.

I use RRF 3.3 and Bootloader 2.3 on all boards and use an SBC.

dc42

@techni please try upgrading the main board firmware to 3.4.0beta2. You can leave the expansion board firmware at 3.3. If the problem persists, please execute those movements, then get M122 reports for all the boards and post them here. Also post your config.g file.

TechNi

@dc42 I followed the advice and tried to upgrade to 3.4b2 via the DWC. However, after 15+ mins the installation process still wasn't completed. I checked the PanelDue and it said it is stuck at 60% of the installation process. I had no choice but to reboot the printer and now nothing works anymore of course. Can still connect to the Raspberry, but DWC does not work anymore, at least not over LAN.

dc42

@techni if you have an attached SBC then when switching between major versions (and sometimes between minor versions too) you must always upgrade via the package server. If you now switch to using the unstable feed from the package server, you should be able to upgrade DCS to 3.4.0b2 and restore communication.

TechNi

@dc42 Please elaborate a bit more, I am really not good when it comes to Linux stuff.

I formatted the SD card of the Pi hoping to get back to RRF3.3 and while I can communicate with the Pi, I am still getting the same error as before the formatting when accessing Duet Web Control:

Executing

journalctl -fu duetcontrolserver

gives me the following results

dc42

@techni to restore communication you will need to either upgrade DCS on the Pi to 3.4.0b2, or downgrade RRF to 3.3 using Bossa or by switching to standalone mode.

See https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide for how to switch to the unstable (beta) package feed and update tko the beta release.

TechNi

@dc42 @dc42 I finally managed to update the main board to RRF 3.4b2 and the issue seems to be fixed. Thanks! I will do some further tests just to be sure.

dc42

@techni thanks for confirming.