Adding a tool height probe check?

I was wondering about protecting the bed in a shared community shop with a lot of casual users who make mistakes.

Is it possible to require using a static tool probe sensor to check the tool height, but not zero the Z with it- instead, just check it against the lowest Z coordinate used in the file?  If it's more than 0.5mm into the spoilboard, don't allow it to run.  This accommodate top and bottom datum users and is just a final sanity check. 

It actually would not entirely replace the Z probe for tool setting.  It would be a good way to set bottom datum specifically too, but lots of people use top, and the wireless toolsetter would still be the best way to probe for top datum.  Quick, accurate, mostly foolproof.

To do this, it would need to have already evaluated the file for max depth.  I do note that if you load a file, then rehome you work origin afterwards, the drawing on-screen will not update unless you reload, and this would require the latest shifted lowest-Z-in-file to be available

Is this something that could be done in the HAL?  But there's currently no parameter loaded with that lowest-Z-in-file value.  I guess this would mean working with the LinuxCNC source code and recompiling?  Would we just put lowest-Z-in-file in an unused parameter slot, but still do the motion with a G-code file?  Or implement the whole complicated concept in the LinuxCNC program?  

I want to use an optical time-of-flight rangefinder on the front of the spindle, pointing slightly in front.  They're not a motion sensor, this is very accurate at rangefinding and can detect the collet wrench specifically. 
So there's now a Z-checked boolean state along with the actual tool height probe value in machine coords, with the following ops:
Starts Z-checked boolean state  in the off state upon LinuxCNC boot.
Resets to off any time rangfinder sees an object at the level of the nut specifically.  It will always be reset when the user uses the collet wrench on it, and pretty unlikely it would be triggered by anything but a bit change.
Sets when the Z-check routine is performed and the tool height value is stored at that time..  This will either be manually requested, or it will do a check automatically upon any start of g-code but only if it's not set.

The Z-checked state is just whether the current tool height has been checked.  To run G-code, it must be true AND the current lowest-Z-in-G-code file and the current work origin Z vs the value.

The Z-checked state will not clear just for loading a new G-code file or resetting your work Z.  However, the rule remains, it will not enter interpreter mode unless Z-checked state is true, and the current  current lowest-Z-in-G-code combined with current work Z offset show the bit's not going to go into the spoilboard.

This makes an enormous amount of sense.  The probing is somewhat time-consuming as it would need to jog to a corner of the bed to test, and you only need to do it every time the bit is changed and we don't want to waste that much time on every Play attempt.  In most cases people will manually request the check-Z routine after changing the bit.   People reload G-code files and move the work Z offset all the time and it's not necessary to check toolheight again for any of that.  Only restarting LinuxCNC, rehoming machine coords, or toolchange-detected requires rerunning the check-Z routine.  My choice would also be if you press Play and Z-checked is false, it will automatically run the check-Z routine.  So you can be a pro and request it manually when you change the bit, or, if you don't, it'll do it for you when you try to run.

It can't protect against a user not tightening it enough and the bit backs out while cutting making a wrong tool offset.  That's relatively quite rare though, I think.  It would be absolute protection against all other user errors (loading a top datum G-code file but setting the work Z offset on the machine bed, forgetting to set the work Z offset, or setting it wrong somehow).  

Thoughts?  Big post, I know.  I really like this concept though.  This would be such a game-changer for makerspaces.

Yeah I can see that variables, subroutines, and changes in fixture offsets would be hard to track. When LinuxCNC loads a file to display onscreen, it parses through any and all of that. It seems like it would be really tricky to replicate all that functionality instead of just having that native code evaluate for lowest Z while parsing it.

Hmm, what about redefining the work box? If the ini file says that Z=-0.5mm is the lowest it can go in machine coords, if there's anything lower than that the g-code is out-of-bounds and won't run. That's the sort of response needed.

But that would mean resetting the machine Z origin with the bit change. That's weird and I don't know how that would work. And, hmm, would that really do what I'm thinking? I was picturing a person sets work offset for top datum and moving the machine Z origin will break that.

I'm only assuming one tool, but it would make sense to calc a rack. 

However, code could switch work offsets.  Any one of them could change either way if their work offset changes, as well as where it finds the tool at.  So, it would need to track the lowest work coord used on each of 9 work offsets and recalc if that offset changes, and do a no-go if any one of the coord systems will be below the spoilboard

--- To do this, it would need to have already evaluated the file for max depth. ---

As you may be aware this will require more than just checking for the most negative Z value in the g-code. It's possible to define an arc in the G18 or G19 plane that will travel lower than any posted Z.


--- This would be such a game-changer for makerspaces. ---

We installed a Z Negative limit switch on the CNC Router at our Makerspace. (It does not have a tool changer or fixed length collets.) The limit switch trip point was on a slide that the user could manually set so his tool tip would never reach the table.

It actually worked pretty well, IF the user bothered to set it ... Same user crashed the collet into his workpiece and the tool into the bed of the machine multiple times because he refused to set it.

Moral of that story is it has to be as automated as possible for a Makerspace due to the varying skills and diligence of the wide user base.