really weird position loss

[Derek]

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

[Derek]

Only the one time. It's a UC-300ETH

It's the same code I've been using the whole time. The first Y move was in the wrong place physically. Not according to the DRO though. Every hole calls out the X and Y coordinates so if the DRO was reading 3.041 on the first hole it would have corrected on the second. All the dowel holes on that row were off. Then every Y move was in the correct place including when it went back to the original holes. After I do the dowels I go back and drill and tap all of the holes. The drilled and tapped holes are offset (correct placement) from the first run of dowels. .020" you can see even with my old blind eyes:)

I'm thinking of putting my old UC-300USB back on it. I have one on the Alliant and it is rock solid running almost every day.

[chjade84]

Hey! I've had a similar problem multiple times in my touch probe routine over the last year or so. It's simply "g1 Xsomething Ysomething" and then the code to probe down but occasionally it will miss and hit the sides of the probe body. I can't figure out what may cause it so I've kind of ignored it (despite breaking tools and trashing my touch plates!) but I can't reproduce it reliably and it doesn't happen that often.

However I've had a much larger issue this week that may be related that I was going to start a thread about. While running a program about once every 20 minutes or so, the spindle would loose power and the machine would pause for 2-3 seconds and then it would start up again where it left off but at a XY coordinate that was about 1.5in from where it stopped! I watched the board while it ran a part and when it happened, most of the lights on the C62 board went out and then came back on. The weird thing is the software didn't loose connectivity to the UC300ETH so it's not loosing power to the main circuitry.

I set up a camera looking at the board last night and cut air for about 4 hours but couldn't get it to do it again. Figures.

It's like the breakout board stops processing any instructions for a few seconds but the UC300 is none the wiser and just assumes the machine has moved as it was supposed to; when it really did not.

Perhaps these are related. I'm running a version or two behind but have been using the same setup for about 2 years with no problems so I'd think it would be much more likely to be hardware related.

[cncdrive]

It does not seems to be from the description that the 2 things are related.
If all lights go off on the C62 then isn't it possible that it loose power?
Is there a power LED on it which just shows the input power to the board? If yes then did that LED go out too?
I suspect a possible power failure to the board if that happens.

Another possibility would be if it uses the charge pump that the charge pump went off for some reason,
but to know if that happened we should know what LEDs went off, if it fully lost the power or if not then what exact circuits went off, then we could make some guesses if we know that.

And I'm not sure that I understand the probe issue. What miss and hit the sides of the probe body means?
Please note that I do not see your probing setup and maybe I have not enough imagination to imagine how it looks and what it means what you described.
A few possible issues could be that the probing routine G1 movement hit the probe because of incorrect movement distance, so you think that it is a G31 probing movement while it is still the G1, so then it will not stop when the probe hit. To see if this is the case you can check the probe LED on the Diagnostics page and under the Status monitor section. Not the one under the I/O function monitor! That means different.
The one under the status monitor is telling you if it is an actual G31 probing move, while under the I/O function monitor LED shows if the probe input is triggered.
So, I'm advicing to watch the probe LED under the status monitor to see if the macro code really sending a G31 move when this happens.
The same time you can also check if the other probe LED triggers to see if the probe input even triggers.

[chjade84]

Thanks for the info I'll try and get video of it happening again tonight if it will cooperate. I don't think the stepper lights go out so the C62 isn't loosing power completely. The charge pump is an interesting idea.

I have a two stage probe using optical and then electrical contacts. Sometimes it will move to the wrong XY location and then probes down but because it's now in the wrong location it misses the optical beam by up to an inch when it descends and instead of breaking the beam to signal a stop it just rams the tool into the copper plate or UHMW body. The probing routine is active, it just misses the thing that tells it when to stop. Video here (of a successful probe) https://youtu.be/v-S4RXMdlrY?t=1316

I'm using a modified version of the touch probe routine it seems everyone is using. Basically this:

Code: Select all

if(domoveXY) // Make XY movement only if enabled
{
  exec.Code("G00 G53 Z" + SafeZ); // Move Z up first
  while(exec.IsMoving()){}

  exec.Code("G00 G53 X" + probeX1 +" Y" + probeY1); // Move to the probe sensor position in XY
  while(exec.IsMoving()){}
}

if(dodualcycle)
{
  exec.Code("G31 Z" + Zmin + "F" + FeedrateFast); // Do the Z probing with Fast feedrate first
  while(exec.IsMoving()){}
  exec.Wait(200);
  exec.Code("G91 G0 Z" + retractforsecondmeasurement);
  exec.Code("G00 G53 X" + probeX2 +" Y" + probeY2); // Move to the second probe sensor position in XY
  exec.Code("G90");
}
exec.AddStatusmessage(" Z Stored: " + Zoffset );
exec.Code("G31 Z" + Zmin + "F" + FeedrateSlow); // Do the Z probing again with Slow Feedrate to get a more accurate reading
while(exec.IsMoving()){}

[chjade84]

Couldn't get it to repeat again last night. I'll probably just have to wait until it acts up again and then grab the camera and try to get a video.

[moparx12]

Derek, Did you get this figured out? Looks like your thread was hijacked and you were forgot about? I think I am having a similar issue. One difference I have noticed is that my machine actually tells me when its lost its position, makes a sound like it ran into a wall. I have a thread on here where I think they have narrowed it down to my PC or network card driver. I have not had time to test that theory yet though.

[Derek]

Couldn't get it to repeat again last night. I'll probably just have to wait until it acts up again and then grab the camera and try to get a video.

Nope.
I yanked the ETH out and put the USB one back in. I lost all confidence in the ETH controller. I was actually going to contact them directly with it since the post did seem to get lost. If the answer is going to be "we can't recreate it" then I'm at a loss. I ran the machine for months before the problem and never had an issue so unless they plan on testing for months then recreating the problem will be impossible. I'm tired of taking the time to collect all the data and get the same we ran it 100 times and didn't see a problem.

My friend is a metallurgist. given enough data on an exploded steam boiler and he will give you a pretty good idea of what went wrong without blowing up another boiler.

If every problem needs to be recreated to be fixed then maybe some sort of advanced logging software needs to be implemented.

Derek

[cncdrive]

Hi Derek,

Advanced logging system is already implemented, because it is required for us to be used when somebody report a complicated issue.
However if an issue does not happen on our system then there is nothing to log by us, no useful data can be collected then if the issue not happening on our systems, but we can give you logging enabled API if we know what we need to log, then you could run it on your system and when the issue happens then you can send us the log file. If we clearly understand what and how happens then there is a high chance that we will enable the proper datas for logging so then we will see what the issue is from the data in the log file and then we can figure what and why happens.
The big issue is that logging everything the same time is kind of impossible. Even when logging just all the motion data can easily create a 400-500MBytes per minute log file,
so the thing is that just the logging process could choke the computer with the so much data writting. So to successfully log things the issue should be initially narrowed down a bit.

I advice you to contact me directly please and explain what the problem exactly is and send me that g-code file and macros and possible your whole UCCNC folder zipped, then we will try to figure out how to debug it the best way.

[Derek]

Will do.

Derek