How do I do a manual tool change?

the gcode will not simply catch up to the variable at any given time once in automatic mode

it absolutely will, as it doesnt care about that. This is exactly how it works on MACH3/4 for decades software on windows. So that alone is a simple proof. I write gcode all the time, it doesnt care about that. relative or absolute also doesnt matter as you override whichever one is in use and during a tool change pause. I did tool changers on reprap firmware and in klipper for example, super basic and simple to do, thats how I know. Gcode is also no different here.

Imagine it this way, lets just take Z here, as we are not changing the XY. Your tool is currently at 20.00 position and the next step supposed to send it to 10.mm. But now your new tool is 5mm shorter, so you move a new tool to zero, which means a -5.00 in old coordinate, and you zero it out over there. now you have an accurate new zero. then you jog it up into safe area again, as normal. new coordinate is now effective and the gcode still wants to sent it to same old 10.00 position, and it will and everything is fine, because you reset your z coordinate and now it is effectively 5mm lower. That's really basic, which is why I got so frustrated that such basic stuff isn't done in over 10 years. So at this point 10000 people spending 100000 man hours to tune it individually for each of them, instead of efficiently doing this once on github and relief the crowd from that suffer.

so please exercise patience, read some of the many examples from other users online using google and in the documents/github

forums are usually my last destination, I have already spent 2 days on google and youtube actually, as that would be great if anyone has made a single sample setup there. would be much more efficient, but sadly I wasn't able to find anything I could use on the web. Turns out this software isnt actually as popular as I thought, and there are not too many DIY setups in the wild to generate that tutorial base.

as the less capable controller software

I disagree here again, and I am struggling here with a very basic feature that took me around 30 minutes to setup on mach4 for example, here I am struggling for 2 days. How is this more advanced in any way? I can not talk about 5 axis fucntions etc, maybe it is more advanced in that area. But so far for my basic 3-4 axis use the initial setup has been a disaster, thats all I know. And that is exactly due to a lack of BASIC features, how much lower an expectation can be than to have a simple probing preset, i dunno.

but are you trying to change the g54 z offset or are you changing the tool height offset?

Thats exactly the problem, as I have no effing idea myself, 95% of my robotic experience is in 3D printers, where this basic stuff is super easy to jsut write in gcode and hit go. I expected this have been already implemented in the software so I dont have to think about "how do I probe" or "how to code this and that to probe". This is again where the frustration comes from, as it feels centuries behind even mach4, which I bought and its also far from perfect. But over there my biggest problem was bugs and non-realtime USB based control. Now I appreciate much more what mach4 actually offered as a complete package actually lol. How I see a proper software: it asks you for your probe data, position, height etc. Then you insert each tool and it measures it, after you press the button to runt he macro. If software doesnt even do that by itself, thats not a software, thats a half-assed unfinished code to my eyes. Again nothing personal and dont mean to offense anyone, treat it as my personal opinion only.

What I am trying to accomplish is simple, change a tool and be able to continue the program, I am a simple man!

I just finished my day long fighting with wifi conflict with mesa, and it turned out (again) that the guide that I used gave me incorrect settings, and the majority of my troubleshooting was focused in a wrong place, since I trusted and did not doubt that guide settings. Again turned out that I spend time online asking and searching for examples and end up just learning stuff on the way and writing it all myself from the scratch in the end, minus wasted time on the web lol. Gotta go back into linuxCNC docs now, as I admit they are very overwhelming to read, and I did skip most of that. Patience isnt my top skill haha. Imagine machine was already making chips and then I wired the simple probe which put the machine down for 3 days and counting and turned all the setting into a bloody mess. Anyways, I am on AXIS interface now, it is not as "pretty" on touch screen, but as long as it fucntions well, I will be happy. Started a new setup now from the scratch and going to use that macro from above and see what it does. Thank you again for all the time you spent here with me and links! 

isn't their eyes/pupils remarkable? it always amazed me.

As a side note, I have just opened AXIS GUI... omg, it is so much simpler, cleaner and better! At least to a person new to linuxCNC. With gmoccapy I struggled to even find a simple hal monitor to check signals, in AXIS found it in 4 seconds! I have a good feeling about this GUI! I may return to gmoccapy, but later when I am already very familiar with the software.

 in your macro folder

Jan, what would be the default full path to that folder? I am again having silly issues here, where it now crashes not being able to locate this file. I already tried to put it all over config folder, set different paths too, also went into dev folder, found a macro folder there, put it there too, still not able to find a file... And of course debugging isn't showing a full path, because who needs that right lol

NVM, "subroutines" line was missing in your code, I figured it out already haha. Time to test!

A sudden leap forward haha, thanks again guys! Bed time, will refine the gcode tomorrow. Still a draft.

And that's how I wanted it to be done, right on the stock for a true zero.

That article was a really good read.

Thank you.

Tommy, I didn't actually read those useless poems from inventory person. That helps save time. Buy hey, if someone find it entertaining, why nit. You said people read that right? I'll be straight on point next time though, you are right about that.

Andy, that's very weird from the coding and logic point of view. My assumption is that because it is an open source project and was probably coded by a number of not connected contributors, it is already so butchered at this point, that it made it super hard to apply such simple change. Which definitely is possible. As far as your money back statement, I'd love to buy a software at reasonable price (for hobbyist), but there is sadly none available for linux. And it's on me for having that idea to make it all nice and compact with just one raspberry pi, so I am pretty stuck with that hardware, including mesa board also. I have a full HD wide screen for touch control and MACH4 for example has a terrible bug where toolpath and the whole graphic area looks awful and pretty much unusable on high DPI screens. Which was one of the reasons I didn't want to do mach4 again. Another reason is USB connection problems on windows, I have had plenty of those too.

I did make it work almost OK though and then took a break to relief all that frustration! Turned out that Gcode is actually quite more complex vs what we use in 3D Printers, so there was some learning there too. I went back to gmoccapy as AXIS GUI is indeed not useable with touch screen and generally felt like there was zero effort on that GUI at all. Using it helped me understand the GUI structure better tho, as a new user and gmoccapy assumed a lot of GUI knowledge from the user, which i didnt have. Now I have gmoccapy, toolchange kinda works, need to put some more work into a gcode macro for it. I even machined with it already, with 6 tools, kinda like how the actual touch works with stock surface, super nice. I can touch XY the same way too, which is nice to have. No problems with RPI latency so far, despite the warning message in the GUI. Had major issues with tolerance and couldn't find the reason, until I checked my ER32 collets and realized there is up to 150 microns runout there.... crazy. Now ordered some good ones (hopefully) and waiting for them to arrive on friday. 0.0002 inch runout which looks great on paper at least.

Forgot to address this, very nice article and super clear. However it focuses on a pause in a middle of an arc, and with my little experience with actual milling, I do not know why one would need to pause like that. My only concern was a tool change purpose. In which case it will not be a sudden pause, it will be a preprogrammed tool change command. As I see it, if you can easily do that just by simply splitting your gcode file into separate files, or for example execute a RUN FROM HERE command assigning a line number. Thats already there, and it does the same thing (well, except that it doesn't work on gmoccapy at all lol, completely broken), and the only thing that will be needed it either an offset or an updated Z coordinate.

All of aforementioned, as I see it, is not related to the situation described in that article.

With that said, once I programmed a tool change gcode, it is just so much better than doing that manually anyways, so I dont think anyone should even bother with a fully manual tool Z reset. The setup doesnt even need any investment if you do it like I did for example. So its a no brainer simpler and shorter solution anyway.