really weird position loss

[Robertspark]

different ethernet cable?

cat 6 enhanced / 6A {not for the dataspeed as uceth cannot use it, but for the shielding + quality}

http://premiumwires.blogspot.co.uk/2016 ... -cat7.html

...belts and braces.... for how much i have used it is used from the ub1 to the drives too as its twisted pair + shielded...

ethernet with windows + cnc should not be a problem really as the data is not set realtime {like linuxcnc, with the realtime kernel}, hence some dataloss / errors whould be un-noticed...

5V power supply stability? {the UC300ETH does require more 5V that the USB variant from memory {thought I remember this being discussed when it was launched} .... not sure how susceptable to minor voltage ripple due to coinceident load??}

UC300ETH manual extract:

7 .
External power supply connection.
Ethernet communication is isolated and power is not transmitted on the network on the
ethernet cable and therefor the UC300ETH-5LPT board needs an external 5Volts DC
powersupply to be connected to the plug type green 2 pole power terminal on the side of the
board.
Make sure to not use higher input Voltage than 5Volts DC because it can cause
permanent damage to the device!
There is a step up switching regulator circuitry onboard which creates the nessessary
12Volts and other Voltage levels for the operation.
We recommend to use a power supply with at least 500mAmps of current capability of the
power supply. More current may be required if more I/Os are used.

[cncdrive]

Hi Terry,

No and yes. Some ethernet protocols have data detection and correction and some not. TCP/IP has, but we not using TCP/IP. We using UDP packets without data correction, because it is faster than TCP/IP has lots of things which we do not need and would unwantedly use more bandwidth than it is required for the UCCNC.
The data check and correction is made by our routines (in the ethernet this is above the UDP) just like it is done with the USB.
And the whole communication works much more complex than you probably think it is, it is not just sending data and check and correct and resend if required, that is just one part.
There are 6 data buffers in total just in the API and we did not even talked about the G41/42 buffer and the g-code executer buffer...
Data checking and correction is close to the lowest level in the API.

To execute wrong data is not possible though, because that is detected and corrected or the connection is opened up if it can't be corrected at all, but to loss some resolution is possible if enough packets are errorous to loose resolution, but the number of lost packets are not enough to trigger a communication error. But loss of resolution not equals wrong coordinates, it just means that the position data is not known for e.g. every 100 microsec but e.g. only for every millisec which if it is a problem depends on several factors like the machine resolution and feedrate.
However normally the number of lost packets should be around zero, if there are lots of lost packets then there is something wrong, like heavy noise effecting the computer and/or the ethernet.

But the issue is that I did not see that code yet and I also did not see what exactly the problem was, so I know about nothing about the issue yet and so I can only talk hypotethical and in general about it, because I do not have the informations yet. So, I'll wait for Derek to email me these informations to see the issue better.

[cncdrive]

Well if the error correction and resend is working correctly that should never be a problem. It either gets all the data sent in a timely manor OR it errors out and stops UCCNC.
It may not be an ETH problem it could be in UCCNC and the PC side ???

Again, it is not that simple unfortunately, but I gave some description about it above.
And the most important is that the controller has to answer within 20msec which is a requirement for the UCCNC to work properly, if it does not can cause strange problems.
That requirement is similar to that Mach3's parallel port driver needs a good timing, if it does not have that then the timing will be bad and the result will be bad.
Similar way, if the ethernet communication replies are slower than the requirement can ruin resolution, packets could mix up which can further slow down the communication etc.
However 20msec is not a serious requirement, because normally if everything if fine in Windows and in the network then packets should be through within 1msec.
And again, because I do not know much about the issue yet I can't tell what the problem exactly is, I agree that based on the little information I have yet it can be anything.

[Derek]

To me the thing to focus on is it went to the first Y move incorrectly. It missed it by .020" . it was commanded to go Y3.0610. It only moved to Y3.0410. After spot drilling, drilling and reaming 7 holes all at they same Y position it was commanded to move to Y-2.8051. It did go to Y-2.8051. If it had lost position it would have been off as well but it wasn't. I noticed it when I test fitted a piece and it didn't fit. I got the probe out and the Y-2.8051 was exactly where it should have been. The holes that were supposed to be at Y3.0610 were showing as 3.0410.

One other nugget. I use CAM. The code for every hole has the full X and Y coordinates of the hole. So if for some reason the Y DRO was reading 3.0410 then on the very next hole it would have corrected. It didn't that's how I know UCCNC thought it was at Y3.0610.

[Robertspark]

I forgot its UDP and not TCP....

I'm only commenting on Derek's original post as he is an experianced user and won't have newcommer setup woes {if he has a problem its one to take note} as there is a few other posters tagging onto this thread.

To recap the post...

I have a Gcode program that I have run multiple times. It's a drill then ream program. The basics are it approaches the X and Y position from the positive. drills, lifts, manual tool change, reams, moves 6.25" in the Y negative and repeats. I ran it this morning and the first hole was .020" out of position. The second hole was right on the money.

