Tool Change M06 not recognized with TC Post Processor

I’m using Windows 10, Vectric’s VCarve Desktop and GRBL V. 1.1, Shapeoko 3XXL, Universal GCode Sender Platform Version.

I used VCarve to create a file with two short duplicate horizontal lines along the X axis, one under the other spaced about three inches apart.

The first line was a profile cut on the line with a 1/4" endmill. The second line was a profile on the line using a 1/8" endmill.

I then saved the two tool paths in the same file using the “Shapeoko_inch_TC.pp” Post Processor.

I did an “air cut” just to test to see that the job would pause for a tool change after the first path.

As soon as I ran the job I received an Error 20: Invalid Command M06. Imagine my surprise. :blush: I hit continue and the job began running as if it was a single tool job. Both lines cut and the program ended.

I opened the GCode file and the coding was, IMHO, perfect. Raise the tool, move to xy position, lower tool, cut the first line, raise the tool.

Then came the M06 command followed by similar code to cut the second line, raise the tool, return to xy zero and M30 to end the job. Who could ask for more?

Soooo… What I’m wondering is… What am I missing? It must be something simple. I used the correct PP. The coding was correct. Is there a GRBL setting change that I should know about?

Obviously, before I waste my time adding all the GCode for my tool change to the PP, I think I should get it to Pause first. :grinning:

While I still have some hair left, any suggestions would be deeply appreciated.

Thanks in advance.

EDIT: I checked with the Vectric Forum first and I was told that it didn’t look like a Vectric problem and that I should check with the Forum of my machine’s controller.

Second EDIT: Added UGS.

Hey @Signdude,
Grbl can’t process M6 (tool change) commands. That is left to the UI to intercept the M6 and process it on the computer.


Hey Neil,

That didn’t take long. :joy: Hope you got my PM.

By UI are you referring to UGS? It’s intercepting it alright. It’s detecting it in parsing before execution.


But it’s giving you an error, right?
So you have all of your tool change macro built into the gcode? The only thing not working as expected is that UGS tells you it can’t run the M6?

I have individual macros for everything I need for a tool change and they work fine one at a time.

Assuming proper pauses:

  1. Move to tool change location - Pause - Manually change bit.
  2. Move to probe location - Pause - Attach probe.
  3. Run probe operation - Pause - Remove probe
  4. Move back to xyz zero - Continue program

I have combined them into a single GCode segment, all ready to insert into the PP. I’ve even run them together as an independent GCode program and they all work just fine with the exception of the pauses I need.

I’ve even tried using M01 for pauses and they are rejected as well.

I can find no way to combine the macros into one macro. UGS doesn’t offer a way that I can find of storing so many instructions in a single macro. I’ve seen how you do it in CNCjs. Wish I could do it in UGS.

I’m guessing that CNCjs has no problems with the M codes???

1 Like

Correct. It pauses on a tool change and allows you to run a macro.

Thanks for the info Neil.

Wish I had asked about GRBL and M codes a lot earlier. I wouldn’t have wasted so many hours. It was still a great learning experience. I just find it difficult to believe that a simple stop/pause instruction was not a part of GRBL from it’s inception. I just assumed since Shapeoko provided Tool Change Post Processors and used GRBL that M06 and M01 commands would certainly work.

GRBL certainly uses a pause because it used one to show me my pause instruction was an error. It then allowed me to click continue running the rest of the program. :slight_smile: I believe that’s all I needed to complete my task.

When I tested my code within the Post Processor, the instructions worked just fine with the exception of the necessary M06. I commented-out the actual probe instruction because I didn’t want to get my hands near the gantry until there was an actual pause. In my thinking, if the code were part of the post processor, macros would not be necessary as I would always use the TC Post for any job with multiple tools and the Post would include the code in the GCode file.

Looks like I’ll be switching to CNCjs sooner than I expected.

Thanks for your help… as usual. :slight_smile:

@Signdude The M0s should create a hold state that you would have to resume. If you just used M0 for the tool change, you might be able to get it to work. Create your tool change sequence and insert it. There would need to be some probable hand editing (or some sort of script) to resume states after the tool change, but I think it’d be possible to create a GUI - independent tool change macro that would be part of the gcode.
How were you working out the probe location and the new Z offset?
I think you might run into trouble on projects with so much material removed that your probe was useless on top. Could be an easy way to switch to a cutter for profile cuts where one could use the wasteboard as a reference.
I’ll give it a look when I have some time.

