M291 Does not block in macro when a job is running

TeamCoco

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?

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.