How do I do a manual tool change?

I feel your pain with linuxcnc, everything is hard but have patience it will become easier by the time you are finished (but its still hard). The documents are very well documented, but in the same way a microchip is well documented. All the basic(and many not so basic) necessities of a modern cnc can be done with linuxcnc, its been around for a while with some very competent contributors but some basic things are not as easy to implement. I am not a pro hacker, but my reading has led me to believe that jogging and setting a new tool offset in the middle of a program is more than 2 lines, and since there are many ways to skin a cat with linuxcnc there are many different solutions.
Are you using some kind of tool height probe with a digital input or are you moving the endmill to the top of the workpiece and setting it that way?
To get your machine running with manual toolchange for the time being, I can suggest when you encounter a toolchange in your program, to stop the program, do your normal tool change procedure manually with touchoff, and resume your program from the toolchange position to ensure all your new offsets/gcode headers are in effect. By that

The best starting point will be the linuxcnc sample configurations probably. Try running this sample configuration to see if it behaves in the way you expect your toolchange to act, and then you can work from there to merge it with your current configuration. the path to the con

I am sorry that I am just used to a much higher standards, let's blame me for that.

That subroutine path was OFC setup before, I have no idea why it was again rewritten somehow, despite that I have not touched any auto configurators like pncconf. You really think I am so dumb to just skip one step in documentation, and do that 3 times in a row? That's a bold assumption I must say. The crap overwrites itself because of poorly written and explained code, and I relate that mostly to gmoccapy and not the linuxcnc itself, as native setup was a breeze until gmoccapy mess started. The guy created some python scripts there which I have no idea what they are doing. Every single time I filled the [RS274NGC] section carefully, first time I made a mistake to use pncconf and it was overwritten, my bad. Both following times it just overwrites itself from some other location.

jogging and setting a new tool offset in the middle of a program is more than 2 lines

Nope, it is possibly less than two lines, all you need to do is stop disabling joging controls and let user overwrite Z0, that's how it is done in mach3/4 for decades, works easy and simple. You basically need to just jog and then reset Z to zero. Both of features are already there, just disabled during program run. Resetting Z to anything is not a problem, program will just shift position and keep going, I have done that for years on mach4 router.

 I can suggest when you encounter a toolchange in your program

I dont even want to think about such PITA to be honest. This is going to turn every machining into a pure misery. Not even gonna mention that gmoccapy GUI doesn't even let me monitor which code line is actually running at given moment and scroll isn't even working. If I wanted that kind of misery I would be better off machining my complex shapes on a manual mill lol. This is the same solution as mine that I do now, just run separate programs for each tool, but that's a sick joke... If I ever knew that would be a case with linux cnc to not have such basics, i would never even touch this. Sadly now I am stuck with only linux compatible hardware.

I would recommend placing Z0 on the bottom of the material

Cant imagine how I would touch off the bottom of the stock later then


 

"Cant imagine how I would touch off the bottom of the stock later then"

I assumed you were using a sensor. If this is the case, you have to determine the offset from your sensor switching point to your material bottom edge once (I assumed that this is always the same) and enter it in the macro under parameter #1814.

No, I do not think you are dumb, there where a lot of new posts before I could finish writing my post and now I am behind the curve as to what is going on. Its harder to understand where you are having a specific issue than it is to fix it
If I intend to face a part, I usually make the top of my part zero in cam but make my g54 z0 below the surface of the material I touched off. this after facing, my z0 is at the cleanly faced top surface of the part.


the forum ate my post before I could finish writing it. it was updated recently and it has a few issues.

I feel your pain with linuxcnc, everything is hard but have patience it will become easier by the time you are finished (but its still hard). The documents are very well documented, but in the same way a microchip is well documented. All the basic(and many not so basic) necessities of a modern cnc can be done with linuxcnc, its been around for a while with some very competent contributors but some basic things are not as easy to implement. I am not a pro hacker, but my reading has led me to believe that jogging and setting a new tool offset in the middle of a program is more than 2 lines, and since there are many ways to skin a cat with linuxcnc there are many different solutions.
Are you using some kind of tool height probe with a digital input or are you moving the endmill to the top of the workpiece and setting it that way?
To get your machine running with manual toolchange for the time being, I can suggest when you encounter a toolchange in your program, to stop the program, do your normal tool change procedure manually with touchoff, and resume your program from the toolchange position to ensure all your new offsets/gcode headers are in effect. By that I mean finding the position in the program where you left off and doing said toolchange, and using right click run from line on that position.

