[3.6.0-rc.2] M596 Multiple Motion Systems

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.