z axis looses position - like it jumps time

[jgriffith66]

after operating some surface runs for about 3-4 hours of run time without a hitch(machine on for about 6 hours total) I ran into a glitch. at the end of a operation the z position jumped about 2.5 inches on the readout. i reset the z and run another operation for about 25 minutes. and at the end it jumped again - same direction and about the same 2.5 inches. from here i reset z three more times trying to run another operation finally shut her down as it was getting time to quit anyways. it seems to do this if i hit the upper limit switch or in a general retract move (z+). encoder? belt jumping? other ideas for me to check tomorrow?

[ajaxscott]

Does the position shift gradually while running or does it happen all at once?

If it happens all at once I'd look closely at your program for G92's, G52, G55, G56 etc... for some other type coordinate shift.

If it's a slow creep I'd look for a pulley or belt slipping-though I'd expect it would show up more often when cutting (usually a negative direction). Keep in mind that if it is shifting while cutting in the negative direction, it will show up as a shift in the positive direction. -Imaging commanding a 1" negative move against an immovable object located at Z0 so that the motor keeps turning but the belt or pulley slips so that the axis does not travel downward. When the move is complete the DRO will read -1.0000 and when you command a move to Z0, there is no resistance so the belt or pulley doesn't slip and Z0 is now 1" above the part instead of at the surface and commanding a move to the Z Machine zero (Z home) will now trip the limit.

An easy way to isolate the problem is to mark the motor shaft and the face of the motor while at MACHINE Z0. Run the machine for as long as you like -hours would be good- then command the axis back to machine 0 (not a coordinate 0). If the marks line up again, the problem is somewhere on the machine side of the motor shaft. If the marks don't line up the problem is either encoder or control related. No if's, and's or but's.

Unless it's something in your program, my money is on a gradual shift being caused by the pulley slipping. Even if you think it's happening all at once, it's likely that you only notice it when the limit trips. It could be a belt that's slipping but you can usually hear it.

Look at your program and do the motor mark test (mark the motor shaft and the motor face plate- nothing else) you'll find the problem.

Regards

Scott

[cncsnw]

Also see http://www.cncsnw.com/PosLoss.htm for expansion on Scott's advice.

[jgriffith66]

thanks for replying - It did seem to happen all at once and the difference seems to be -2.5 if my memory is correct. the part i was running (and still needs two more surfacing ops) luckly has come out perfect so far so not much going on inside the program, but i'll look at the program when i get back there today. marking the pulley was a thought i had last night so going ahead and try that and run a couple dry runs. this machine doesn't get a lot of use and is located two blocks from the ocean. so i was curious if it could be a corrosive connection problem.

[cncsnw]

No. If it were a connection problem it would gradually lose position all the time, in very small increments at a time.

An encoder connection problem serious enough to allow the loss of 2.5" in a short time period would affect axis controllability. Movement would be noisy and erratic.

My guess is either you have a G92 or M26 code in your program, or you have a severe pulley slip problem.

[jgriffith66]

well got off a few ops today. I cleaned the limit switches with electronic cleaner. in my programing (using mastercam9) i saw a code for tool compensation on in the beginning few lines, I deleted this and had no problems rising up into the limit anymore so without that contact it seems ok. I did have a powering off problem begin. The plc and spindle drive will power off but power remains in the cabinet. I have to disconnect power to everything to power back up. she went for as little as 10 minutes through to finally giving me 1.5 hours to finish my last op. (after about 7-8 shutdowns) these shutdowns occured both sitting idle and in program. it's like an estop but the plc goes off along with it.