Z axis height at end of cut

Phill, could the Z axis be retracted to the maximum height at the end of a gcode file? At the moment I think it goes to probe height.
This causes havoc on a water table as it splashes water everywhere due to the post flow. Very bad if it is near the edge of the table. There is a lot less splash when the torch is further away.

rodw wrote: Phill, could the Z axis be retracted to the maximum height at the end of a gcode file? At the moment I think it goes to probe height.
This causes havoc on a water table as it splashes water everywhere due to the post flow. Very bad if it is near the edge of the table. There is a lot less splash when the torch is further away.

Yes, I know what you mean, it is something I have thought of before. It doesn't even look right when you see it in a sim.
Technically it does go to max height at the end of the gcode which is when it sees the end of a program from a M2 or a M30. The problem is the the last X/Y motion obviously need to be before that.
I have had a quick look a couple of time previously to see how it could be done but didn't see any obvious way to do it so just put it on the backburner.
I think we need some way to distinguish the last M5 in the file. I am pretty sure gcode cannot set HAL pins, only read them otherwise that could be a way to do it.
It could probably be done with a M code calling a bash script that sets a HAL pin but that seems a bit clunky and I am not sure how the timing would pan out. I do some pendant buttons like that for probe test and goto Z max etc. and it works well but of course there are no timing issues because there is no motion at the time.
Ideas welcome...

I think doing it on a M2 or M30 would be OK. While the torch is moving the splash is not too bad. Unless you put it on a digital pin so we could add it to the end of the file. I try and remember to add a parking code to the middle of the table in Sheetcam but if I forget it goes back to the edge and makes a mess

That is how it works now, the problem is the M2/M30 is not issued until the last X/Y motion is complete. That is when it does the last move up to the Z starting position.

phillc54 wrote: That is how it works now, the problem is the M2/M30 is not issued until the last X/Y motion is complete. That is when it does the last move up to the Z starting position.

I think that would be OK. Just make it go to max height

But it does that now. Am I missing something?

Mine definitely doesn't. I'll upgrade and see how it goes but it won't be for a while. I pulled the control box off to do a bit of an upgrade. I sent an extra box off to powdercoating this morning so it might be a couple of weeks.

OK.

On another note I have been doing some experimenting with material changes and the material actually changes a lot quicker than I thought. I have strung together a list of material changes with no wait on the M66 (M66 P3 L0) and no other active code and you can see the materials changing. I haven't had an error yet.

These were the load times:
0.0884439945221
0.0435960292816
0.0502989292145
0.0375521183014
0.0477669239044
0.0407938957214

Again this is putting me in a bad position, as i am really against adding features that are pretty much useless to most users of PlasmaC and complicating everything from setup to support for Phill.
That should be easily done in post processor by adding G0 or G1 and a Z value to go to at the end of the gcode file.
Or as i have done it, set the probe heigh to something lower than the Z axis max limit. I have it at 150mm and the probe speed set to 4m/m so it is very fast at moving up and down, but the very slow retraction speed still remains, making all the efforts to build a very fast machine void. This is an issue when using floating switch, not so much when using ohmic probing, as ohmic needs to be done much slower. Most users of PlasmaC use floating type probing, not ohmic.

Tommy you forget that Plasmac strips out any Z axis motion code. I have not tried but I don't think I can simply add some g code to go to top of the Zaxis.