I m trying to do a Boss Probing using the capabilities built into Mach4 but it doesn't work. All it does is move the gantry to the positive Y (plus the Approach value) location and then stops. What it should do is move to the max Y position, drop to the Z position indicated in the UI an then probe in the reverse direction until it hits the outer wall.

When I debug further, I see that the return code for the GCODE_EXECUTE_WAIT probing calls returns the dreaded MERROR_NOT_NOW error code !

Is this a known issue and is there a resolution

The mcProbing code is : (snippet)


   ------------- Probing sequence -------------
   local rc = mc.mcCntlGcodeExecuteWait(inst, "G0 G90 G40 G80")
   mm.ReturnCode(rc)
   rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G43 H%.0f", OffsetNum))
   mm.ReturnCode(rc)
   local ProbeTo = ProbeToYp

   mc.mcCntlSetLastError(inst, "BOSS Probe A :"..string.format("G%.1f Y%.4f F%.1f", ProbeCode, ProbeTo + Approach, FastFeed))
   rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f Y%.4f F%.1f", ProbeCode, ProbeTo + Approach, FastFeed))
   mm.ReturnCode(rc)
mc.mcCntlSetLastError(inst, "BOSS Probe A, rc = "..rc)

>>>>rc = 0


   rc = Probing.CheckProbe(1, ProbeCode); if not rc then; do return end; end


   rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f Z%.4f F%.1f", ProbeCode, ZLevel, FastFeed))
mc.mcCntlSetLastError(inst, "BOSS Probe B : "..string.format("G%.1f Z%.4f F%.1f", ProbeCode, ZLevel, FastFeed))
mc.mcCntlSetLastError(inst, "BOSS Probe B, rc = "..rc)

>>>> rc = -18 !!

   mm.ReturnCode(rc)
   rc = Probing.CheckProbe(1, ProbeCode); if not rc then; do return end; end


   rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f Y%.4f F%.1f", ProbeCode, ProbeTo, FastFeed))
   mm.ReturnCode(rc)
mc.mcCntlSetLastError(inst, "BOSS Probe C : "..string.format("G%.1f Y%.4f F%.1f", ProbeCode, ProbeTo, FastFeed))
mc.mcCntlSetLastError(inst, "BOSS Probe C, rc = "..rc)

>>>> rc = -18 !!


   rc = Probing.CheckProbe(0, ProbeCode); if not rc then; do return end; end

Seems like there is a very common issue with many of the probing functions in the mcProbing.lua file. I dealt with a similar issue in the calibration and I'm just looking at the same issue in the external corner probing routine. Who ever wrote these scripts seems to have used a G31 command for moves that are just setup moves in some cases

When I debug further, I see that the return code for the GCODE_EXECUTE_WAIT probing calls returns the dreaded MERROR_NOT_NOW error code !

MERROR_NOT_NOW means that you are trying to do something when the state of the machine is such that it cannot perform the task given.  So, what state is the machine in when you get MERROR_NOT_NOW?  mc.mcCntlGetState() and friends can tell you. 

Seems like there is a very common issue with many of the probing functions in the mcProbing.lua file. I dealt with a similar issue in the calibration and I'm just looking at the same issue in the external corner probing routine. Who ever wrote these scripts seems to have used a G31 command for moves that are just setup moves in some cases

Using G31 moves is VERY common when a probe is loaded into the spindle.  It is called a protected move.  What if you told the machine to move in a direction that would crash the probe with G00 or G01?  It would break your poor probe stylus and possibly your entire probe!!!  Not too good.  If you move the probe around with G31, even if you hit a workpiece clamp that you forgot to remove, the probe will simply stop and not grenade.

Steve

That's a very good point about using G31 for all the moves with a probe. There must be some underlying set up issue then because as I said and as it came up in a few other threads recently that the set up moves in some of the probing routines werent working as it would do the pre probe moves and then spit an error when it never touched anything even though it wasnt meant to

That's a very good point about using G31 for all the moves with a probe. There must be some underlying set up issue then because as I said and as it came up in a few other threads recently that the set up moves in some of the probing routines werent working as it would do the pre probe moves and then spit an error when it never touched anything even though it wasnt meant to

What I think happens is the probe is too sensitive to machine vibration when moving in setup moves (usually faster moves than when probing for a surface).  Or noise on the probe input.  In any case, I would call it false triggers.  I see a lot of people trying to run mechanical probes on 3.3v or 5v. and that ALWAYS leads to false triggers.  Mechanical switches need more than logic level voltages to work properly.  That is why the machine tool voltage standard is 24v. 

My machine probes just fine using an old Renishaw MP3 on a 24v imput.  It only triggers when it hits something.

Steve

I'm pretty sure that's not the case for me as all the g31 setup moves end with:

ESS starting Probe 0
ESS: Failure! Probe0 never hit or the allowed distance was traveled. Switching from PROBING to NORMAL state.
ERROR: No contact with probe

What happens if you manually run a G31 in MDI? 

Steve

And touch something or just let it get to the end without touching? A normal probe move that hits the part works just fine. If I G31 with nothing to touch I get that answer.  That error was coming during the Probe XY or radius calibration on the move to the Z measurment height before the actual probing of the bore

In newer versions of the ESS there's a setting that'll cycle stop after a probe failure. Possibly that could be impacting your probe routine?

Hello,
To anyone reading this post.
We're changing the way that we probe in MACH4. However don't worry the traditional moves will work and nothing is being fundamentally changed.
Probing has been plagued with issues for as long as I've been at NFS (99% of the time the issue being electrical noise...) and I'm rebuilding the programming behind our probing screen and making it a much more guided experience. This will avoid any confusion as to what is happening, moving forward you will select the operation you'd like preformed and then it will walk you through the process the whole time reporting all values that need to be retained into pound vars, this way we can easily troubleshoot what's happening behind the scenes (along with the logging window).
We tried to make a experience where you enter the values and hit start and then the machine does it's thing, however we find that users with issues don't know what part of the process isn't working properly. For instance, is the machine not doing what it's told or is it a noise issue etc.
This is being worked on and it's programmed for the most part and the GUI is being designed very shortly.
All in all this sums up to me saying, we will have a better user experience for probing soon and hopefully it will allow us and our users to diagnose the issues at hand much faster as you will know exactly what's happening every step of the way.
Sorry this has been an issue