Then get a clean rag and a sharpie marker, and put index marks across
the junctions of all accessible moving parts. Useful locations on
a typical axis include:
Centroid CNC control sales, service, training and support
When all is working correctly, your control will maintain its positioning, relative to machine zero and to part zero, indefinitely.
Even if you shut off the power, then later power up and re-home the machine, your zeros should still be in their previous locations.
Loss of position, whether during a part cycle, from cycle to cycle, or from day to day, is a sign of some sort of mechanical or electronic problem. Some common causes include:
Most of these things can be divided into several broad categories: Position loss of any amount at any time, even as jobs are running; Position loss of any amount, but only after cycling the power and re-homing; and Position loss of exactly one motor turn (or an exact multiple of motor turns) after cycling the power and re-homing.
Avoid the temptation to blame the CNC control first, just because it is there and it is inscrutable. Look for the simple things. Here are some examples I have come across over the years:
Strictly speaking, it is not an error to put G92, G52, or M26 codes in your program. However, if you do use these codes, you need to be sure you understand their side effects.
Some CAD/CAM postprocessors insert G92 or G52 codes automatically, so it is possible you have these codes in your program without knowing it.
If you suspect your CAD/CAM system may put G92 or G52 in your part programs, use the text editor (F6/Edit) to search for them.
Intercon will never generate any of these codes unless you explicitly insert them with the "Insert M&G" operation.
How G92, G52 and M26 work, and how they don't work with Search and Resume
Once you have eliminated the simple things, you should put some tell-tale marks in place so you can visually determine which parts of the machine have returned to their previous positions, and which parts have not.
First, get a fresh start: power off, power back up, and let the machine find its home position.
Then get a clean rag and a sharpie marker, and put index marks across
the junctions of all accessible moving parts. Useful locations on
a typical axis include:
The marks from shaft to pulley will tell you if the pulley is slipping.
The marks from shaft or pulley to stationary surfaces (bearing housing or motor face) will tell you if the shaft has rotated back to the same position it was at when homed.
Now run the machine, either cutting parts or doing dry runs, until you
see that you have lost some position on the axis. Then send the axis
back to its home switch and check to see whether each component is
back where it had been before, and to see whether the DRO returns to
machine zero at the same time.
This example assumes an X axis, homed minus. To test another axis, use
the appropriate letter. If the axis homes plus (as Mill Y and Z usually
do, and as all Lathe axes usually do) then use M92 instead of M91.
Alternately, if your problem only occurs when the machine has been
shut down, powered up, and re-homed, then just check your test marks
immediately after it is done homing at the start of each day.
Look at the DRO. If it does not read within a tenth or two of 0.0000, then you have a problem. If the error on the DRO is some whole multiple of a motor turn, then the problem relates to your home switch: it is either positioned to trip too close to where the encoder index pulse comes around, or it is sticking and failing to release consistently.
How much distance is one motor turn?
If there is an error on the DRO that does not correspond to a whole number of
motor turns, then check your motor shaft-to-face marks. If the motor
shaft is back exactly where it was before, then you are losing counts
due to a faulty encoder, faulty encoder cable, or bad connection.
If the motor shaft is not back where it was before (and perhaps the angular difference matches up with the error on the DRO) then you are not getting a consistent index pulse. Again this could be due to a faulty encoder, faulty encoder cable, or bad connection.
If the DRO does come back to read within a tenth or two of 0.0000,
(or of some whole number of motor turns), but the motor
shaft-to-face marks do not line up, then the encoder has slipped
on the back shaft. Remove the back cap from the motor and try
reseating the encoder.
This is less common, but does happen. After the machine has lost position,
send it to home as described above; check the encoder position first; then
check your marks on down the drive train to see which ones still line up.
Some things to look at:
In general, a mismatch in the index marks downstream of the motor itself will be self-explanatory. You will see what moved, you just need to figure out the best way to keep it from moving.
A mismatch at the motor is nearly always an encoder failure. When you replace the encoder, see if oil or coolant is getting into the motor cap. If it is, you need to install a drip shield to protect the motor and encoder.
One machine I encountered would lose position on one or more axes as the job ran, progressively cutting farther off position as the cycle went on, but then would reset itself at the beginning of any new cycle. If the operator canceled and restarted, it would be back to cutting in the right place. Further, the DRO accurately showed that it was at the wrong position in the middle of the job.
The cause turned out to be a miswired encoder. Another service technician had replaced the motor and rewired the motor cable connector to match, but had crossed up the encoder index pulse and motor tach wires, so that the Centroid board was getting random noise on the index pulse input. This interrupted the motion control processor persistently enough to make it drop vectors: some of the move segments in the program were simply not happening, so that the tool did not reach the expected location. A hint was given by occasional "CPU failure #2" messages in the status window, indicating that the controller board was intermittently losing communication with the motion control processor.
When I fixed the cable connector wiring, the problem went away.
Copyright © 2008 Marc Leonard
Last updated 01-May-2008 MBL