Hey Neil,

Thanks for the reply. I’m anxious to give the M00 a try tomorrow. I wish I was optimistic, but as I indicated earlier, when the M06 failed to work I tried using the M01 (Optional Stop) and that had no effect either. I hope the M00 works.

As I’ve followed your work on your Tool Change macro I agree that I will have to keep track of states throughout the coding. The Post makes available some “variables” and “reserved words” which I think will allow handling to those items. Thanks.

At the moment, my probe location is at the lower left corner of the material with an XY Zero offset of 1-1/2" to allow for the size of my probe and keep it away from the cutting area. That’s not going to be a satisfactory location for all jobs, but if the M00 command will get my code running properly, I’ll go back and see what I can do about moving it, as you suggested.

Thanks so much for your thoughts and help,

1 Like

Hey Neil,

Mega thanks. I had a chance to try out the M00 command and it works perfectly. I still don’t know why the M01s were ignored, but the important point is you’ve got me back on track. I haven’t had much time this evening to get the entire routine working, but I did have time to get the following working as it should.

After zeroing the material XY & Z, as normal at the beginning of the job, the program…

Proceeds cutting the first horizontal profile line and lifts the bit.
Moves to the Tool Change location, Pauses
I change the bit and hit Continue
The bit is moved to the Probe location, Pauses
I position and connect the probe and hit Continue
The probe operation is executed and the bit is raised.
The bit is moved to the Material XY position.

Tomorrow I’ll get to resetting the Z0 based on the previous probe and see how that goes.

Because the tool path program was written in “inch” mode, the above coding which uses mostly G53 coordinates, is enclosed within G21 and G20 commands.

Thanks again for your help. I’ll post when I find out how the rest goes.


M1 has something to do with a “stop switch” and doesn’t seem to be supported by grbl.

From the grbl source code:
*M1* NOTE: Not supported, but valid and ignored.

Just curious if any of the code writers on this forum participate in GRBL development. If they do, maybe these functions could be introduced into a future version. It seems that several users are trying to push the capabilities of our entry level CNCs to make them more capable. Should those unsupported M commands be included?

That would be @chamnit — my understanding is that there was a major push to make Grbl as good as it could be on an Arduino — essentially done in v1.1 — and the next step is to change the focus to a different processor/board and to begin adding features.

1 Like

It seems those commands would almost always require the sender app to handle them, as the controller doesn’t have any user I/O (there are no screens, for example, to display an instruction like to change a tool).

That’s correct. The Grbl on the Arduino Uno was made to be as good as possible with the most critical features prioritized due to limited space. The current development is not available online yet but it focuses on making the firmware abstract enough to be easily ported and allow others to add things fairly easily.


The timing of this couldn’t be more fortuitous.

I use Cut2D and am working on a project with multiple tools and thought it would be nice to output a single file.

The current post processor I’m using (G-Code Arcs (mm)) doesn’t support tool changing.

Which post processor are you using that supports both GRBL and tool changing?

Also, may I ask which version of UGCS you’re using?

Thanks for any help you can provide.

Adding the tool change to a V-Carve post is pretty simple.
Just add:


  • Commands output for tool change


“M6 T[T]”

to your post. I use GRBL (mm) with added support for Tool changes and dwells.

1 Like

Does M6 work? Is your change all that is needed to make my G-Code arcs (mm) PP work?

It seems Bill had problems with M01 and is now using M00 and never mentions M06?

I’d like to avoid having to repeat his steps in deriving a solution if possible.

I’m 53 going on 54, trying to limit trial and error. :slight_smile:

Sorry Phil. No, M6 won’t do anything by itself. Your sender would have to intercept the M6.
Bill was modifying the post to include all of the commands he needed for a tool change, replacing the standard M6.
If your Z probe location would be consistent (and not carved away), I think it’s doable, regardless of sender.

1 Like

No problem, Neil.

I was just wondering if anyone had any simple tool changing code that works with GRBL (.9?) and Universal G-Code Sender (one of the later versions). All I really need it to do, is pause execution and allow me to jog and press my macro shortcut (F1) I use to re-zero the Z.

If anyone has anything like that and can share, that would be great.