M291 Does not block in macro when a job is running
-
-
@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.