Immediately! What does that actually mean?

Controlling external relays and digital outputs with grblHAL is easy. M62-M65 GCodes (er, MCodes?) are straightforward. Or are they?

The Digital Output Control codes allow you to turn external devices on and off. On the T41U5XBB and RP23CNC boards, there are both relay drivers and logic level digital outputs that can be used for that. Embed a G62 P0 or G64 P0 in your GCode program to turn the Aux 0 output on. G63 P0 or G65 P0 will turn it off. These can be put in the standard prolog/epilog sections that typical CAMs have and they automatically get inserted into your GCode programs.

I have a customer using grblHAL. He wrote a short GCode program to test using the Aux outputs of his RP23CNC board. It turned on Aux 0 with an M64, did some motion and turned it off with M65. He wrote me that it didn't work correctly. The Aux output never came on. I tested his code and it seemed to work just fine. Though, he was using USG and I was using ioSender. I tried it using Sienci's GSender and got oddly different results. The output came on at first but went off well before the job completed. Understanding why requires diving into the details of how grblHAL handles these codes.

The LinuxCNC manual describes the action of M62-M65.

The M62 & M63 commands will be queued. Subsequent commands referring to the same output number will overwrite the older settings. More than one output change can be specified by issuing more than one M62/M63 command.

The actual change of the specified outputs will happen at the beginning of the next motion command. If there is no subsequent motion command, the queued output changes won’t happen. It’s best to always program a motion G-code (G0, G1, etc) right after the M62/63.

M64 & M65 happen immediately as they are received by the motion controller. They are not synchronized with movement, and they will break blending.

M64 and M65 happen immediately while M62 and M63 happen at the beginning of the next motion command. When I changed the program to use M62 and M63, it worked as expected - Aux 0 turned on at the beginning and off at the end for all the GCode Senders I used.

The reason for the different behavior is due to how different GCode senders talk to the Grbl controller. In order to avoid starving the controller, the senders will presend commands. The controller will process them, place them into the planner buffer and execute them in turn as the previous one completes. This allows the sender to get well ahead of the controller and allows very short/fast movements without having to wait for the next command to be sent. Some of the GCode Senders allow you to choose to presend or not - like ioSender's "Agressive buffering" option and the default is off. Other senders treat it differently and tend to always buffer aggressively without the option to turn it off. When I turned on Agressive Buffering (yes, it is spelled that way in ioSender), I got the same behavior as UGS and GSender. So, what does grblHAL do that makes the difference? It receives a command and then places it in the planner buffer. It works through the planner buffer executing each command when the previous one completes. So, it executes M64 and M65 at the time when it places the command in the buffer (ie immediately when it receives the command from the sender). M62 and M63 are placed into the planner buffer and executed when it sees a following motion code. Interestingly, any GCode command seems to count as motion - G04 (the delay command) works, for example. Note: I have significantly simplified how grblHAL manages the planner buffer.

In the end, the solution is to use G62 and G63. You need to make sure there is a motion command following the MCode. I may have inadvertently contributed to this confusion because I use G64 and G65 in a number of posts. This is to simplify my explanations - I can avoid having to issue a subsequent motion GCode to make the action happen. Unfortunately it sets people up for this confusion. Mea Culpa!

Note: the behavior is dependent on how the Grbl motion controller works. Other GCode motion controllers may behave differently. If you are using Mach or LinuxCNC or others, how does it work for you? Here is a little test program to try it out, courtesy of a customer who wishes to not be named. With a buffering controller, the Aux 0 output should go on at the start of the job and then go off well before the end. If you change G64 to G62 and G65 to G63, Aux 0 should stay on the entire job and go off when it ends.

G21

S1000

G0Z5.0

G0X60.0Y10.0

G0Z3.0

G0Z3.0

M64 P0

G04 P0.5

G0X60.0Y10.0

F100.0

G1X60.0Y10.0Z1.5

F500.0

G1X60.005Y10.0

G1X60.0Y60.005

G1X9.995Y60.0

G1X10.0Y9.995

G1X60.0Y10.0

M65 P0

G0Z5.0

M5 M30

About Me.

I'm Phil Barrett, a long time CNC enthusiast. I run a small company, Brookwood Design, that makes several breakout boards for grblHAL and love to help people get the most out of their CNC machines.