Hello Guest it is March 28, 2024, 08:26:14 AM

Author Topic: Mach4 hangs after G31 probe with no contact using AXBB-E motion controller  (Read 834 times)

0 Members and 1 Guest are viewing this topic.

Offline MrFixit

*
  •  7 7
  • Series 2 Boss 6 CNC mill - retrofitted+updated
    • View Profile
Hello,
I have been trying to work out an issue when probing on my CNC mill. I have found that for preparatory moves where I want to use G31 in case the probe does make contact, but I'm not actually looking for a probe contact, Mach 4 is hanging. 

I originally found this issue when trying to use the 2 Surface Outside Centering script on the probing screen. In trying to troubleshoot my problem, i found that the same issue occurs on a very simple G31 MDI input when the probe is not triggered/contacted.

I'm not sure I understand the log correctly of who's/what's fault it is. I have included it below. 

When using G31 in the simplest sense, it works great. IE, machine starts to move, and it stops when the probe is triggered. 

When using G31 as a prep move where no probe contact happens is when the software is hanging on me.

Here is the error I see when I input the following in MDI, it is worth noting that the machine moves to the position X -1.000 correctly but the code hangs after the move.

G31 X-1.000 F20

Code: [Select]
2021-11-24 05:26:29.134 - API: mcCntlMdiExecute(inst = 0, commands = 'g31 x-1.000 F20') (unknown caller)
2021-11-24 05:26:29.243 - Attempt transition from "Idle" on event "MDI Start" controller.cpp:2364
2021-11-24 05:26:29.243 - Signal id 1127, (Jog Enabled), changed from HIGH to LOW.
2021-11-24 05:26:29.243 - S_IDLE_on_exit
2021-11-24 05:26:29.243 - Signal id 1172, (Machine Idle), changed from HIGH to LOW.
2021-11-24 05:26:29.243 - ACTION_start_mdi
2021-11-24 05:26:29.243 - SoftSync()! Clearing planner.
2021-11-24 05:26:29.274 - S_MDI_RUNNING_on_entry
2021-11-24 05:26:29.274 - SoftSync()! Clearing planner. stateinterface.cpp:1351
2021-11-24 05:26:29.274 - S_MDI_RUNNING2_on_entry
2021-11-24 05:26:29.274 - Signal id 1114, (Gcode Running), changed from LOW to HIGH.
2021-11-24 05:26:29.274 - Attempt transition from "MDI Running" on event "Probe" runcanon.cpp:536
2021-11-24 05:26:29.274 - S_MDI_RUNNING2_on_exit
2021-11-24 05:26:29.274 - Signal id 1114, (Gcode Running), changed from HIGH to LOW.
2021-11-24 05:26:29.274 - ACTION_start_probe
2021-11-24 05:26:29.274 - S_MDI_PROBING_on_entry
2021-11-24 05:26:29.274 - Signal id 1173, (Machine Probing), changed from LOW to HIGH.
2021-11-24 05:26:29.274 - Probing: Waiting on exit event... runcanon.cpp:267
2021-11-24 05:26:29.274 - Waiting on planner to drain before waiting on SetStill... runcanon.cpp:92
2021-11-24 05:26:31.383 - Waiting on SetStill...
2021-11-24 05:26:31.383 - Signal id 1180, (Feed Hold Disabled), changed from LOW to HIGH.
2021-11-24 05:26:31.383 - Controller::RunCanonBuffer called AddStopReportRequest() runcanon.cpp:101
2021-11-24 05:26:31.383 - Requesting a stopped report for axis 0 motors.
2021-11-24 05:26:31.383 - Requesting a stopped report for motor 0.
2021-11-24 05:26:31.383 - Requesting a stopped report for axis 1 motors.
2021-11-24 05:26:31.383 - Requesting a stopped report for motor 1.
2021-11-24 05:26:31.383 - Requesting a stopped report for axis 2 motors.
2021-11-24 05:26:31.383 - Requesting a stopped report for motor 2.