I don't use any backlash comp. The machine is a Bridgeport and is really accurate. .001" backlash on the X and Y. Rechecked the backlash this morning at both positions and it was the same .001" The servos are set to fault at .005" so I don't think it was position loss. So what happened is the machine went to Y3.041 when it was commanded to go to 3.061.

UC-300eth, 5LPT, HDBB2 boards. UCCNC V1.2102

Looking to see if anyone else has see position loss like this. It didn't loose position overall it just didn't go to the right spot on the first Y position. X was right on the money. It went to the right position on the second hole.

Thanks
Derek

Most important bit is the last line in my opinion...

It didn't loose position overall it just didn't go to the right spot on the first Y position. X was right on the money. It went to the right position on the second hole.

It lost position but then made it up... That sounds like a front end {gcode interpreter issue} the spot drill & reaming Mcode jumped the queue before the X G01 {or G00} was finished... but then made it up...

Don't know what step resolution he is running but that is ~0.5mm, so its probably a fair number of witheld steps

Could it be something to do with Linear Error Max, Linear Addition Length or Linear Unify Length?

Maybe UCCNC witholding something in a buffer and then adding it to the next line segment {maybe something in the code adjusted to allow for G41/G42}

Yeah, I know picking at straws.... but a comms lost packet won't add missing steps later... hence ethernet cable is a red herring.

[cncdrive]

Hi Derek,

Summarising the issue a bit with my words to let me see if I understand correctly:

The code was executed from a single g-code file and the first drill (or one of the first ones) did not go and did not drill on the correct position.
The drill was in code at Y3.0610, but the drilling happened at Y3.0410. And you obsereved that the Y axis DRO is at Y3.0410 when drilling.
Is this correct?

Another question is about the probing, You've mentioned that there was a probing done, was the probing right before that drill?
If so that makes me suspect that something wrong with how the probing updates the coordinates in the API, but I really should get some more info to see this clear and you to confirm.
If the coordinates were wrong (off) in the UCCNC makes sense, I mean much more sense than a communication error. I feel that the least possible.
And it would be very helpful if you could send me the whole UCCNC folder zipped with all your macros and the g-code file.
And in addition if you could describe me if there is any special process you did before running the code? I mean if you probed from the screen buttons or from a macro etc. (if probing is not in the g-code file) so we will then check first if we see the problem here. So, please email me these informations. I'll be available over most of the weekend as there is Easter 4 days weekend, so I could debug it.

[cncdrive]

Rob,

I think Derek is right about that it was not lost steps, because then that the coordinates coorect up later on without homing, there is a very little chance for that, because for that to happen the machine should loose the same amount of steps again but to the opposite direction. I think I can say that there is very little chance for that.
I also don't think it is a communication issue, because the communication is very robust, so there is very little chance for that too.
Because Derek mentioned probing and I know how the probing exactly works I suspect the issue will be there, but will wait for Derek to confirm that there was probing before the issue happened.

Or it could be interpretation issue. E.g. a macro could do this type of problem like how you wrote if not waiting for ismoving to end, so the coordinates the macro get for unprogrammed axes could be intermediate coordinates then because the motion is still there and the macro gets the unprogrammed coordinates from the API then. But Derek wrote that both coordinates are programmed in these g-code movements, so I think we can cross this out.

And it can't be a CV parameter problem, because the stationary coordinates will be correct, like an XY moves with Z drills down the drill down coordinate in the XY stationary state will become correct even if the CV tolerance is high. So, I would cross this out too.

And yes, I agree, I see about zero chance that it is a communication problem.

[Derek]

Could it be something to do with Linear Error Max, Linear Addition Length or Linear Unify Length?

This is the same machine I was trying to get the motion to be smoother on.
http://forum.cncdrive.com/viewtopic.php?f=4&t=1066
And yes I was fiddling with those settings before I had the problem. I have no idea what they were set at when I had the issue but they were either what I originally set them at or one of the recommended settings on that thread.

The code was executed from a single g-code file and the first drill (or one of the first ones) did not go and did not drill on the correct position.
The drill was in code at Y3.0610, but the drilling happened at Y3.0410.

Correct

And you obsereved that the Y axis DRO is at Y3.0410 when drilling.
Is this correct?

Incorrect. I made that assumption that since the very next line of code had Y3.0610, then if the DRO was reading 3.0410 the very next hole would have been in the correct spot.

Another question is about the probing, You've mentioned that there was a probing done, was the probing right before that drill?
If so that makes me suspect that something wrong with how the probing updates the coordinates in the API, but I really should get some more info to see this clear and you to confirm.

Yes I probed right before I started. This operation is the most critical one on the entire head and I always make sure I'm properly set.

And it would be very helpful if you could send me the whole UCCNC folder zipped with all your macros and the g-code file.
And in addition if you could describe me if there is any special process you did before running the code? I mean if you probed from the screen buttons or from a macro etc. (if probing is not in the g-code file) so we will then check first if we see the problem here. So, please email me these informations. I'll be available over most of the weekend as there is Easter 4 days weekend, so I could debug it.

Working on it. Waiting till the end of the day to shut the machine down. I send it in a couple of hours. I will note the probing macro number in the email.