[3.6.0-rc.2] M596 Multiple Motion Systems

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

davidjryan

@droftarts @dwuk3d

Well, holy fork!

I totally missed the addition of the M606 command in the firmware changelogs. I'll give the above suggestions a shot.

As usual, self-inflicted wounds do the most damage...

droftarts

@davidjryan I think M606 is only needed if there are more Gcode commands for one motion system than can fit in the Gcode queue, as the other motion system may run out of commands and pause. So it really depends on what you're doing. Though I'm not sure if there are any downsides to running with the file input split, perhaps only on memory.

Ian

davidjryan

@droftarts

Here is my test code:
testma.g

M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000
G90 G1 A0 F2000
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G90 G1 X200 F3000

M596 P1
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X500 F5000
G90 G1 X100 F3000
M400

M596 P1
M400

M598

M596 P0
G90 G1 X0 A0 F4000
M400

Everything works as expected but I get:

as soon as I run the macro. The axes perform the motions in the macro but I get the M606 No file is selected error right away and then the green "complete" or "file processed" message.

My start.g and stop.g files exist but are both empty. I thought it was trying to call one of those so I created them but left them blank.

I've read this a couple of times now:
https://docs.duet3d.com/User_manual/RepRapFirmware/Multiple_motion_systems

I still can't figure out what M606 error is all about.

System is 6HC in SBC mode, CNC mode, and I am sending M98 P"testma.g" from the DWC

dwuk3d

@droftarts said in [3.6.0-rc.2] M596 Multiple Motion Systems:

@davidjryan I think M606 is only needed if there are more Gcode commands for one motion system than can fit in the Gcode queue, as the other motion system may run out of commands and pause. So it really depends on what you're doing. Though I'm not sure if there are any downsides to running with the file input split, perhaps only on memory.

Ian

Ian - I only ever got up to 5 commands to run in parallel, irrespective of queue size before I started using M606.

More notes here if anyone is interested
https://forum.duet3d.com/post/352058

dwuk3d

@davidjryan Worth trying invoking your Macro with M606 in a Job if you are not already doing that - as I think that might be relevant.

You might actually need the M606 to be in the Job file and not in a macro - that's the way I have always used it.

Plus note that there are some complications with global variables and macro's mentioned in the @dc42 post that resulted in M606 being introduced - mainly as an option to switch off file forking by default I think.

Also - My M606 is not right at the top of the file - but only where I need to start going parallel, plus I don't have any M400's - just M598's in the parallel section after the end of the 2nd presented parallel stream.

I also have a Tool Selection after every M596 too - but not sure if that relevant in your case if you are not extruding.

davidjryan

@dwuk3d

My system is not a printer, so I don't run job files. I have 50+ macro files that perform each part of my process that I call as needed when needed via a custom python GUI running on the Pi. The custom GUI continuously reads the object model and based on the current state of the sensors connected to the Duet 6HC, I execute the required macros to perform an assembly process.

My motion queues are set to 100 steps each. So, I believe with the M606 S1, the queues are "filling", switching between each other, and "filling" with more commands. I do not see any motion stutter or stopping/waiting of one axis over the other. Granted, I only have 3 commands per motion system, then 2 per while switching between them. I'll try to tax them a bit more with more motion commands to see if/when the queues are affected by quantity of commands.

When I run the above macro, line 15 (G90 G1 A100 F2000) starts a second or two before line 20 (G90 G1 X200 F3000) starts. So the two motion systems don't start simultaneously but it's close enough for what I am trying to do (reduce cycle time by running independent processes simultaneously).

Now, if I do this (at line 15 start P1 with 1 move, switch to P0 and start it with some moves, then go back to P1 and add the removed moves (old lines 16 and 17) to it's queue (lines 23 and 24)):

M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G90 G1 X200 F3000

M596 P1
G90 G1 A0 F2000
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X500 F5000
G90 G1 X100 F3000
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F4000
M400

the 2 axes start pretty much simultaneously. So, it's safe to say there will be a lag before the 2nd queue starts when filling up the 1st queue with it's initial moves/commands, which is totally understandable.

I just need clarification on what the M606 error is all about. What "file" is it referring to?

davidjryan

@dwuk3d @droftarts

Modified test macro:

;M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000
G90 G1 A0 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000

M596 P1
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G4 P1000
echo "X stopped"
G90 G1 X200 F3000
G90 G1 X500 F5000
G90 G1 X100 F3000
G90 G1 X500 F5000

M596 P1
G4 P1000
echo "A stopped"
G90 G1 A500 F5000
G90 G1 A100 F3000
G90 G1 A500 F5000
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X100 F5000
G90 G1 X500 F5000
G90 G1 X100 F5000
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F4000
M400

So, I am playing with the number of move commands and adding in G4 P1000 with echo between the motion systems. I wanted to see if a G4 in one motion system would affect the other motion system and it does not. Again, as expected per the multiple motion system documentation. I am trusting but verifying...

Everything works as desired as long as I don't let either motion system "run dry" of commands. If one motion system runs out of commands, the axis sits and waits until the next M596 Px and gets more to do... totally understandable and expected per the documents.

Also of note, running with or without M606 S1, the functionality seems to be the the same, just no M606 error without the M606 S1.

droftarts

@davidjryan said in [3.6.0-rc.2] M596 Multiple Motion Systems:

Everything works as expected but I get:

...

I still can't figure out what M606 error is all about.

One for @dc42!

Ian

dwuk3d

@droftarts

I get
M98 P"0:/macros/M606 Test.g"
Warning: this command is valid only when running a job from a stored file

When I try including an M606 in a macro - which I run from the console, or if I type it directly in.

I think it only works in Jobs.

The only way I found of having more than 5 commands queued was to use M606 - but if @davidjryan is managing to get more commands than that queued then great.

I haven't tried anything like initiating commands from python or having a SBC connected - so I guess there might be quite different behavour running that way.

Looking back on my notes - it also looks like M598's only work for jobs too - so I can understand now why @davidjryan is needing to do M400's

I might end up needing to do something like he is doing at some point kicking things off from something like deamon.g - because when one motion system finishes its current batch of work quite a long while before the other one I will need the print head to park and cool down. But then just before the other one has finished I need to find a way to kick off the idle motion system again to reheat and prime - ready for it to start work on its next batch (layer) once the other one has finished.

davidjryan

I've gone a few days now and the multiple motion systems is working well. I'll call this one closed.

Thanks for the assist!

dc42

@davidjryan thanks for confirming!

droftarts

@davidjryan @dwuk3d Re M606 in macros, @dc42 replied this when I asked him:

M606 only works in job files. The full functionality of M598 only makes sense in job files (or in macro files called from job files) after M606 has been used, but using M598 should be harmless in other situations.

Ian

dwuk3d

@droftarts thanks - I've been wrestling with M598's a lot over the last few days - trying to get parallel tool changing working (not actually parallel printing).

I am flipping between two motion systems - trying to kick off a process on the other motion system just before the current motion system finishes.

I'm getting close to getting it working - but I've at the moment I've more or less given up on using M598's. - as when you keep alternating between using them on different motion systems (a) sometimes they work fine, (b) sometimes they wait for around 20 seconds for no apparent reason. (c) Sometimes they hang and finally (d) sometimes they seem to just finish even though the other motion system is working on stuff.

I tried using axes machinePosition to tell what the opposite gantry was up to - but that doesn't seem reliable either.

So I have settled on using global variables to flag when the other motion system is parked - so when it is safe to proceed.

Seems to be working ok so far.