My first post here in this forum.  I'm just getting my home-built CNC machine running.  I'm using Win7 64bit with 4GB of RAM and a Corei5 processor running Mach4 Hobby at the 3804 level and an ESS Plugin at 220.  I'm using a 6-axis screen set.  I have a bore gauge 1.89955 inches that I'm using for this.  When I start the XY Offset Calibration, it starts the probing process, I will get at the most 3 of 4 strikes of the probe on the first side of the 4 that this probing process wants to do on this bore gauge.  I then get this message in the History Display: Can't transition from PROBING to OPERATION.  after Mach4 goes Disabled.  I have run the demo G-code programs that come with Mach4 through this machine in testing, so I know this machine is somewhat functional.  I just don't get why this probing function is giving me problems.  I'm seeing the G31 probe light up when the probe hits.  My probing signals seem to be working.  I'm using a 3D Probe for my G31 probe.  I've tried reinstalling 3804 and completely reconfiguring my profile, I even tried installing 3805 Beta to see if that makes any difference.  Are there any other files that MACH4 might save elsewhere other than the MACH4Hobby folder on the C: drive that might be causing me problems?  When I reinstalled, I renamed the MACH4 Hobby folder on C:, and let the reinstall build a new MACH4 Hobby and then reconfigured my profile and copy over the license file.  Wondering if anyone else has had a similar issue with this probe routine.  Any thoughts would be appreciated.

it could be a few things

try a small amount of debounce on the price pin
try a slightly faster approach speed


it looks like the probe signal is being miss read and mach 4 thinks ( I know it cannot think ) it is seeing 4 strikes

in the past before W9 got the ESS to do probing correctly mine drove the probe down in Z trough a 12 mm MDF test piece and smashed the probe tip ( its not a simple touch one but a 3d probe with a hammier probe tip that I made )

Thank you for the quick reply.  Not sure what "debounce" is or where the "price pin" is.  Sorry.  You might have to be a bit more specific for me.  I did think about the speed of my computer compared to the ESS, and thought there might be a bit of a mis-match in speed with the ESS being slower than my processor.  I might have to synch up the 2 differently somehow.  I'm not sure how to do that, yet.  I'm still learning.  That's what's fun with this, though.

I think he meant to say "probe pin". Check the ESS plugin for a debounce setting.

Computer speed has nothing to do with it.

Thanks Gerry

Darn this spell checker I may be dyslexic but I think this iPad is worse

Haha, I hear you with the autocorrect stuff.  Gets me into trouble every time.  OK, I know where the probe pin is in the ESS plugin.  I'll look for the debounce setting.  Thanks guys.  I'm out of town this weekend.  So, I'll check it out once I get home.

I don't believe the ESS v220 plugin in Mach4 has a debounce setting that I can see.  The Pins Config tab has a Noise Filtering setting in milliseconds that can be entered.  Is this the same or similar thing?

Hi,
yes that is the same as de-bounce.

Craig

Thank you, Craig.  Documentation for the ESS suggests not to use noise filtering on probe pins.  I'll try using a faster approach speed for my probing routines first to see if that fixes my problem.

Did you look in the History window to see if an error such as "Probe obstructed" or "No contact with probe" immediately preceded "Can't transition from PROBING to OPERATION"? The latter may well have occurred simply because Mach4 had by then been disabled.

The controller is bound fairly closely with probing, and I don't use the ESS, but I have found that with certain probes the technique used in the mcProbing.lua module to determine the success of a probe strike does not work. This might explain why approach speed etc. seems to be a factor for some users. The correct way to test for a strike is to compare the commanded destination with the reported strike point. If a strike occurs within the commanded distance, these will differ. If no strike occurs, they will be (approximately) equal. I say approximately because I have found that they can be subject to small rounding errors such that testing for equality will invariably fail.

If you would like to try this approach, here is the code I personally have found reliable:

function Probing.CheckProbeStrike(ok, ProbeTo, ProbeReg, Hit)

-- AW Test for strike using position data as Probe signal can give the wrong indication
-- AW ProbeTo is commanded probe position
-- AW ProbeReg is the register containing the recorded strike point.
-- AW Units of ProbeTo and @ProbeReg must match i.e. user or machine units
-- AW Hit = non-zero indicates that a strike is expected,Hit = 0 that probe should remain clear

if not ok then; do return false; end; end
local inst = mc.mcGetInstance()
local EndPoint = mc.mcCntlGetPoundVar(inst, ProbeReg)
--local probeHit, rc = mc.mcCntlProbeGetStrikeStatus(inst) -- This doesn't work
--if (EndPoint == ProbeTo) then -- This doesn't work
if (math.abs(EndPoint - ProbeTo) < 0.0001) then
-- Probe failed to strike
if (Hit ~= 0) then
mc.mcCntlSetLastError(inst, "ProbeTo: " .. tostring(ProbeTo) .. "  EndPoint: " .. tostring(EndPoint))
mc.mcCntlSetLastError(inst, "Probe: No contact with probe")
ok = false
end
elseif (Hit == 0) then
-- Probe struck
mc.mcCntlSetLastError(inst, "ProbeTo: " .. tostring(ProbeTo) .. "  EndPoint: " .. tostring(EndPoint))
mc.mcCntlSetLastError(inst, "Probe: Probe was obstructed")
ok = false
end
return ok
end

My probing module is highly customised, so you would need to adapt this and the existing CheckProbe function calls but it should suffice to give you the general idea of what is needed. Take note that this must only be used where a G31 has been issued: at other times it is  appropriate to simply test the probe signal as is done in the standard module. You could initially try this approach for the calibration functions and expand it to others if you have any success with it.

Allan