**Critical Workflow Issue for me: Manual Tool Change & Z-Probing during Job Pause**

MillMage Software Questions
,
1

Hi everyone,

I’m from Germany, new to this forum and recently started working with MillMage on my SainSmart PROVerXL 4030 V2 (using the custom GRBL MillMage configuration).
Thx to the KI for translating my german text. :wink:

To give some background: I’ve been a DIY/Hobbyist CNC user for over 12 years with different machines and self-builds. I’ve worked extensively with LinuxCNC, Mach3, UGS, gSender, and Estlcam. My goal was to finally have an “all-in-one” solution by moving my entire workflow to MillMage.

However, I’ve hit a major roadblock regarding Manual Tool Changes (M6) that currently acts as a deal-breaker for me:

The Problem: In my typical workflow (especially when switching between a spoilboard for wood and a T-track nut-plate for aluminum), I need to perform a manual tool change. In every other sender software (like gSender or LinuxCNC), a tool change command (M6) pauses the machine and allows the user to manually jog the axes. This is crucial to:

  1. Move the spindle to a convenient position to change the bit.
  2. Use a mobile touch plate (or paper method) to re-zero the Z-axis for the new tool at the current workpiece position.

The MillMage Limitation: Currently, MillMage locks the axes during a pause/tool change. It seems to enforce a workflow that requires a fixed/stationary Z-probe or ATC to calculate offsets. For many DIY users, a fixed probe is not always feasible (e.g., when the probe is mounted on a spoilboard that gets removed for aluminum jobs).

Broken G-Code Export (M6 Error): Another major issue is the G-Code generation itself. Even in projects using only a single tool, if the M6 command is enabled in the post-processor, MillMage returns an error. This makes it impossible to use MillMage even just as a CAM tool to export clean, standard-compliant G-Code for external senders like gSender or Estlcam. I am essentially blocked from both sides: I can’t do a manual change within MillMage because of the axis lockout, and I can’t export a file with proper tool headers to another software because of the M6 errors. This forces me to manually edit G-Code or split files into single operations, which is a massive step backwards in terms of productivity.

Why this is a KO-criterion: Without the ability to jog and re-zero Z manually during a tool change, I am forced to split every project into multiple single-tool files and run them separately. This defeats the purpose of an integrated CNC suite.

I really want to love MillMage, as the UI and CAD/CAM integration are absolute great, but the inability to perform a flexible, manual tool change makes it impossible to use in a versatile workshop environment.

Are there plans to allow jogging and manual Z-probing during a tool change pause in future updates? Or is there a workaround that doesn’t involve a permanent, fixed-location sensor?

Since I am still new to the MillMage ecosystem, it is entirely possible that I have overlooked a specific setting or a different workflow approach that addresses these needs. If MillMage already has a way to allow for manual jogging and Z-probing during a tool change pause without a fixed sensor, I would be more than happy to learn how to set it up correctly. My goal is to streamline my process, and I’m open to any advice if I am simply “holding it wrong.”

Thank you for your time and for all the work you put into the software!

Looking forward for any feedback or helping hands.

Best regards,

Manfred

2

Thank you for your thoughtful and complete explanation.

Your contribution is appreciated.

I’ve escalated your concerns to a Dev channel internally.

3

You are describing a process with an automatic tool changer than can run through each operation without stopping. Otherwise, the spindle moves to a tool change position (you define), then performs a Tool Probe cycle (if you have one and enable it). Then it continues with the next operation. I am curious as to where you are going to place the Tool Probe Block if not on a corner.

We all are. MillMage is a brand new product that has not even reached version 1.0.0 yet. You can buy into it now and grow with the rest of us, or wait until you think it is perfect. Personally I prefer to ride the roller coaster. :joy:

The concept of Lightburn migrated into a CNC mill program is what makes it worth using. Is there another product out there that gives a similar result (design and machine control in a single application)?

We all share what we discover here. That is what makes this adventure so much fun!

Finally, welcome to the forum. When you ask questions, we all learn in the process. Keep asking!!!

9

@heelimanni

I’m not understanding the error attributed to Millmage.

Please re-run the GCode where the error appears and capture a screenshot so I can understand and further inform our team.

Like LightBurn, the text in the Console window is scrollable and selectable so it can be copied and pasted into a thread here. This improves accuracy/precision.

Along with information about the error message, we definitely need to know which firmware version is stated by the SainSmart controller in the MillMage Console window when Millmage connects to the PROVerXL 4030 V2. The initial message can be more verbose than the regular request for the firmware version report.

Please copy the text stating the firmware version from the Console window and paste it into a reply here.

10

My understanding is that the basic version of grbl on the Ginmitsu machines does not support the M6 command. Do you have a different experience with this command on these machines?

