[gnea/grbl Issue#734] Question: GRBL not processing M3/4/5/8/9 or G4 commands until Jog is complete

#1 – mike-pittelko 于 2019-10-06

Yes. You should actually not expect any commands to be processed during >>jog<<. Jog is a special case where a number of modals don't apply either. It doesn't actually make much sense to be jogging in the middle of a program, you should be using G0/G1 for movement.

#2 – valentine195 于 2019-10-07

Sorry, I misspoke. When we stream a program to GRBL, it is using G0/G1 commands for movement.

This is a typical program:

Set modals -> processed immediately
G0 to a retraction -> processed immediately
G0 to the first programmed point -> processed immediately
Turn on the spindle -> not processed until previous G0 is complete (the machine finishes moving)

Additional steps afterward have the same behavior.

We have switched to buffer counting, which has fixed the issue on our end.

#3 – mike-pittelko 于 2019-10-08

I would have thought that would be desired behavior – turning on the spindle mid rapid seems a little sketchy….agree, shouldn’t matter….but…..

Does GRBL happen to be in laser mode?

#4 – bdurbrow 于 2019-10-13

Acting on M codes further downstream from the command currently being executed would be really bad.

Consider a laser machine – turning on the laser when not in position would cause cutting where it shouldn’t, ruining the work; or turning it off prematurely, with the effect that the final few moves wouldn’t be cut.

Or, consider the commands to turn off coolant or the spindle – if those executed immediately, you’d be left either cutting dry or pushing a cutter into the work-piece when it isn’t spinning.

#5 – MeJasonT 于 2019-10-13

The commands in the GRBL controller are buffered and are carried out on a fist in first out basis.
The only other method available is using the high level commands, pause, reset, door etc which are acted upon immediately and for obvious reason.
The M & G codes are part of the job and not high level commands. What you are looking for is commands/operations which should be handled by your post processor. It may appear on industrial machines that the spindle is started during the move but in all likely hood it is started then the move is performed, this would give the illusion that the spindle started on the move as its initial inertia will not have allowed it to spin up to speed before the move started.
Writing a GUI is hard enough without getting bogged down with fiddly bits, Trust Grbl its well written and follow the gcode standard it will make life a lot easier in the long run, I tried to fight the system and the guys and gals on here wouldn’t budge. The code is solid but it will only remain stable if its not messed around with.

#6 – mike-pittelko 于 2019-10-13

> We have switched to buffer counting, which has fixed the issue on our end.

This doesn’t make any sense either.

M commands, by design, cannot happen until the previous G has completed. They’re “M” for Modal….changing modes before a command completes would have all sorts of ugly effects as described above. gcode is not a complex language, and hoisting commands like this is literally impossible to do in this case – how far ahead do you want them reordered? That can be done in many cases by computer code because of known side effects. In this case, the effects are literally unknowable. If the code generator could safely move the command earlier, it should have done so.

Regarding “wouldn’t budge” – there’s just not a lot of capability to budge – the code space is tiny (and full), the code is mature, not simple, and real time motion is involved. I don’t know what you were asking for, but I know the changes that came in 1.1 took a very long time to get done, and as I understand it, there’s active work going on for a successor codebase. It’s coming, just very slowly.