Z axis height at end of cut

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...

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.

But it does that now. Am I missing something?

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.