11M Frustrations

[Todd Zuercher]

We have about had all that we can take from this POS.

We have a 1984 Heian CNC router with 11M control.

Tired of dealing with a misterious positioning error that no one has been able to fix let alone, diagnose for the last five years. It will mill along happily then for some unknow reason change position on the Z axis even when there are no Z commands issued in the program. Often it is only a few thousanths, but sometimes it is several inches. The position screen will be showing Z=-.75 then all of a sudden the depth changes to Z=-1.1587 (or some other semingly random number). Machine, Absolute, and Relative postions all change by the same about. If I then flip the single block exicute switch and step through a series of blocks that contain a G00 Z movement. the machine will (usually) correct its self and return to the propper depth commanded in the program. But if I do nothing it will continue on with the error.

We thought that it seemed like a cabling problem. because it seems to happen more in certain areas of the table. but switching the encoder and servo cables did not fix it.

I have swapped encoders with another axis, no effect.

have swapped servo amps, no effect.

Switching LSI chips, no effect.

It does seem to be more of a problem when it is warm.

I am ready to do a brain transplant to fix this dinosour or this machine has gota go.

PS: Any one want to buy a slightly used 11M control?

[tc429]

hmm...11 was usually a pretty solid control for us, except for maybe the 9" crt power supplies...

we had a old 6 that was doing goofy stuff, found the manual absolute switch was intermittently shorting on, been ages ago, dont recall if position display changed, but think it did....ive never really used manual absolute, so not exactly sure how it affects the control.

are the master/rom-ram/BMU cards fairly clean? dirty boards can cause a lot of grief... I recall theres a bunch of buss chips on the master that can get flaky and cause weird stuff, (74ls244 or something like that?) but only ever saw that once.

[Todd Zuercher]

This machine dosn't have a manual absolute switch. The ZNG switch is messed up, but it was diabled (cut out) a long time ago.

[memoryman]

Todd, I suggest that this unusual problem maybe power supply related. Have you swapped that for a known good one? It is also possible that the motherboard is defective. What is the motherboard part #?

[Todd Zuercher]

No I have not tried another power supply. I do not have a spair one to swap with.

We had tried another MB about 4 years ago (from Fanuc). It didn't help so it was sent back.

Our MB # is A16B-1010-0050/113

Which powersupply, the one that plugs inthe MB?
Its # is A16B-1210-0560-01

[memoryman]

yes, that is the power supply.
We have a working control that is used for occasional testing and we could work out an arrangement where you pay for shipping both ways if you don't need anything. You can call me at 289 389 6117.
Bill

[Todd Zuercher]

How about the Power Supply. That is one of the few things that I know that we have not tried.

[memoryman]

how long would you need it in order to prove that the problem is gone?

[Todd Zuercher]

As the machine is now, I can get it to mess up in 5-10 minuts with the right file.

1 day should be plenty.

[memoryman]

call me after 9am EST at 289 389 6117 and we'll work it out

[Dan Fritz]

The fact that the position displays all show the shift in position tells me that the control still knows where it is, which means that it's not in the servos or in the positioning LSIs. The control is getting a command to move to that new position from somewhere. Some likely causes:

1) The control is mis-reading the program data. Are you running through a serial DNC connection or a BTR connection, or are you running a program that's in the 11M's bubble memory?

2) The control is picking up a tool offset somehow, or the offset amount is changing unexpectedly. Are you using any tool offset commands in the program? (G43 to G49)

3) A +24v input signal that freezes the Z axis position (ZNG or "Z neglect"). Is there a panel switch or button for that function?

4) If there is a switch on the panel for "Machine Lock" (MLK) then if this switch signal comes on when the Z axis is moving, it will shift the Z position.

My bet is on scenario #1. You mentioned that a new Z command will return the Z axis to the correct position, which tells me that it's probably mis-reading a Z move in the program by changing a digit or dropping a decimal point from a Z move at random. If you're running from a DNC computer, it could be in the buffering of the data or a buffer overflow condition. If you're running from the bubble memory, try this trick:

Take a program that's mis-behaving and send it to a computer through a serial connection. Then (leave the old program in the memory), but re-number the file on the computer with a new O-number. Then load it into the Fanuc memory using the new O-number and run that program. If the copy of the program runs OK, but the old one misbehaves, you may have some bad loops in the bubble memory board. Putting a copy of the program in while leaving the old on in memory forces the control to use a different set of loops (like disc sectors on a hard drive) for that data.

Bubble boards can be reformatted and re-initialized, but it is a pain. New bubble boards are expensive. A less expensive fix would be to run the machine in TAPE mode from a computer using a serial DNC link. That would avoid the bubble memory board altogether.

Hope this helps.
Dan Fritz

[memoryman]

good post, Dan. Some things to consider:
offset and position data is stored on the BMU.
point #1: there is no Z command in the block where the problem occurs
point #2: there is no Z offset in the block where the problem occurs
point #3: doesn't the ZNG freeze the Z movement too?
Todd Zuercher: does the Z axis move when the problem occurs?