Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: pmageau on September 10, 2021, 02:16:19 PM
-
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 :)
-
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?
I think this is the issue, I'll give it a try tomorrow.
-
Goomba
when you get the GUI sorted for the probing can you pretty please call in by a different name so it will not override the current version that would allow us to gracefully apply our customisations
Stuart
-
And yes, changing the setting in the ESS fixed probing issues for me
-
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 :)
As someone who has been trying to climb the learning curve of understanding how to modify the current probing scripts, this sounds pretty exciting.
What sort of timeline is this project on? I know things don't happen overnight, but I am interested!
Thank you!
-
Goomba,
What ever happened to the probing software rewrite ? Did that ever get released ? If so, can you provide links to the download/version ?
Thanks,
Paul
-
Hi,
I have in recent days tumbled to the solution.
As smurh has pointed out it is common to use a g31 move to simulate a g1 move with a probe installed, it's to protect the probe....but a g31
that does not return a probe event is interpreted by some motion controllers, the ESS and UC100 certainly and maybe others, as a fault.
The ESS by default issues a <Cycle Stop> if that is the case and probing routines like mcProbing fail as a result.
The Probing Tab of the ESS plugin has a setting to disable the <Cycle Stop> in the event of a non-contact g31 move.
Craig
-
Thanks Craig. I’ll check my ESS settings tomorrow !