Hi Steven,
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.
Heres more on post processors.
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.
Worth a try, no?
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.
Thanks for the responses
Thanks for your post. I installed a TLS on my LM MK2 w/ SLB this afternoon and was having the same issues. Changed $13=0 and everything works perfect.
could you please explain in a different post on how you implemented rapid change atc in Gsender?
Just bumping this since I think thereās still something trickey that might be hiding in the tool change procedure for $13=1 setups (though of course that can just be changed to $13=0 in the meantime)
What Cad/Cam software are you using and what post processor ? Iā was able to repeat your issue in vetric by drawing in imperial then saving / generating gcode in metric pp .
I believe this is a scaling issue not being converted correctly between mm / inches . In my experience [$ 13 =0 ] makes no difference with this particular issue .
There is code in the tool change routine that persistantly returns it to metric mode and I donāt know if thereās a work around. So I just changed my post processor to a metric version and itās working now.
For what itās worth, my $13 is on the default setting.
Iām using vcarve pro. As I said my reply to Chris, I resolved the issue by changing to a metric PP.
Doesnāt seem to matter if I draw in metric or imperial. The issue is in the tool change code reverting to metric repeatedly during its canned routine
Hi all, since weāre gearing up for a new gSender Main release Iām digging through older topics that fell through the cracks to see if the problems are now resolved on new gSender or gSender Edge versions, or if they still are occurring and if so then weād like to fix them up promptly if we can.
If you can give any response in the next week or so itād be greatly appreciated 
Iām running into what I think is the same issue as Sparky1 much higher in the thread.
My Altmill tool setter is at the machine home (X0, Y0) in the back left corner, and is one of the abundant Aliexpress ones that stands 67mm tall.
When I set my workpiece 0 and start the job, the initial tool probe wizard fires up and takes the machine back to above the setter, it rapids down to the seek position, and then throws Alarm 2 before probing.
Iām wondering if this is because the workpiece Z top is higher than the tool setter?
The code in the terminal shows all the positioning being machine coordinate (G53), but then the probing distance for Z is -122 which is a lot farther than the āmax probing distanceā (I have default set):
(Toolchange initiated)
ok
G91 G21
ok
G53 G0 Z-10
ok
G53 G0 X0 Y0
ok
G53 G0 Z-50
ok
G38.2 Z-122 F150
ALARM:2 (Soft limit alarm. G-code motion target exceeds machine travel. Machine position retained. Alarm may be safely unlocked.)
[MSG:Reset to continue]
Iām not sure how the Z-122 is calculated.
I tried to debug this a little further by myself, and am even more confused 
As far as I can tell, the probing distance is being computed here: gsender/src/app/src/wizards/automaticToolchange.tsx at master Ā· Sienci-Labs/gsender Ā· GitHub
This sounds like it should cap the input parameter at the maximum possible, but I donāt even see the input parameter being used in the method. It looks to always return the max (machine travel - workspace tool change position [the z of the toolsetter in settings?] - 2). The ā30mmā of probe distance doesnāt seem to come into play in this method or where the value of it is consumed and put into the gcode.