Position loss with UC-300ETH

[Derek]

Hi
I upgraded my mill from a UC-300 USB/M44B to a UC-300ETH/M44B. I'm now getting a good amount of drift in all axis. I's always in the same direction. I put the UC-USB back in and I no longer have the issue.

Single core tower with a dedicated PCI NIC for the UC-300. Using a crossover cable. Running XP.
I have 2 M44B boards and have tried both with the same results.
The NIC card is an older Belkin

Any words of wisdom?

Thanks
Derek

[cncdrive]

Is the position DRO shows the correct position?
If yes then the motion controller produced the correct amount of step dirs, because the position DRO gets it's value from a readback from the pulse generator, so if this is the case then the pulses are lost somewhere outside of the UC.
Or if the DRO shows the incorrect value then it is something with the device or settings.

And one more idea is to verify the kernel frequency setting, it may be too high can cause lost steps if the drive can't read that fast signals safely.

[Derek]

Is the position DRO shows the correct position?
If yes then the motion controller produced the correct amount of step dirs, because the position DRO gets it's value from a readback from the pulse generator, so if this is the case then the pulses are lost somewhere outside of the UC.
Or if the DRO shows the incorrect value then it is something with the device or settings.

And one more idea is to verify the kernel frequency setting, it may be too high can cause lost steps if the drive can't read that fast signals safely.

Hi Balazs.

If I zero the DROs on the edge of the stock with the probe, run the code, and then check the edge again with the probe the DRO's are off.

I was running at 200 khz but I get the same results at 100 khz which is what I'm running the UC-300USB at.

Derek

[Derek]

Also I'm running DG4S-16035 drives and a C62 BOB.

[cncdrive]

Hi Derek,

I meant that if the DROs are off from what the stationary position is, let me describe:

Because the position DRO shows the sum of the step dir signals if there is a bug or something and if the UC generates the wrong number of steps for any reasons then the DRO would be off in a way that for example you command to G0 X0 and then the DRO would be not X=0, but would be off with the lost steps amount, for example X=0.5 or something.
We've designed the system this way to easily find out if the controller generated the wrong number of steps.

What you saying is that the DRO is off of the physical position is ofcourse like that in all cases when anything in the control system looses steps.
But the question is if the DRO shows the position where you commanded the axis to move after this drift happened or not,
because if it is then it will be not the motion controller and if the DRO is drifted like I described then it is sure the motion controller who made the drift.

We also have a step dir counter application which is a modified firmware for a UC100 and what that makes is if you connect step dir outputs of another motion controller to the inputs of a UC100 then the UC100 counts then and we use this setup to verify that the step dirs are all correct. We run a long verification code before all releases.
I think I can give you this code if you would like so you could verify if the motion controller makes the problem,
but I will need some days, because currently my collegue who could give me this code is out of the country.

[Derek]

Having trouble grasping the concept that you are describing because it's the end of the day and I've kept 3 machine churning out parts all day and I'm whipped:)

I can tell you this though. I roughed out a core mold and then finished it. after the finish pass was done I noticed immediately that something was wrong because all of the vertical surfaces on the left were still rough. This usually means either the machine drifted or the stock moved. Testing revealed that the machine moved slowly over the course of the run . When I checked the corner of the stock with the probe the x axis read .06" instead of 0.00"

I ordered a new network card and I'll switch it and the cable out and repeat the same code. If that doesn't fix it then we can address it further.

Thanks
Derek

[CT63]

Seeing the only real change is going from USB to Ethernet you could have a corrupt Ethernet driver. Try deleting then reloading the driver. Or check for a updated driver. Another forum member had similar issues that ended up being a corrupt driver but that was on a Windows 10 upgrade machine.

[Derek]

Seeing the only real change is going from USB to Ethernet you could have a corrupt Ethernet driver. Try deleting then reloading the driver. Or check for a updated driver. Another forum member had similar issues that ended up being a corrupt driver but that was on a Windows 10 upgrade machine.

I ordered this card
https://www.amazon.com/gp/product/B0003 ... UTF8&psc=1

It's an intel and it has drivers for XP so I figure I'll start there.

Thanks
Derek

[Derek]

We also have a step dir counter application which is a modified firmware for a UC100 and what that makes is if you connect step dir outputs of another motion controller to the inputs of a UC100 then the UC100 counts then and we use this setup to verify that the step dirs are all correct. We run a long verification code before all releases.
I think I can give you this code if you would like so you could verify if the motion controller makes the problem,
but I will need some days, because currently my collegue who could give me this code is out of the country.

This is interesting. So I could theoretically hook the UC-100 directly to the BOB and if the count was correct then that would mean it was a drive, encoder or mechanical related. Is the the theory?

Neat.

[cncdrive]

Hi Derek,

Yes, exactly.
That firmware acts as a counter and it does nothing else just counts the step dirs.
So, if you have a UC100 you can use it as a counter device and so it can count the step dirs and so it can tell you if the other motion controller, another UC100 or UC300 or UC300ETH etc. sent the correct amount of step dir signals or not.