How do I do a manual tool change?

Vladcronos wrote:

Nope, it is possibly less than two lines, all you need to do is stop disabling joging controls and let user overwrite Z0

The underlying difficulty is described here:
wiki.linuxcnc.org/cgi-bin/wiki.pl?WhyManualWhilePausedIsHard

But, really, if you don't like LinuxCNC, have your money back, and move on.

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.

Vladcronos wrote:

I do not know why one would need to pause like that.

If there was only a way to find out. Oh yeah, I know let's check the article:

If the tool breaks or swarf wraps 1 inch into a 10 inch long cut, you need to stop now.

See, there is a very valid reason why one would want to do that.

Vladcronos wrote:

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

You can already do that, but you didn't want to do that.

Vladcronos wrote:

or for example execute a RUN FROM HERE command assigning a line number.

Again, you can already do that, what's holding you back?

Vladcronos wrote:

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

The article is supposed to show you that it's not as simple as "just 2 lines of code" aka "jogbutton.enable = true" and "touchoffbutton.enable = true"

The article is supposed to show you that you shouldn't make assertions about stuff you don't understand. Just because you can't grasp the needed complexity, doesn't mean there isn't any.

Vladcronos wrote:

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.

Almost like that's exactly what I said. See, adding your proposed "solution" of splitting the gcode file etc. adds not needed complexity that is a worse solution in the first place as you're able to understand now that you yourself got the better workflow. It was merely you being used to the ugly hack with mach that made you blind to the obviously better solution.

        offensive comment removed