Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: HeliOfAGuy on July 13, 2018, 11:55:13 AM
-
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
-
Hi,
I use an ESS and I do have a little filtering on the probe. I also have a 500pF capacitor on the input pin.
While its true you don't want excessive filtering which would slow the 'probe strike event' modest filtering is fine.
Craig
-
Thank you Fledermaus. I'll try your routine if my other efforts prove to be unsuccessful. The default size of the bore gauge is 1 inch for this XY Offset Calibration. My bore gauge is nearly 2 inches, and I'm wondering if that may be part of the issue the amount of time it takes to travel that larger distance before the probe strike.
I'm out of town, so once I return home, I will try a faster approach speed first, then try some debounce if the faster approach speed doesn't resolve it.
So grateful for all the responses. Thanks to all for your help.
-
The default is just an arbitrary number. In my system it would have been 1mm! Seriously, the diameter can be any size you choose, and the time it takes doesn't detract from correct operation.
Allan
-
That's good to know. That's how I would expect it to work, but I'm still new to this, and still learning. Thanks again.
-
I added 500 to the noise filtering of my 3DProbe pin and went from 20 to 30 approach speed in the probing, and it worked! Thanks to all who contributed. Now, I can move on to more productive things.
-
Glad to be of help
-
Pleased you got it sorted.
Allan