Is there a "no go zone" feature of any kind?

This is a weird-ish question, but LinuxCNC is so vast, I thought I'd ask:

I have a build where I'm making a trunnion inside the same area where the XYZ axis operates. Now that trunnion is growing up to have parts attached to it...

Is there a way to define a "no go zone" within the XYZ build box so that I don't accidentally crash into it?

It would need several different sections, ie, a series of boxes could be defined within which the controller is supposed to know that's not OK and send that 'move would exceed limitations' message if I tried to violate it.

I'm thinking the answer is "with great complexity comes great responsibility..."

But I thought I'd ask.

Cheers. 

Thanks again!

That last suggesting, to use hal to monitor it...

I'm familiar with setting up the game-pad pendant, and so my recollection is that you add some mux-es and ands and ors to the servo thread, and check for buttons and do the bit-math until you come up with a speed to feed into the jogging speed.

So my first thought is kinda redux that thinking: use the ands and ors and current position pins and create a section in the .ini file for limits which the ands and ors are comparing, and have the logic come up with a on/off value which gets net-ed into the Estop pin.

I think it would either have to
A: anticipate the movement somehow, (because if it used the current position, once you tripped it, you'd have no way to un-trip it. {evil grin}) and I'm clueless on how that would work,
or,
B: it would need some 'override' button, say on the jogging device, to ignore the limits and allow moving it anyway. (That's easy to imagine how it works with a final or statement.)

So the second option seems easier.

With second option, I'm thinking the e-stop button on the GUI would just trip on, everything would stop (you are spanked). Then you'd have use your pendant with override pressed to move somewhere where the e-stop button on the GUI trips back off. Then figure out how to avoid that spanking.

Is there another/better approach that comes to mind?

(I'm probably not counting the risk high enough to actually make it to the proactive action of doing this now... when I crash something badly, then I'll probably do it. Sigh. Sometimes it sucks knowing one's own psychology.)