11

I ran a test today and can confirm my Genmitsu 6050 does not recognize the M6 command. It does pause, but only because the M6 causes an error code..

12

it’s a shame no further explanation has been added is old mate left in the lurch, or has it been sorted curious for similar reasons

pat

13

Well, the OP has not responded with the information he was asked to provide. The developers can’t help me if he won’t cooperate by providing information. My opinion, for what it’s worth, is that this is a grbl problem, not a Millmage problem.

14

Or to be more exact I thought it was a Sainsmart GRBL issue including my machine. Until I found this…

Standard Grbl 1.1h does not natively execute the M6 (tool change) command. Instead of stopping or prompting for a tool change, Grbl ignores the code. To work around this, you must rely on your G-code sender software or CAM to handle the operation.

If it throws an error instead of ignoring it, attribute that to the manufacturer of your machine.

M6
error:20
Unsupported or invalid g-code command found in block

15

Hi everyone,

First of all, thank you very much to everyone here who is trying to help me with my problem.
Sorry for the delay, we had school holidays here in Germany and I was away on vacation! Here is the cooperation and info you needed to clear this up.

First, here is the exact firmware greeting line from my MillMage Console when connecting to the Sainsmart PROVerXL 4030 V2:

Plaintext
[SainSmart PROVerXL 4030 V2 v1.1]

What happens on the machine side:
MikeyH and davebmck are completely right. As seen in my log, this Sainsmart firmware does NOT support the M6/M06 command natively and responds with a hard crash:
error:20 - Unsupported or invalid g-code command found in block

However, this tool change sequence is very common for GRBL machines. To illustrate, here is the exact G-code sequence we use for a tool change on this setup:

M05
G00 Z30
M06 (Tool change: Insert cutter and run Z-probe)
M00 (Safety pause: Manually turn on spindle now!)

This exact G-code runs flawlessly within Estlcam’s internal controller, as well as when streamed via standard GRBL senders like UGS (Universal Gcode Sender) and gSender.

The difference in behavior seems to be that Estlcam, UGS, and gSender intercept the M06 command on the software side. They pause the stream and prompt the user to change the tool/run the probe macro, rather than passing the raw M06 command down the USB wire to the GRBL hardware.

Currently, when MillMage encounters the tool change, the M6/M06 command is sent directly to the controller, which triggers the error:20 and halts the stream.

A controlled pause is essential for my setup.
I am running an external 1.5kW spindle with a VFD that is not (and cannot be) controlled by the Sainsmart board (had contact with manufacturer). Therefore, a controlled software pause during a tool change is absolutely critical to process the following required workflow:

  • software finishes milling operation 1 with tool A, moves to clearance height, and pause.
  • Manually turn off the spindle motor via the VFD.
  • Remove the dust shoe / vacuum attachment.
  • Remove tool A and insert tool B.
  • Run the Z-probe macro on the tool setter (WLS), then move back to clearance height.
  • Reattach the dust shoe.
  • Manually turn on the spindle motor and speed at the VFD.
  • Click “Resume” to start milling operation 2.

For now, I will revert to my old setup with Inkscape/Estlcam/GSender.
Should I find a solution in MillMage (I’ll keep an eye on it) , I would be happy to move my entire workflow over to MillMage. Apart from my ‘pause problem,’ MillMage is a fantastic piece of software that I would love to use. After all it is exactly what I wished to have for over 10 years!

Best regards!

16

Most of what you are describing sounds achievable already, aside from manually jogging and setting Z0 from MillMage during a pause, but I don’t think that is necessary.

You can add a movement to the best tool change position as part of the Tool Change, then include a controlled pause using the @P command, for example;

@P Please insert Tool #{tool} | {tool_name}

After setting your initial Z0, ideally using Z-‘Probe Block’ with a mobile touch plate, you can immediately use the same mobile touch plate for the ‘Tool Length’ probe. Wherever you set the tool length probe to take place (a fixed location best set at or near where you will change the tool), it should not change height in the Z axis as the job progresses.

17

My Sainsmart does not get sent the M6 command to GRBL on a tool change. I have included the entire tool change sequence from my machine in the image. It works like a charm.

GRBL Tool Change
GRBL Tool Change946×1021 141 KB

18

Hi Nicholas,

First of all, thank you so much for your fast and incredibly helpful response! Having such dedicated support from the team makes a massive difference when dialing in a workshop workflow. I really appreciate your guidance on the tool change logic!

You are right with your idea. Having an @P as a controlled stop would be all I need.

Just to clarify: I already have the @P command implemented in my main Tool Change script, and it works absolutely perfectly there! It does exactly what it’s supposed to do, allowing me to stop the spindle and change the tool safely. Ideally, I would love to use that exact same pause/message behavior at the end of the tool length probe routine to manually and safely spin the spindle back up.

