1
Mach4 General Discussion / Re: Mach4 hangs after G31 probe with no contact using AXBB-E motion controller
« on: December 21, 2021, 12:35:51 PM »Hi,
I have and use an ESS and use probing extensively for making circuit boards.
I have a software utility (Autoleveller) that generates a Gcode job to probe the PCB blank and record the z position of the surface. It will probe a PCB
50 or more times in a grid fashion. If the probe for whatever reason does not make contact before it reaches the end of travel as programmed by the G31
code then the program halts......that's what I would expect.
You have issued an instruction 'go to location z=nnnn and stop on contact and report the z position', if it does not make contact within its given range is that not a fault?
What would you expect Mach to do?.
In the case of my PCBs, if Mach just carried on and entered a -1mm z ordinate, -1mm being the max z extent of the G31 move, then my levelling program would fail miserably
by virtue of poor data.
Craig
Hey Craig, In your application that makes perfect sense. I don't see any fault in your logic. I always appreciate you taking the time to read and reply. You are an awesome contributor to this forum.
I want to explain where I'm coming from not to challenge you, but to hear how you would handle it or what your opinion is on the whole mess.
I also want to say that I bought a ESS and an MB3 as a means to solve this problem since i got no reply or answer back from CNCdrive about the plugin for my AXBB-E.
I havent installed it yet, so the rest of this reply still applies to what happens with the AXBB-E.
Mach Support did respond to my support email and confirmed that it is up to the plugin creator to add the functionality/option of ignoring a no contact condition in a G31.
Their exact response was this
Quote
Hello,
Controllers like the ESS have a setting that allows you to proceed if using a G31 and you make no contact.
By default a controller will error out however unless they've included a setting in their plugin that ignores the no strike condition.
Best Regards,
Trevor
The reason the probing behavior as described above is an issue for me is that the Mach4 probing scripts are written with G31 instead of G01 for preparatory machine moves. For example on the 2 surface outside centering X direction the mcprobing script reads as follows(excerpt). I added a couple comments on the right of the lines i am referring to.
Code: [Select]
------------- Probe Surface 1 -------------
local ProbeTo = CurPosition + (XWidth / 2) - OverShoot
local RetractPoint
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)
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f X%.4f F%.1f", ProbeCode, ProbeTo + Approach + OverShoot, FastFeed)) --This line is an X move over the part from the centerish starting point to past the expected part edge.
mm.ReturnCode(rc)
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)) --This line is an X move to the specified probing height for probing
mm.ReturnCode(rc)
rc = Probing.CheckProbe(1, ProbeCode); if not rc then; do return end; end
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f X%.4f F%.1f", ProbeCode, ProbeTo, FastFeed))
mm.ReturnCode(rc)
rc = Probing.CheckProbe(0, ProbeCode); if not rc then; do return end; end
local ProbePoint = mc.mcCntlGetPoundVar(inst, mc.SV_PROBE_POS_X)
if ((ProbeTo + Approach + OverShoot) < ProbeTo) then
RetractPoint = ProbePoint - BackOff
else
RetractPoint = ProbePoint + BackOff
end
This is the way the lua script is consistently written in the mcprobing module.
The end result is that simple probing actions such as finding a single surface or finding an inside center work for most people since there are no prep moves.
However on more complex probing sequences, i get the hangup that i am showing above.
I have found where others have encountered the issue and it has been handled several ways.
- Some suggest changing to G01 from G31. This fixes the issue but leaves the probe vulnerable to damage since an unexpected contact will be ignored. It seems to be best practice in the industry from what I have read to use G31 anytime the probe is installed to protect it.
- I did find one post where a script was written to tie a probe contact to an E-stop input anytime the machine status wasn't "probing". There were questions about the software handling it fast enough to do any good but that user reported success. My understanding being that the lag between the motion controller and software could be large enough to allow the crash before the software can shut down the motion controller.
- People with an ESS note that there are options in the ESS plugin to change this behavior. I understand there to be an option that allows the machine to progress normally without a probe contact during a G31
- I have noted that most of the weirdness goes away in the newer "touch" button probing menu but they don't cover all scenarios, namely 2 surface centering in one axis.
It is worth noting that currently there isn't even an error that happens or a message to the operator, the code just hangs and the cycle counter continues to count until i E-stop the cycle. I had to use logging under the diagnostic tab in order to find what was happening.
I have successfully changed certain probing sequences to G01 instead of G31 by editing the script like this
original line
Code: [Select]
string.format("G%.1f Z%.4f F%.1f", ProbeCode, ZLevel, FastFeed)
edited line
Code: [Select]
string.format("G1 Z%.4f F%.1f", ZLevel, FastFeed)
It does work, but as stated above it makes me nervous about breaking the probe if i have something input incorrectly about my setup or the safeZ and probing ZLevel
All this is to ask, how would you handle this?