Position loss UC-300ETH

[Derek]

Finally getting time to redo my Bridgeport. Here is what I have.

UC-300ETH/ 5LPT. 2 HDBB2 BOBs. DG4S 16035 drives. Brand new Intel PWLA8391GT NIC. 5VDC supplied by 2.5A wall wart.

Test program runs the Y axis to 10" and back to 0". It does this cycle 100 times. At the end of the cycle it is off by .014-.017" in the same direction each time. If I switch out the UC-300ETH/ 5LPT with a UC-300USB/ 5LPT and run the same program it's within .0005". I have tried two different computers. Two different network cables. It is absolutely repeatable. I switched it back and fourth 3 times and got the same results. Both are running at 100 kHz.

I get the same results with both 5LPT boards.

Both computers were dual core with external graphics cards. One was XP and the other was Windows 7. The network cables tested were Cat5E and Cat7.

This is the same issue I was having earlier with the M44B but at the time based on others comments I concluded that was the problem. I also had no way to test it at the time due to lack of testing components. The last time I tested it I tried 2 different network cards.

I'm really at a bit of a loss as to what to try next.

Thanks
Derek

[cncdrive]

I would first check the position counter of the UCCNC, because the position sent out is what is shown there, because the position DRO shows the summary of the step/dir signals sent out.
The only exception is when a backlash is setup, then the position of the DRO may differ upto the amount of the backlash.

Second I would check if the step active low setting is set properly, if it is not can cause random looking position errors, because then the direction signal is not set on the proper edge of the step signal, so there can be cases when a step is done to the wrong direction.

Third I would check the position counter in the servo drives to see if they receive the proper amount of step/dir signals.
I would do that with zeroing the DRO in the UCCNC and in the Servoconfig3 in the same position and then make the testruns until a physical position loss is experienced.
Then check the position counter (commanded position counter) to see if it got the same amount of step/dirs from the software as what the software shows.
Ofcourse disable the backlash (if it is enabled) for this otherwise there may be a minor difference of upto the number of backlash steps, because under the backlash distance the position is the same.
If the DRO in the UCCNC will show the same position as the DRO in the Servoconfig3 means that the step/dirs were all correct and then the issue is not with the software or motion controller, but in the feedback signal (encoder signal) or mechanical error, otherwise, if they differ then the issue can be with the software or motion controller or signal loss or extra steps are getting into the step/dir wiring somehow.

So, I would do these tests to narrow down the problem.

You can also post your profile file and an example g-code file with which you can reproduce the issue and then we will run it with a step/dir counter connected to the step/dir output pins of the UC300ETH-5LPT.

[Derek]

I'll do those tests but if the usb version has no position loss and the ETH does wouldn't that rule out everything from the 5LPT to the servo? All I'm switching out each time is the UC300 and 5LPT. USB no loss- ETH loss.

Thanks
Derek

[cncdrive]

Not exactly. For example if the step pin active low setting is incorrect may cause problems with one controller and may not with the other,
because there can be minor differences in the timing of the direction signal with the different motion controllers and this is because the ethernet controllers have a better timing, a higher base frequency, so the timing is more precise. So, it may be possible that because of the bit worse timing in the USB controllers will not show the issue while it will show up with the ethernet controllers. We talking about microseconds and submicroseconds which can cause differences if the setup is wrong.

And one more question which I forgot to ask is to please also tell me the version of the UCCNC you running, so if you will post your profile file then we can test with the exact same version.

[Derek]

Well I just changed the step from "active low" to active high and got the same basic results. this time it was .0095".

When I started the run the dial indicator was at zero, the dro was at zero and the Y position count was 501. After the run I jogged the axis to the zero point on the dial indicator and the DRO read .0096 and the Y position count was 599

I'll fire up the servo config and get some data. I'll also post my profile file for you.

[cncdrive]

OK, also check what the step active edge is set to in the drives with the Servoconfig3.
The setting in the drive and in the UCCNC have to match if you using a HDBB2 board for the connection, because the HDBB2 does not invert the step signal.

[Derek]

Here is the profile.

The Gcode is simply
G00 Y-10
G00 Y0
Run multiple times.


I forgot to mention that the error is distance based not direction change based. If I change the code from -10 to -1 and run it again the amount of loss is slight.

[Derek]

Here are the results from the servo config test.

DG4s set to active high so I unchecked active low in UCCNC and applied.

Setup for test. Zero DRO and dial indicator. Y axis count on diagnostics page is 465. Reset servoconfig diagnostics page and set the "steps per" to match the Y axis units on UCCNC.

Ran test and checked results. Dial indicator at zero. UCCNC DRO .0079" Y axis count 539. "Position machine" on servoconfig 0.000300.

So if I'm interpreting this correctly the servo drive is in agreement with the dial indicator.

UCCNC version is 1.2042.

I'm in the direct path of hurricane Irma so my testing abilities may be a bit limited in the coming days:)

Thanks
Derek

[cncdrive]

Yes, if the position counters differs then the servo drive read different amount of step/dir signals as what the UCCNC output which can be that the UCCNC does not output the correct amount or noise picked up on the step/dir lines. However because the USB UC300 works OK in place this second one is not likely.

I we will run some tests next weekstart, because I don't have the logic analyser at home and I think my collegue who has will be busy over the weekend.
Will let you know what we find asap.

BTW, if you can check one more thing is the statistics window on the profiles page, I mean to check how high does the graph runs while you running the g-code.

Good luck with Irma, I hope it will silence down when it will reach your region.

[Derek]

Thanks. It should be down to a category 1 by the time it's here but even then there is a large potential for the power being out for a while.

I have switched back to the USB so that I can run a quick job tomorrow. Will the graph data help you or do you need it with the ETH unit.