11M Problem

[Todd Zuercher]

I am having a problem with an old CNC with an 11M control
It is a Heian 3 axis router fed by DNC from a PC.
The problem is that is is loosing position (only notice in Z axis).
Even though the files are running in G90 mode, the depth will change a seamingly random amount up or down more often down. On the positioning screen the relative positon will indicate the position as commanded by the program, however the machine position will show the correct position of the machine. Pausing the machine, switching it to single block exicution mode and exicuting a single block command that contains a Z movement, will reset the mahcine and move it back to the correct position. Then we can turn off the single block mode and resume the program without any problem (until it messes up again). No alarms are ever set, so I don't think it is a problem with the servo. It isn't a mechanical problem because the control knows it is off and by how much, it just dosn't do anything about it, unless you flip the single block exicution switch.
This is getting to be a serious problem, last night on 3rd shift it punged into the table draging the collet on the material and started a fire.

[Al_The_Man]

If the machine position show correct on the screen and no alarms, but the actual Z position is wrong, I would suspect there is a mechanical error between the motor and the final Z.
If the encoder is on the motor, it cannot detect any final error after reduction etc.
Al.

[Todd Zuercher]

The value shown for the machine position is correct. It is the value shown for the realative posion that is drifting in relation to the machine posion. It is almost like there are G92 codes being issued changing the relative postion (but there are none in the file).

[memoryman]

does the physical machine position agree with the displayed machine position? What about the ABSOLUTE position?
Could be an offset problem? the offsets are stored on the BMU.
Bill

[Todd Zuercher]

The physical machine position (where the tool actually is) does agree with what is displayed on the CRT as the "machine" position.
The "relative" position and the "Absolute" position both are showing the same number and both numbers match what the program is telling them they should be, but they have changed relative to the "machine" position.
Example: At the start of a program the relative position for Z=0.5000 and the machine position for Z=-5.6100. After the error part way through a run the relative postion will still say Z=0.5000, but the machine postion will say Z=-5.8576 (or some other random number usually only a fraction of an inch from the -5.6100 that it should be). I am can not say for certain but I am pretty sure that the number displayed under absolute postion is the same as what is shown for the relative postion before and after the mistake. We are not using any offsets on this machine right now, and the machine coodinate systems (G53,G54,G55,...) make no changes to the Z axis position.

[memoryman]

weird. What does your 'distance to go' show?
It may be easier if you call me.
Bill Peiman, President
Tulip Electronics Inc.
2065 Conservation Road
Campbellville,On L0P 1B0
Canada
P (905)854-6668
F (905)854-6669

[Todd Zuercher]

While the machine is moving the distance to go is always changing.
I agree it is quite weird.
if the machine is exicuting a block that dosn't have a z movement the distance to go for the z-axis will show 0.0000 even when it is out of wack. I suspect that If I were to actually catch it in the act (while it exicutes the block that messes it up) the distance to go my not reach 0 before the next block is processed, but shouldn't that set an alarm.

[WGoyer]

Todd,

I think you might have a problem with your "Z Neglect" function. This is usually controlled by a toggle switch for program test purposes. If the switch is bad, the function may be switching on and off with vibration. There is a diagnostic that should show the state of the Z neglect switch.

Warren
www.uptimecorp.com

[Todd Zuercher]

I did think of that, but have not tried to test it yet.

Someone else asked me at what baudrate we have been feeding the machine and suggested that we slow DNC feed down from the 9600bps we are currently running to 4800 or 2400. I am currently running a test of this now, I'll look at the switch later.

[gbowne1]

how did the test go?

Greg

[Todd Zuercher]

So far changing the feed rate of the DNC from 9600bps to 4800bps has not given any errors, but we haven't been running the machine as hard lately and only on 1st shift (still a little gun shy). But it has always been a very intermitant problem.

[Edit]

I spoke to soon. I just ran the machine myself and at the start of the run the z axis coodinates were: relative 0.5000, abslolute 0.5000, machine -5.6100, distance to go 0.0000. After the running a file the z axis coodinates were: relative 0.5000, absolute 0.5009, machine 5.6091, distance to go 0.0000. It had drifted .0009 up (at least it was up instead of down). I homed the machine and ran again and this time the machine finished with the same numbers it started with (what it is suposed to do).

I looked at the ZNG switch a little. We never use it. At some point it must have gotten hit with something, and is bent and quite loose to the touch. It could be a very good suspect. I will look into it more closely.

[Todd Zuercher]

Ok the ZNG switch is defonatly bad, but is it the problem?. Uppon pulling the pannel I could see signs of electrical failure of the switch (gunk splattered on the back of the pannel around the bad switch). There are also signs the switch had been replaced before. With an electrical tester the switch tested open (off) and no amount of jiggling was able to get it to show continuity with my tester. So just to be safe, I cut it out of the circuit and taped the wires. We're running the machine now let you know if(when) it messes up again.