Brian
i do something like this and then i can run g31 over and over and works
without cntlenable i have to hit the mach4 enable button to run  g31 a second time, or i won't get any axis movement
but i am not having any real problems with the scripts setup like this its the ESS register i am reading for errors

rc = mc.mcCntlGcodeExecuteWait(inst, "G91 G31 Z-"..ZMaxTravel.." F"..SlowFeed)    -- start the z probe if not hit Show not hit and exit

if mc.mcRegGetValue(hreg) == ProbeState then -- check the probe state if ProbeState error probe not hit
mc.mcCntlSetLastError(inst, "No Probe Hit Aborting try a higher ZMaxTravel, or make sure you are over the part") -- send messsage error
mc.mcCntlEnable(inst, 1)
return false -- now exit and abort
    end
 -- probe was hit
Gary

The ESS isn't actually disabling Mach4 when that option is selected, it's only issuing a cycle stop command.

No special hardware needed! I use a drill connected to GND and a circuitboard blank to create a short circuit when the probe touches.
To replicate the behaviour you can run the below code in a button_up script and dont let the probe trigger: (And the ESS needs to have the probe configured and options set as in the image i posted.
rc = mc.mcCntlGcodeExecuteWait(inst, "G91 G31 Z-1 F20")   
rc = mc.mcCntlGcodeExecuteWait(inst, "G91 G31 Y1 F20")   
The above will only generate movement in >Z direction. When it comes to the second line it will return -18.
The only way to avoid this is to add "mc.mcCntlEnable(inst, 1)" between the two lines, then it works.
I tried to dig more into the documentation and as per the statement on the config screen for the ESS it seems to claim that it uses Cycle_Stop which per the API internally Feed_hold. I dont know if this is related to my issue but it is what i have found so far.

gorf23: when you say: "without cntlenable i have to hit the mach4 enable button to run  g31 a second time" i guess you mean you have to press it Twice: first to disable and then a second time to enable or does the g31 without a hit cause your enable button to change state?

Send it into the support guys. They can make that setup and test it tell them I sent you

Is off to the support - They will Check with Andy who is already on top of things...

While i wait for the support i was chatting with Andy on the warp9td forum and this thread covers his response to my problem: https://warp9td.com/index.php/kunena/7-general-discussion/8746-probing-error-bad-behavior-when-probing-fails

Blah , I don’t have an account.

No info on the actual problem but one workaround solution is to use GCode M2010(......)  to disable "disable Mach4 on probe fail" before the routine and enable if again after using the corresponding M2010(...) call. To determine if the probe hit you can use:

hregProbingState = mc.mcRegGetHandle(inst, string.format("ESS/Probing_State"))
iProbingStateValue, iReturnCode = mc.mcRegGetValue(hregProbingState)
I is a better looking workaround but still not a solution because if Mach4 is disabled by ESS during probing with "disable mach on probe fail" enabled - Mach4 is in a state which disables the motion of the machine but without indication. Also if I use this way in my screen script and decide to uncheck the "disable mach on probe fail" it will get auto enabled when i run my script as i can not determine if the setting is enabled or not in code.