I apologize if this has been answered elsewhere but I was not able to find a solution.

I am going through the probing routines and have run into and issue.  Not sure if this is how the UC100 plugin is handling the G31 command or a problem the mcProbing.lua file itself.  When I run a probing routine, it typically errors out with "ERROR: No contact with probe" during a move to an offset location to begin probing.  I would expect the behavior of G31.0 to move to a specified position OR stop if contact with the probe is made.  What I am seeing is that it aborts when the position is achieved AND no contact is made.

I have been able to run the calibration routines by replacing the G31 commands in the lua file with G1 commands to get the probe in the offset position before the G31 commands to do the actual contact testing.  Doesn't seem like this should be necessary and wanted to ask the question before I modified all of the probing routines to use G1 to get to the offset positions.  Seems like the G1 commands could be risky if the probe contacted something unexpectedly and kept moving.

Has anyone else run into this problem?

Hi,

Has anyone else run into this problem?

Yes, quite a few posts have commented on that. ESS users have the same problem.

You are correct many controllers, the ESS, and by your description the UC100, hang if a probe contact does not occur before the terminal move.
Evidently its common practice  to write a G31 move to some location rather than a G1 or G0, the reason being that IF the probe touches the machine
will stop rather than crunch the probe. The only trouble is our controllers tend to hang if they don't get an expected probe contact.

At this stage NFS claim that its the motion controller plugin which is at fault while the motion controller manufactures claim its a Mach4 fault.....so neither
do anything about  it.

The only solution I'm aware of is to go through the code removing the offending G31's and replace them with G1's.

Craig

So I'm thinking of moving to use a UC100 rather than parallel port, initially with Mach3.  Just to check, if one uses G1 or jogs close to a surface to probe, and (assuming that one is in G91 relative mode) use a command like "G31 X3 F5" then if one is closer than 3mm to the surface the machine will stop on contact and signal the position to Mach3 (or Mach4) - is that correct please?

Hi,
that is correct and I believe the UC100 will perform that task no trouble. Just beware that there are dozens of Chinese ripoff copies of the UC100 on Ebay
and Amazon, buy genuine or don't buy.

Second issue is that if as a part of a Gcode probing routine what happens if a G31 does not result in a probe strike? Other reports I have seen suggest that
the UC100 halts or crashes the Gcode job, as it regards a G31 without a probe strike event as a failure.

As it turns out the Ethernet SmoothStepper (ESS) behaves similarly, however there is a setting that can be made in the ESS plugin that stops the plugin
from issuing a <Cycle Stop>. Whether the UC100 has a similar setting I don't know.

https://www.machsupport.com/forum/index.php?topic=45652.msg290228#msg290228

Given that the UC100 is a single port device (17 IO's) I consider it poor value compared to the UC300 (85 IO's) or UC400 (34 IO's)from the same company but still
I by far and away prefer the ESS (51 IO's) by Warp9TD.

Craig

Thanks Craig. 

- John.