M291 Does not block in macro when a job is running

[NineMile]

@TeamCoco wondering if this is another symptom of an issue I've seen recently with G4 not pausing in a custom Gcode when called using the code (e.g. M6) vs working correctly when called using M98 (e.g. M98 P"M6.g").

I'd be interested to hear if calling your existing macro using M98 in the SD card file fixes the issue?

Details here: https://forum.duet3d.com/topic/35300/odd-g4-behaviour-from-macro-called-from-sd-file?_=1711622479937

[Phaedrux]

@TeamCoco said in M291 Does not block in macro when a job is running:

3.5beta3

beta 3 or RC 3?

[dc42]

@NineMile please try the latest 3.5 build at https://www.dropbox.com/scl/fo/wrp6hvr39vjxjlep89p5x/h?rlkey=hzka49sxnsqjpwsvy46m26ms0&dl=0.

[TeamCoco]

*RC3 build. I'll give the latest 3.5 build & the M98 a try next week.

[NineMile]

@dc42 I'm unable to do this as there's no stm32 builds there, but I think Andy has already tested this on his latest build with the same outcome as my initial testing (in the other thread).

[jay_s_uk]

@NineMile @gloomyandy

[NineMile]

Bump, still getting this on 3.5.0-rc4 which I believe is after the 'latest build'. I'm still seeing delays behave differently when calling M3.9 directly from a file vs calling M98 P"M3.9.g" instead.

[jay_s_uk]

@NineMile can you upgrade to 3.5.1 and verify again please?

[NineMile]

@jay_s_uk said in M291 Does not block in macro when a job is running:

@NineMile can you upgrade to 3.5.1 and verify again please?

Yes, this still happens on 3.5.1.

As an example, I have a park macro, G27 which is called at the end of a job file:

; Use absolute positions in mm
G90
G21
G94

; Move spindle to top of Z travel
G53 G0 Z{move.axes[2].max}

; Stop spindle and wait
M5.9

; Present workpiece
G53 G0 X{(move.axes[0].max - move.axes[0].min)/2} Y{move.axes[1].max}

When this macro is triggered, the spindle moves back to Z=0 at the end of the job, then it instantly moves to the X and Y location - only then is the spindle stopped and a wait occurs, which is the wrong way round - it's like the M5.9 call is being deferred.

If I replace the M5.9 line with M98 P"M5.9.g" then this behaves as I would expect - the spindle moves to Z=0, it then stops and moves the workpiece to the front of the machine.

M5.9 just checks if any spindles are running, executes M5 and then a G4 S... if any spindles were running.

[oliof]

@NineMile what happens if.you add a G4 S1 before and after M5.9?

[NineMile]

@oliof - in this case are you looking to confirm if the G4s inlined with the macro call work, but the ones called from inside the macro don't? I'll try and check this morning.