Hello Guest it is March 29, 2024, 10:44:39 AM

Author Topic: G31 command stops since moving to Ethernet SmoothStepper  (Read 2013 times)

0 Members and 1 Guest are viewing this topic.

G31 command stops since moving to Ethernet SmoothStepper
« on: September 19, 2019, 07:02:00 AM »
G31 command stops since moving to Ethernet SmoothStepper

I have a z-height and center finding macro I have run for many years that make use of the G31 command. They failed when I moved to my ESS and after some trouble shooting I discovered the G31 command is no longer working. Even when entered as a MIDI command noting happens, For example, G31 Z1 F10.

I have done some searching here and found a few similar observations but without a definitive solution.

The probe LED does work via the diagnostic page as expected

Please refer to the image for wiring of my probe port.

Mach3 versions tested are below and I have also tested from a Dell Laptop and HP Thin client both running Windows 10.

Mach3 Version R3.043.062
Mach3 Version R3.043.066

ESS Version: ESS 2019_02_25 10w2a-10f1

G31 does not move any axis as a midi command however G32 work just fine.


Any help would be appreciated... Thx.
Re: G31 command stops since moving to Ethernet SmoothStepper
« Reply #1 on: January 10, 2020, 12:38:43 PM »
I have encountered a similar problem, but haven't discovered a solution yet. I am using MACH3 with an ESS (AVID CNC) running on a W10 PC. My application is to use the CNC to conduct X-ray measurements on a surface and use G31 to set the vertical height before each measurement. My probe is a npn output from a laser displacement sensor and I occasionally had a crash that I first assumed was a sensor fault. To prevent damage, I added a limit switch which trips an ESTOP condition and halts all motion and execution if the probe operation goes too far. What I found is that the MACH3 diagnostics pane shows that the probe was sensed, but the Z axis was not stopped. In the most recent example, I had successfully probed a surface 995 times in succession without a problem before the crash occurred. On recovery, I verified that the probe worked by simply restarting the code and it was able to correctly probe the exact same location successfully and stop without error, and continue to work for hundreds more locations before crashing again. Since MACH3 does sense the trip of the probe, it must be a MACH3 issue,.. I think. I've tried to reduce the system overhead on the computer and disconnected the PC from the network, closed other apps, etc., but so far, the fault still occurs and is very random. There nothing special about the places where the faults occur. Hopefully, someone has an idea of what is causing this and suggest fixes.
Re: G31 command stops since moving to Ethernet SmoothStepper
« Reply #2 on: January 23, 2020, 04:34:21 AM »
As I understand it, the probe input is "wired in" to the stepping engine in M3 via the parallel port, so that stepping stops instantaneously when the probe is triggered.  This is essential to make sure that the probe doesn't overrun and to get an accurate reading.  The functionality of the M3 stepper engine isn't used through the ESS, the ESS does it instead, so this is probably an ESS issue rather than Mach 3.

Offline Tweakie.CNC

*
  • *
  •  9,196 9,196
  • Super Kitty
    • View Profile
Re: G31 command stops since moving to Ethernet SmoothStepper
« Reply #3 on: January 23, 2020, 07:15:31 AM »
As I understand it, the probe input is "wired in" to the stepping engine in M3 via the parallel port, so that stepping stops instantaneously when the probe is triggered.  This is essential to make sure that the probe doesn't overrun and to get an accurate reading.  The functionality of the M3 stepper engine isn't used through the ESS, the ESS does it instead, so this is probably an ESS issue rather than Mach 3.

Nice thought John but Mach3 cannot stop instantly without loosing position - it has to be a controlled stop (using deceleration) and there will be overrun. The contact 'trigger point' is stored in a variable rather than taken from the DRO reading to allow for this.
In reality (dependant on the axis acceleration setting and axis speed) the overrun is very small but it has to be allowed for in the probe design.

Tweakie.
PEACE
Re: G31 command stops since moving to Ethernet SmoothStepper
« Reply #4 on: January 23, 2020, 07:47:35 AM »
OK, but that wasn't really my point.  If mach3 isn't doing the pulsing it must rely on the interface to signal what the position is when the probe is triggered which surely locates the problem in the ESS?  As I understand it, with these separate motion controllers M3 sends G code commands to the interface which executes them: so the ESS gets told "do a G31" and it will have to tell M3 how far it has moved before the probe triggers.
Re: G31 command stops since moving to Ethernet SmoothStepper
« Reply #5 on: January 23, 2020, 01:27:01 PM »
Hi John,
in the Mach4 Documents folder there a file called API.chm and in that file there is a DETAILED explanation how a plugin
(motion device) must handle a g31 code. Despite it being written for Mach4 its the same process for Mach3.


Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: G31 command stops since moving to Ethernet SmoothStepper
« Reply #6 on: February 05, 2020, 11:04:04 AM »
Get the Windows 10 fixed version of .062. That solved my probing problems. You can apparently find it here (see the “do not update windows 10” thread, but I got it from Warp9. The patch wasn’t intended to resolve this issue, but it did. For me, at least.