It just hangs here after the log line    Controller::RunCanonBuffer called AddStopReportRequest() runcanon.cpp:101
In case it is helpful, the machine just sits like this with the cycle time counting up until i toggle the enable button off.  The log file then continues as below

Code: [Select]
2021-11-24 05:28:33.223 - API: mcCntlEnable(inst = 0, FALSE) (Mach4GUI Button)
2021-11-24 05:28:33.239 - Signal id 1018, (Enable #0), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - Signal id 1019, (Enable #1), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - Signal id 1020, (Enable #2), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - Attempt transition from "Probing" on event "Stop" controller.cpp:5235
2021-11-24 05:28:33.239 - S_FILE_PROBING_on_exit
2021-11-24 05:28:33.239 - Signal id 1173, (Machine Probing), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - S_MDI_RUNNING_on_exit
2021-11-24 05:28:33.239 - ACTION_stop
2021-11-24 05:28:33.348 - S_IDLE_on_entry
2021-11-24 05:28:33.364 - Signal id 1172, (Machine Idle), changed from LOW to HIGH.
2021-11-24 05:28:33.364 - Waiting on SetStill is Done!
2021-11-24 05:28:33.364 - Signal id 1120, (Machine Enabled), changed from HIGH to LOW.
2021-11-24 05:28:33.364 - Probing: Exiting probe state because of end of move. gcodeexec.cpp:1552
2021-11-24 05:28:33.364 - Attempt transition from "Idle" on event "Probe Complete" gcodeexec.cpp:1574
2021-11-24 05:28:33.364 - Can't transition from "Idle" on event "Probe Complete" gcodeexec.cpp:1574
2021-11-24 05:28:33.379 - Signal id 1180, (Feed Hold Disabled), changed from HIGH to LOW.

For background, at the risk of making this post too long to be interesting, my probe is hooked up to Port 2 pin 5 of the AXBB-E. It is an NPN switching probe @5volts.  I have its output hooked up to i5- and 5VDC going to i5+.  I have it set up as active low in Mach4 config. It works perfectly and is very consistent.  I'm quite certain i don't have a hardware issue, but i wanted to give that context in case it mattered.

I have the most current AXBB-E plugin that i can find. It is listed as V 1.002 in Mach4.

If anyone has any ideas about how i can resolve this please let me know.

I have posted this over on CNCdrive's forum as well on the suspicion that it is a plugin issue but i wanted to ask here as well since i am uncertain. It is also quite possible that it is my fault. I'm hoping someone can point me in the right direction.

I found one other forum post there of another person struggling with this specific issue and Mach4 but it was over a year ago and they never got any replies to their post. https://www.forum.cncdrive.com/viewtopic.php?f=22&t=2600

I also read here on MachSupport about something similar happening to people with another vendors product (Ethernet Smooth Stepper), and they added functionality to their plug in to prevent it hanging in this situation from what i understand. I only include this for context of me suspecting it as a bug.

I have attached my Mach4 logfile and my ini files in case they are useful.

Please let me know if there is other information i can provide that would be helpful and i will get it to you. 

Thanks in advance for any help or clarity you can provide!
« Last Edit: November 24, 2021, 09:45:31 AM by MrFixit »
Re: Mach4 hangs after G31 probe with no contact using AXBB-E motion controller
« Reply #1 on: November 24, 2021, 04:10:13 PM »
I believe you are correct in that this is a plugin issue. I think it has to report back to Mach that it has not probed anything and abort the probe sequence itself. I don't know how well they support their plugin for Mach4 as they obviously have their own CNC software.
Re: Mach4 hangs after G31 probe with no contact using AXBB-E motion controller
« Reply #2 on: November 24, 2021, 05:22:21 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
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline MrFixit

*
  •  7 7
  • Series 2 Boss 6 CNC mill - retrofitted+updated
    • View Profile
Re: Mach4 hangs after G31 probe with no contact using AXBB-E motion controller
« Reply #3 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?


« Last Edit: December 21, 2021, 12:37:48 PM by MrFixit »