[3.6.0-rc.2] M596 Multiple Motion Systems

davidjryan

My setup:
1 6HC - @ 3.6.0-rc.2 (was 3.5.4)
3 3HC - all @ 3.6.0-rc.2 (was 3.5.4)
System has 13 stepper axes across the 4 boards (X, Y, Z, A, B, C, D, W, a, b, d, e, f)
System is set to CNC mode M453. This is a non-printer application
RPi 4, 4GB in SBC mode

I'm still having trouble getting multiple motion system to work again. Everything is fine in 3.5.4. Ever since 3.6.x, it has stopped working.

It seems the Duet will not release multiple motion axes after moves are complete. The DWC always reports out:
Error: in file macro line 18: G1: Drive A is already used by a different motion system
when trying to move an axis in a new motion system that it wasn't previously attached to.

I've got a test board set up with 2 axes and I'm running a very simple motion test.

config.g

; General preferences
M453                                                        ; set CNC mode
M550 P"A2000-xx"                                            ; set name of controller
G90                                                         ; set absolute coordinates
G4 P1000                                                    ; 1s delay for CAN comms

; Drives
; Motors are wired to Duet A-A, B-B - motor directions are flipped here
M569 P0.0 S0                                                ; physical drive 0.0 goes forward
M569 P0.2 S0                                                ; physical drive 0.1 goes forward

; Set motion system queue parameters
M595 P100 R50 Q0                                            ; set motion system queue 0 to 100 steps
M595 P100 R50 Q1                                            ; set motion system queue 1 to 100 steps

; Set drive mapping
M584 X0.0 R0                                           ; set linear drive mapping for gantry
M584 A0.2 R0                                           ; set linear drive mapping for gantry

; Set microstepping interpolation
M350 X16 A16 I1                 ; configure microstepping with interpolation for linear motors

; Set axes scale values
M92 X250 A250         ; set steps per mm

; Set max speed change values
M566 X400.00 A400.00        ; set maximum instantaneous speed changes (mm/min)

; Set max speeds
M203 X10000.00 A10000.00        ; set maximum speeds (mm/min)

; Set accelerations
M201 X3000.00 A3000.00                 ; set accelerations (mm/s^2)

; Set motor currents and idle factor
M906 X2000 A2000 I5                                   ; set motor currents (mA) and motor idle factor in per cent

; Axis Limits - minimum
M208 X-200 A-200 S1                                       ; set linear axis minimum

; Axis Limits - maximum
M208 X1000 A1000 S0                                   ; set linear axis maximum

Test program:

M400
M598
M596 P1
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000

M400
M598
M596 P1
G90 G1 A0 F2000

M596 P0
G90 G1 X0 F3000

M400
M598
M596 P0
G90 G1 X100 A100 F2000

When I run the program, X goes to 100mm and A goes to 200mm, both starting pretty much at the same time but stopping at different times because of the feed rates.

X and A then return to 0mm, again, starting pretty much simultaneously, but stopping at different times because of the feed rates. All expected behavior.

When the system tries to add axis A back to motion system 0 on line 20, I get:

and the program stops so axis X nor axis A move to 100mm.

I didn't see any change in the documentation for coding multiple motion systems, so let me know if I am using the M595, M596, and M598 incorrectly.

I am able to run any desired test pretty quickly on my test board so let me know if there is anything else I can do to help debug the issue.

dc42

@davidjryan does it help if you add another M400 command at line 13, to release the A axis while you still have motion system 1 selected?

davidjryan

@dc42 now that worked but it also caused axis X to wait until A finished it's move to 0mm before axis X started it's move to 0mm.

Macro:

M400
M598
M596 P1
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000

M400
M598
M596 P1
G90 G1 A0 F2000

M400

M596 P0
G90 G1 X0 F3000

M400
M598
M596 P0
G90 G1 X100 A100 F2000

But........

Following your logic... if I do this, it works as desired:

