Overrides have no effect once job is fully in planner buffer

[dresco]

While there are still some lines to be received from the sender, then overrides (spindle / feed / rapid) behave as expected during job execution. However once the job is fully in the planner buffer, then overrides no longer seem to have any effect?

I have observed this both from a software sender, and from my control panel plugin (I'd just assumed it was a sender bug before this). Any ideas?

[terjeio]

A sender issue?

When I test with my sender it works as far as I can tell. There will be a short delay (~100ms?) as motions already in the segment buffer cannot be modified.

[dresco]

Have done a bit more testing. For me, at the start of a job - when there is data in both the receive buffer and planner buffer, then overrides work as expected. Once all the data is in the planner buffer, then overrides have no effect until the job finishes (but they are queued up somewhere, and are all applied at the end of the job).

I did think it might be a sender bug, but I also see the same thing from my control panel plugin - which uses grbl.enqueue_realtime_command() - same as feed hold / cycle start etc which all continue to work as expected.

I can replicate on the bench, so will dig deeper...

[terjeio]

Here is the test program that works with my sender:

G0X0Y0Z0
G1Y50F50
X10
Y20
X30
M30

[dresco]

Interesting, that one works for me too. Here is one that doesn't;

(Exported by FreeCAD)
(Post Processor: grbl_post)
(Output Time:2022-02-27 09:57:39.896810)
(Begin preamble)
G17 G90
G21
(Begin operation: Fixture)
(Path: Fixture)
G54
(Finish operation: Fixture)
(Begin operation: TC: 25.4mm Surfacing)
(Path: TC: 25.4mm Surfacing)
(TC: 25.4mm Surfacing)
(Begin toolchange)
( M6 T30.0 )
M3 S7200.0
(Finish operation: TC: 25.4mm Surfacing)
(Begin operation: LeadInOutDressup)
(Path: LeadInOutDressup)
(MillFace)
G0 X-19.150 Y18.950 Z5.000
G0 Z3.000
G1 X-19.150 Y18.950 Z-1.000 F420.000
G3 X-0.100 Y-0.100 I19.050 J0.000 F600.000
G1 X-0.100 Y-0.100 Z-1.000 F420.000
G1 X100.100 Y-0.100 Z-1.000 F600.000
G1 X100.100 Y16.918 Z-1.000 F600.000
G1 X-0.100 Y16.918 Z-1.000 F600.000
G1 X-0.100 Y33.936 Z-1.000 F600.000
G1 X100.100 Y33.936 Z-1.000 F600.000
G0 Z5.000
(Finish operation: LeadInOutDressup)
(Begin postamble)
M5
G17 G90
M2

[dresco]

It appears to be caused by the spindle stop (M5). As soon as that's removed, or the program end is moved above it, the issue goes away..

[terjeio]

core/gcode.c

Line 986 in 4ff8f1c

sys.flags.delay_overrides = On;

This is it, good catch. I have to rework this code - it is for delaying overrides when in spindle sync motion is active. Just uncomment the line for now. I am about to verify spindle sync with a STM32F411 driver so will take a look then.

[Erik-Morbach]

It appears to be caused by the spindle stop (M5). As soon as that's removed, or the program end is moved above it, the issue goes away..

I made some tests and this also occurs with M8 and M9.
The same line is used when checking M7, M8 and M9. There is a reason why this is used on coolant?

[dresco]

Hi @terjeio, any further thoughts on this one? (Just updating the code on my router, and revisiting the local code changes I'd made in the previous build). Thanks!

[terjeio]

Ouch, this had fallen off my radar. Will fix in the next commit by changing to separate delay flags for feedrate (not yet used), spindle and coolant. The reason for the delay is that, IMO, pending spindle or coolant commands should not be overridden before they take effect. These commands (M3, M4, M7, M8 and M9) will be pending until the planner buffer has been emptied. I guess I should look into S word handling as well...

[dresco]

Thanks, will test..