If you have some kind of tool length sensor, the best starting point will be the linuxcnc sample configurations probably. Try running this sample configuration to see if it behaves in the way you expect your toolchange to act, and then you can work from there to merge it with your current configuration. the path to the sample config with be sim>axis>remap>manualtoolchange
Try that in simulation mode to see if it is what you are looking for. you can read about the function here
github.com/LinuxCNC/linuxcnc/tree/master...h-tool-length-switch

I do not remember if the premade linuxcnc images for the RPI4 have a globally installed version or not, but I also do not know where the files hide for a global installed version. I do use it very often but when I do I usually have to search. To find these files the best way is to use the find files on the rpi4 file browser. open up the file browser and click the "Go to parent Folder" button (arrow pointing up) until you are in the top level  then under tools use the find files and locations of the linuxcnc files, because the exact path might be different from system to system. 

I understand your need for wifi, I cannot help you exactly, but i when I find an issue that is not common, in a common configuration, it is usually raspberrypi specific, as many seemingly common issues for rpi are not issues for regular pc. I do know there are many users using Ethernet mesa cards with the rpi4 so I would suggest looking in some of the RPI threads on the forum.  you might have luck looking at the rpi wifi documents. 

nope I was planning to just touch a surface with a tool itself, always worked fine before and very reliable and simple. Dont need any offsets and other unnecessary overcomplications. I have already electrically isolated vise from the machine body and can use that now as endstop/sensor.

Anyways, thanks a lot guys, gonna go have a dinner and then I will start a whole new config entirely from the scratch, use this code that you gave me here and not going to use anything from gmoccapy at all. And see where it brings me!

If you are using your isolated vise as an automatic tool touchoff try using the sample config i mentioned and work from there.

I dont know what led you to the conclusion thats its just 2 lines to change, but im sure if it was that simple one of the many other users trying to do this would have changed it by now. If you do know which 2 lines need changing, please post them , and then this issue can be fixed.

"I have no idea why it was again rewritten somehow, despite that I have not touched any auto configurators like pncconf. You really think I am so dumb to just skip one step in documentation, and do that 3 times in a row?"

Yes indeed, I think this is how dumb you are. This fits exactly what I've seen from you so far. You call simple configuration "hardcore programming". You completely misevaluate the pricing of hardware. You have no idea what use cases were considered when writing the software yet talk like you're an expert. Again, the pattern is clear, you talk a whole lot of shit about stuff you have no idea about.

So this is how it most likely went down:
You fiddled with the stuff and you over wrote and then you most likely blamed someone for that (definitely not yourself). Then you went to the docu and you filled out the [RS274NGC] section again but you didn't click on the link like the first time and you didn't add the SUBROUTINE_PATH again because you already consider yourself a master of that section of the documentation so you went through it carelessly and indeed didn't do this extra step.
But again as you can't be blamed for anything "something else must have overwritten it". Nope, shit doesn't magically disappear buddy, take some fucking responsibility for once.

Nope, it is possibly less than two lines, all you need to do is stop disabling joging controls and let user overwrite Z0, that's how it is done in mach3/4 for decades, works easy and simple.

You know how I draw the Mona Lisa? I take a brush and a canvas and then I just draw the thing. It's literally so easy you should try it once.
Oh wait, there goes a whole lot more on there. You clearly have no clue at all what you're talking about. I mean you struggle with very simple configuration task why would you ever tell others how easy it is to implement something?
I mean you don't even understand that none of the code you would have to touch for that is linux specific, this is just another cheap arse excuse of yours to delfect responsibility. I have fiddled with the code and I know for a fact it's not just "hurr durr just add 2 lines of code". This stuff is a lot more complex than that. You think this is just a matter of a fucking button being enabled or not? Seriously mate ....

