How do I do a manual tool change?

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

is it one cent for me and one cent for him?

Hello guys, I'm new in the CNC world in general.

Is it worth it to try out this solution with 2.8 version or is it better to split my code? ...or any other suggestions

Thanks in advance

Can you ask a question that does not require us to watch a video to understand what you are asking?

And is your query really related to this thread?

Oops sorry, you are right!

The video was copied from a previous page of this topic.

But, by using the latest version of Freecad Path I can easily split my files. So, manual tool change is really easy now and I don't need to make any changes related to this video.

Thank you for your time!

andypugh wrote:

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

Thanks Andy, that sheds some light on things. I'm working a CNC converted little bench-top mill, and just milled my first part last week. Since I have no probe or preset tool length option at the moment, I'm running into the problem of resetting zero for a new tool too. I overcame the issue by creating a  separate setup in cam for each tool. Being new to this I'm well aware of my ignorance here. Is there an easier way?

I'm no programmer, but I had a couple thoughts after reading the article WhyManualWhilePausedIsHard.

The first was, would it be possible to look ahead for the tool changes in the G-code and have the queuing of upcoming moves paused at each tool change so there's nothing in the queue after the tool change.

The second was, if the above can't work due to previously calculated variables, could the entire program be restarted with the new z-zero for the tool, with the motion controller inhibited (so nothing actually moves) and the feed rates somehow ignored (so it runs quickly); then stop at the tool change line in the program, re-enable the feed rates and the motion controller, and continue the program with a new tool, new z-zero and updated variables?

I'm really out of my element here, but thought I'd just put that out there.

Note that the "Jog while paused" page was written in 2010. There have been changes since then including: linuxcnc.org/docs/stable/html/man/man9/moveoff.9.html
But this does not seem to be relevant to the question of manual toolchanges.
(I don't think that LinuxCNC tries to maintain the queue through a toolchange. If it does, then this seems an unecessary complication)

I generally arrange my machining as a separate G-code program for each tool anyway, as it makes re-starting jobs easier. And sometimes it is easier and quicker to swap parts than tools.

Without a tool length probe I would suggest carrying on as you are, one G-code file per tool.