I’m having an issue where I’m running the built in routine to change a tool using the built in Fixed TLS routine. The first tool finishes running, goes to the probe location, probes, I change tool, probe again, then when I click to resume the program it rapids to where it is supposed to go (above the first tool cut area), then it rapids to the x/y zero and does a tiny cut (cuts air, barely moves in the x/y, maybe half an inch if that) right above the material surface and ends. At the end, all the zeros check out. Maybe it is switching to metric and cutting something tiny in the X and Y, but even if that were the case wouldn’t it cut down into the Z even the tiniest bit? The visualizer shows the cuts being made where they are programmed to be, while the actual cutting is taking place near x/y zero.
I’m aware of the issue of changing the $13 to inches and mine is still set to the default setting.
I’ve tried this on multiple programs with the same issue arising.
Depending on what CAD/CAM package you are using you might be able to design in inches and still post process in millimeters. Vectric’s products can do this for sure. I’m not sure about others, even the ones I’ve used, because I adopted millimeters for all my design work years ago.
Anyway if your able to do that you could try it and see if it is a unit problem.
The program I’m running is cutting a 1" diameter pocket, and then putting a round over on the pocket. Just a short program to try to isolate the problem. The first operation runs as it should, and the g code itself doesn’t appear to have anything weird going on. So I don’t believe there is an issue with the output from vectric. Uploaded the gcode for reference.
It feels like you have a variation of the tiny visualisation problem some ha e reported.
The solution to this has always been to use the grblmm post processor.
Since I don’t use inch nor tool changes, I have not encountered these problems, but it seems that grbl and converting to inches can create a multitude of weird behaviour that can be mitigated simply by using the gbrl(mm) post processor.
I see that your G-code is using inches and was made with Vectric. I suggest trying the grbl (mm) post processor in case it’s some kind of unit problem.
As far as I know you can design in inches, post process with mm, and still see inches in gSender with ‘Carve screen units’ set to inches in the configuration.
Using G-code in millimeters is more accurate because grbl only uses so many decimal places. I don’t know the number but in any case any fraction of a mm is 25.4 times smaller than the same fraction of an inch. I’ve heard that it can lead to problems with G-code that uses arcs. I don’t think the accuracy is part of your problem but it’s good info to know IMO.
I think inches are a second class citizen in the world of CNC so maybe, fingers crossed, using the mm PP will work.
I ran the program one more time and examined the code output in the terminal window. It seems like the tool change routine is mixing in some G21 (mm) codes and never goes back to G20 (inches).
It’s strange that I haven’t found anyone else having the same issue, I’m sure there must be other people in the US running inches and tool changers. Maybe I didn’t arrive at the right search terms to find them.
I agree that it looks like I’ll have to reprogram my brain to think in mm going forward.