Not even gonna mention that gmoccapy GUI doesn't even let me monitor which code line is actually running at given moment

See, another example of you talking straight up bullshit. Here a quite recent video of gmoccapy in action where you clearly can see that the currently active line of code is highlighted.

the relevant portion of the video is @ 9 minutes 50 seconds

"Cant imagine how I would touch off the bottom of the stock later then"

You don't? You set your bed as 0 and that's it. This is exactly how I'm doing it. I planed my bed and set that as my 0. Now my machine always knows the bottom of the part and every tool is automatically measured after I manually changed it and uses the very same 0 point.
How can this very simple concept be so hard for you to understand?

So I know a thing and have a good understanding how good or bad open source software can be.

See, this is the main problem here. You have a giant ego and you can't handle that you've been shown that you're not quite as smart as you thought you are. You think you know shit, but in reality you have no fucking idea.
You do not get that this is not a question of enabling a user control and setting a variable. You do understand so little about it that you don't even know that the button you see and the machine control run in 2 entirely different processes. See buddy this software is a little more complex than "just set a variable to 0". Yes for your very simple workflow this might be the gold standard but guess what not everyone using this software wants to run a shitty workflow just because you can't handle a more complex and way more efficient one.
Jogging after your tool change to set a new 0 point is a crutch you got used to from an inferior software. It's not because it's the superior work flow but it's just the crippled hack you got used to and now you're throwing a tamper tantrum because you can't have your shitty hack back.
Tool touch off is incredibly easy to set up, it took me less than an hour when I first did it following the video you got linked and it's infinitely much easier. I too wanted to do it like you at first until I learned that this is a shitty way of doing things. Just like I wanted to rehome everytime I started a new program because I didn't understand work offsets. But unlike you I didn't blame everyone else, I realised that I still have to learn a lot about CNC in general and LinuxCNC in particular.

Just think about it, despite you being an arsehole to the docu writer the software dev the hardware dev you still get so much help. So have some self reflection and start acceptiong that YOU are the problem and not everyone and everything else. You are failing not the software not the docu not the hardware.

-

Ah thats good, because I dont know whats going on as I have zero years experience programming as I am a tool and die maker.I also like making 3d printers, I got my first one at the world makerfair 2012 in newyork. But dont worry, a lot of linuxcnc is programed in c and python, so a windows background shouldnt matter. Its really more about why those 2 dead simple things are disabled. Check out some of stuff here linuxcnc.org/docs/devel/html/code/code-notes.html and here github.com/LinuxCNC/linuxcnc/tree/master/src/emc . But say you do change those 2 lines to make it joggable and and set a tool variable, what happens after that? Im just a simple toolmaker, but from what I understand, even if you could jog and set a tool variable, the gcode will not simply catch up to the variable at any given time once in automatic mode. I do not think you can pass variables after you have hit the auto button, and still have them take effect. Once the program is started, all those variables are calculated before hand using the tooltable/params and the programs fate is sealed until the machine comes out of auto and the program is re-interpreted with the new variables. So to pass any variables mid program, you will need to do things my feeble toolmakers brain cannot comprehend like coming out of auto or queue buster or maybe something to do with task.
There are many users using linuxcnc, and im sure your issue is not unique, so please exercise patience, read some of the many examples from other users online using google and in the documents/github , and understand that linuxcnc is not as much lowering standards as it is lowering expectations of everything being as simple as the less capable controller software. Other things are more like "paint by numbers" and linuxcnc is just a blank sketchbook.

About your vise and spoil board, that is good info to know, since these heights are not static. It is important to include all relevant information when asking for help because understanding the problem from your point of view is important to finding a solution. Considering setting up a static location for a toolsetting position that does not change from setup to setup. Im still rather unclear as to how you are trying to do this, but are you trying to change the g54 z offset or are you changing the tool height offset? Please be very clear on what exactly you are trying to accomplish in detail. Over generalized statements and opinions are unhelpful in the troubleshooting process and it is important to keep your topic specific to the issue you are trying to solve. Good luck with your project, my cnc is about to enter into the same phase with automatic manual toolchange offset.