M598
M596 P0
G90 G1 X0 A0 F2000

M400
M598
M596 P1
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000

M400
M596 P1
G90 G1 A0 F2000

M596 P0
G90 G1 X0 F3000

M596 P1
M400

M598
M596 P0
G90 G1 X100 A100 F2000
G90 G1 X0 A0 F4000
M400
M598

So I switch back to P1 after starting P0 on it's move to 0mm and issue M400. Once all axes are stopped, issue M598, then go back to P0 and add axis A back in. In all of the instances where I use multiple motion systems, I know if P0 will finish before P1 or vice-versa, so I can add this workaround to my macros.

I'll upgrade one of my runtime systems to 3.6.0-RC2 in the next day or so to see if the code change will solve the issue.

Will we get back to where M400 waits for both motion systems to stop, and then M598 will release the axes?

dc42

@davidjryan it appears to me that it might be useful to have a variant of M400 that only waits for the current motion system to stop (and releases axes).

davidjryan

@dc42 But as is stands, M400 waits for both motions systems to stop motion and also prevents one from loading up the second motion system with moves to be executed independent of the first motion system. Could M598 be a "wait for all motion systems to stop and then release axes"? Per the description in the documentation, that's what it should do, but it doesn't unless you wrap some M400's around it.

As you suggest, if M400 was a wait just for that motion system and the processor kept reading code to allow moves in the other motions system, that could work. We would just need a list of G/M codes that stop the processor from further reading code to be processed by the second motion system. I.e., a G4 Px does the same thing as M400 if it's in M598 P0 or P1; further processing stops until the wait is over, then it continues.

I hope to get to my testing today.

davidjryan

@dc42 I can confirm 3.6.0-rc2 multiple motion system works with the code adjustments.

dwuk3d

Not sure if I have quite understood what you are trying to do with the M400's, but in my multiple motion system macros (which I am still learning) I have tended to do the following.

At the start of the print avoid using multiple motion systems for things like homing. - I run the below ClearAllocs.g macro
Before starting the print release all of the axis from any motion systems they are allocated to by doing the ClearAllocs.g macro

;ClearAllocs.g
;echo "ClearAllocs.g"
M400
M596 P0
T-1
M400
M596 P1
T-1
M400
M596 P0

At the start of the print I then do a

M606 S1 ; Fork Input File reader - for parallel printing

I then use M596 P0, T1, G1 U V..., M596 P1, T0, G1 X Y..., M598. - i.e. No M400's
Then at the end before shutting everything off I do my ClearAllocs.g macro again.

This all worked with 3.5.4, but stopped working for 3.6.0 until the recent fix which seems to now be releasing the motion systems.

PS/ I am working on a new version of M596 that can be used in all of my Macro's - which optionally ignores the motion system switches when not needed - something like this.

;M596.1,g
;M596.1 P-1  ; Ignore M596.1 commands until P-2

if exists(global.M596_stat) == false
    global M596_stat = -2
    
if exists(param.P)
    if param.P < 0
        set global.M596_stat = param.P
    else
        if global.M596_stat == -2
            M596 P{param.P}

droftarts

@davidjryan If your 2nd motion system commands start getting longer, you may need to include M606 S1 to enable the job/macro file to be read by the motion systems separately. Without this, the two motion systems share the primary queue, so one motion system may be starved of commands until the other motion system has processed commands. From the 3.5.1 update notes https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-351-stable-changes-since-346 :

[Duet 3] When processing job files, commands for both motion systems are now processed by the primary file stream by default. The secondary file stream is only activated if the M606 command is used, which can be done in the job file or in the start.g.file. When the job completes the secondary file stream is closed and commands in the stop.g file for both motion systems are executed by the primary stream.
[Duet 3] New M606 command supported to fork the input stream when running a job from SD card. This command must be used in the job file if you want the second input stream to execute commands for the second movement system; otherwise commands for both movement system are executed by the primary file stream.

Ian