UC300-ETH G31 probing with Mach3.

[Olivier-CNC]

Is the UC300-ETH G31 probing working internally in hardware ? Or does it run through Mach3 ?

I ask this question because since i've migrated from an ESS to the UC300-ETH, it seems that i did loose precision on the probing. I have a macro where i probe three times, one time at fast speed to reach the target, and two times at slow speed.

At each phase i'm comparing the probing result and display a message if the error if more than a defined value. Before the UC300-ETH migration i never had a displayed error, but after i had a probing position error of about 0.4 mm between the first fast speed probe and the second probing at slow speed. This is about 4 times more than the position difference i had before between the two first probing.

I needed to modify my macro where i had a limit set at 0.2mm for the position difference between first probing at high speed and second slow probing. I did rise the allowed error to 0.8mm to avoid alarm messages.

It's seems too that i don't get the same measured tool lenght through the toolsetter. I need to check that more deeply and set back the ESS or parallel port to compare. What it sure is that i did not see any difference when switching from the parallel port to the ESS. Only the UC300-ETH trigged a problem here. I need to check if it does come from the referencing or from the probing.

So i suspect that something is wrong in the EC300-ETH probing. Perhaps it does run through mach3 instead of catching the probe position in hardware, the delay necessary to send the probing information to mach3 would explain what i'm seeing.


Thanks for listening,

Olivier.

[cncdrive]

The UC300ETH handles the probing in hardware and feeds back the position to Mach3, so what you expecting is not true.
Are you sure that your probe is switching accurately?

[Olivier-CNC]

The UC300ETH handles the probing in hardware and feeds back the position to Mach3, so what you expecting is not true.
Are you sure that your probe is switching accurately?

Ok that's a good point. Yes my probe is sampling accurately, repeatability better than 0.01 mm. I've never seen before the difference error i see now.

Following your answer i'm going to investigate more deeply but there is not a lot of things that can go wrong. Only the input capture delay could explain what i'm seeing when the probing speed change.

The only thing that could be different from my previous setups is the debounce interval for inputs. When i was using the parallel port (at 45 KHz), the debounce was a Mach3 setting. It was set at 400 microseconds. With the ESS, it was an ESS setting (here if i remember correctly the probe input has a dedicated setting in the plugin setup screen).

For the UC300 i don't see a setting in the plugin screen, so i suppose that it is fixed for all inputs ? What is the value ?

Recommended debounce time for mechanical switch inputs is around 3 milliseconds. This is the default value we find in most PLCs. If you are using this value or something similar for all inputs, this could explain the difference error i see because the value i was using before is 400 us, around 7 times faster.

As is suppose you are using an FPGA for inputs and timing counters, i see no reason there could be an additional significative delay here. The only thing that i suspect could be wrong is the debounce interval for the probe input. If it is a fixed value of a few milliseconds, it would be nice to have a dedicated setting for the probe input, as well as for the index and incremental encoder inputs used for rigid tapping.

Olivier.

[Dazp1976]

I had some really bad delay with mine.
Haven't got a probe but all my trigger switches saw delayed triggering all inputs in the diagnostics page.

Seems a lot better since updating the lan driver in Windows.
I think I need to get a tool setter myself to see what my accuracy/response truly is.

[Olivier-CNC]

I had some really bad delay with mine.
Haven't got a probe but all my trigger switches saw delayed triggering all inputs in the diagnostics page.

Seems a lot better since updating the lan driver in Windows.
I think I need to get a tool setter myself to see what my accuracy/response truly is.

If the probing timing detection is done entirely inside the UC300 there is no reason that the Ethernet driver could make a difference.

As a side note the Ethernet delay on a local link is generally below around 1 ms, that depends about the Ethernet switch but today most of them are well below 1 ms delay as well as the Ethernet cards.

The diagnostic page is just a visual indication, it is delayed by the video driver timings, display monitor timings, and a few other delays.

To give a work basis, at 50 mm/min probing speed, a capture delay of 1 millisecond gives a position error of 0.83 micron (0.00083 mm).

I probe with two speeds : search speed is 1000 mm/min, final measure speed = 50 mm/min. The difference is 950 mm/min or 15.83 micron (around 0.015 mm) if we suppose that the UC300 input delay is 1 millisecond. But the position difference i'm seeing with the UC300 is a lot larger, a couple tenth of millimeters between the two speeds. This is how i detected the problem because i have in my macro a comparison between the probe measurements, if the difference is too large, i trig a message displaying the error.

The only reliable data you can get to have an idea of the measure latency here is the reported G31 measured position, this value is normally detected in the controller hardware and then transmitted to Mach3 or other softwares G-code G31 variables. This mean that Ethernet or USB delays should not have any influence.

When using the parallel port, Mach3 is using a parallel port interrupt to catch the input timing as fast as possible. Not as good as an external hardware solution like a CNCDrive one but was working good enough for most uses, at least with Windows XP. Later windows OS became to fat to keep a good reliability with the parallel port. Even Windows XP in its time needed a few optimizations to get reliable results.

So without a toolsetter or a 3D probe, i think that there is no mean to detect an input latency problem (excepts perhaps if you have precise homing sensors, changing the homing speed and measuring position errors, it should be possible to get the controller capture timing by calculus).

[cncdrive]

How you getting the probe data? Are you reading the probe # variables? Or you reading the axes position DROs?
Reading the DROs can cause such problem, because the probing stops with decceleration (otherwise it could wear the driving mechanics if it would work with exact stop), so the higher the speed the longer the decceleration distance will be, so at the stop point after probing will be shifted (overrun) with the decceleration distance.
But the probe# variables register the probing point meanwhile and so when the probing finishes you can read those variables to get the accurate probe trigger point.

[ger21]

The only thing that could be different from my previous setups is the debounce interval for inputs. When i was using the parallel port (at 45 KHz), the debounce was a Mach3 setting. It was set at 400 microseconds.

Debounce in Mach3 does not affect the probe input.

[Olivier-CNC]

How you getting the probe data? Are you reading the probe # variables? Or you reading the axes position DROs?
Reading the DROs can cause such problem, because the probing stops with decceleration (otherwise it could wear the driving mechanics if it would work with exact stop), so the higher the speed the longer the decceleration distance will be, so at the stop point after probing will be shifted (overrun) with the decceleration distance.
But the probe# variables register the probing point meanwhile and so when the probing finishes you can read those variables to get the accurate probe trigger point.

I'm reading the G-code variables. Here is the first part of my macro for the toolsetter.

Code: Select all

' Phase 1
Code "F" & FirstProbeFeed 'Set feedrate to FirstProbeFeed
ZtoProbe = ( GetOemDRO(186) - FirstProbeDist ) 'prepare probe move to current work coordinate z - FirstProbeDist

Code "G31Z" & ZtoProbe 'Probe down using FirstProbeDist maximum distance
While IsMoving() 'Wait for probe move to finish
Wend

Z1 = GetVar(2002) 'Read the touch point
If ABS(Z1 - ZtoProbe) < NearLimit Then 'Error if we are near the maximum Probing distance
Message "Erreur : la sonde n'a pas détecté l'outil en phase 1 !"
Post CurrentFeed, CurrentAbsInc, ToolOffsetOn 'Call Post subroutine
Exit Sub 'Error, exit Main()
End If
Code "G0 Z" & ( Z1 + FirstRetractDist ) 'Move back to hit point + FirstRetractDist
While IsMoving ()
Wend