However, when using the @P command inside the Tool Length measuring routine, I ran into a technical hitch with how the command is streamed. It seems that at this specific stage, the @ symbol gets passed directly to the Grbl controller instead of being intercepted by MillMage first.

M5
G21
G53 G1 Z-10 F2400
G53 G1 X-28 Y-270 F4000
G53 G1 Z-45 F2000
G91
G1 Z-0.1 F400
G38.2 Z-60 F150
G1 Z1.5 F2400
G38.2 Z-1.5 F30
G90
G53 G1 Z-10 F2400
G54
G1 X0 Y0 F4000
@P Spindel starten

I also tried G4 as last line, which works, but this delay is not the control i need.
G4 P8 (8-second dwell to let the spindle spool up to full speed)

Here is the exact error log I got from the console:

Plaintext
[PRB:-28.000,-270.000,-60.388:1]
[PRB:-28.000,-270.000,-60.398:1]
error:1
G-Code-Wörter bestehen aus einem Buchstaben und einem Wert. Der Buchstabe wurde nicht gefunden.
On or near line 14:
Stream completed in 0:16

Hope you can understand the german parts in the code …

Thanks again for pointing me in the right direction – MillMage is a fantastic tool and your support is top-notch!

Best wishes from Germany, Bavaria

19

I don’t think I’ve ever tried @P in the Tool Length Probe, it’s possibly not allowed - I’ll find out.

I recommend you move your @P Spindel starten to to the ‘Tool On’ Custom GCode block.

20

Hi Nicholas,

You are a lifesaver! Moving the @P command into the Tool Change macro instead of the Tool Length Probe routine worked beautifully. I tried so much things, but your idea was perfect. No more Grbl errors, and the pause works exactly as it should. Nicholas, you definitely saved my workflow here! Almost … :wink:

However… there is still one “almost” in the equation that makes the initial startup a bit frustrating. Right now, I am forced to probe the tool length twice back-to-back before the machine actually starts cutting.

Here is exactly what happens:

Preparation: I insert the tool, move to my X/Y workpiece zero, and use my mobile touch plate to set Z0. This works flawlessly.

The software request: Immediately after setting Z0, MillMage requires me to perform a Tool Length Probe on the fixed sensor. I do this, and the spindle moves to its park position. Everything looks good.

Job Start: Now I hit “Start” to begin the actual job. But instead of cutting, MillMage immediately triggers the Tool Length Probe routine again as part of the initial tool change sequence in the G-code.

So, I am literally probing the exact same tool on the fixed sensor twice in a row before a single chip is made.

Is there a setting I missed to tell MillMage: “Hey, the current tool length is already measured, skip the initial probe on job start”? Or is this a known logic loop in the current version?

Thanks again for your awesome support, we are so close to perfection here!

Best regards!

21

Hi Manfred,

Yes, that is a known side effect when the first tool in your job is same tool that MillMage used to get the tool length offset “initial reference”, in which case, the “Skip” option is available so you can safely dismiss the first tool length probe.

22

Hi Nicholas,

Thank you so much for the quick explanation! It’s awesome to know that the “Skip” option is intentionally designed for exactly this scenario. Your support is truly outstanding!

I did some live testing at the machine with the “Skip” function, and I noticed a crucial difference in how MillMage handles the Z-axis movement compared to a successful probe cycle. I think this could be relevant for other users.

  • The Regular Cycle (Safe): After a successful tool length measurement, the machine is smart. The Z-axis lifts safely up to my absolute machine coordinates (e.g., G53 Z-20, almost all the way up) and only then travels laterally to X0 Y0. This is perfect and clears all clamps!

  • The “Skip” Abort (maybe Dangerous): However, when I hit the “Skip” button to abort the second probe, the logic changes. Instead of lifting to the safe machine coordinates, the Z-axis only retracts to the workpiece clearance height (G54). Because this is significantly lower, the spindle remains in a “low altitude” and then travels diagonally back to X0 Y0.

In certain setups—especially with flat workpieces and high clamps/fixtures—this low-altitude transit move creates a massive risk of a collision on the way back across the table.

For a future update, it would be a massive safety improvement if the “Skip” button triggered the exact same Z-retract behavior as the successful probe cycle (lifting to absolute machine coordinates like G53 Z-20 before moving X/Y).

I am currently tweaking my hardware setup a bit to mitigate this on my end, but having a consistent, safe G53 retract on “Skip” would make MillMage even more bulletproof for everyone!

Thank you again for your top-notch support and for helping me figure out the @P command. You guys are doing an amazing job!

Best regards,

Manfred