M291 Does not block in macro when a job is running
-
I have a MB6HC running 3.5beta3 in CNC mode and use a custom M6.g file to handle tool changes. My issue is with M291 commands not blocking as expected when M6 is called during a job. My macro has 3 M291 calls to pause the script at various points and allow me to manually change the tool and use a stationary bitsetter to adjust my WCS Z.
; M6 Call for tool change G53 G1 Z{move.axes[2].max-1} F1200 ; Move to Z Max-1 M11 ;Turn off Vac M291 P"Tool Change" R"Move to BtStr" S3 ;Start Confirmation ; ---Move to BitSetter--- G53 G1 X{global.BtStrXLoc} Y{global.BtStrYLoc} F4000 ; Move to BitSetter location ; ---Probing--- M291 P"Tool Change" R"Probe new tool" S3 Z1 ;Start Bitsetter Probe Confirmation M208 S1 Z0 ; reset Z-axis limits before probe G38.2 K0 Z-120 F100 ;(BitSetter Probe 0) G10 L20 P9 Z{global.BtStrZTrig} ;Set SB-Z=0 in WCS 9 ; ---Set tool offsets--- G91 G1 Z15 F500 ;Clear the top G90 ; Absolute positioning G10 K1 L20 Z{global.BtStrZTrig+15} ;Set WCS Z0 G53 G1 X{global.BtStrXLoc+25} Y{global.BtStrYLoc+40} F4000 ;Clear the Button XY G53 G1 Z{move.axes[2].max-1.5} F1200 ; Move to Z Max - 1.5 M208 S1 Z{move.axes[2].workplaceOffsets[0]} ; Set Zmin to Probe SB=0 From new WCS Z M291 P"Tool Change" R"Resume" S3 ;CONFIRM SET WCS XY M10 ;Turn on Vac
If the macro is run while the machine is idle It behaves as expected, but if it is called durning a job, the macro behaves as if only the last M291 is blocking, and the first two are run as if they where a non blocking type. I have tried various M400 calls without luck. I even split the macro into tfree,tpre, and tpost (instead of M6) each with it's own M291 and it behaves exactly the same. Is there some kind of formatting error I am missing? Why is this working while idle?
-
-
@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 usingM98
(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
-
-
@NineMile please try the latest 3.5 build at https://www.dropbox.com/scl/fo/wrp6hvr39vjxjlep89p5x/h?rlkey=hzka49sxnsqjpwsvy46m26ms0&dl=0.
-
*RC3 build. I'll give the latest 3.5 build & the M98 a try next week.
-
@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).
-
-
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 callingM98 P"M3.9.g"
instead. -
@NineMile can you upgrade to 3.5.1 and verify again please?
-
@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 withM98 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, executesM5
and then aG4 S...
if any spindles were running. -
@NineMile what happens if.you add a
G4 S1
before and afterM5.9
? -
@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.