Retrofitting a 1986 Maho MH400E

I got the motors to energize by actually connecting the ground from the Indramat to the 7i77 TB2-6 pin (TB-7, as you suggest in your schematic was already connected to the 19k2 relay). I had previously connected all the original grounds to a terminal on the cabinet (Picard facepalm.jpg),

Now I get a Y following error and the machine estops. Z and X don't seem to move (looking at either motor with the cover off, or on the DRO). If I increase the allowed error, it just moves more before it estops. I remember that with the original wiring, the drives would turn left and right when idle, producing a hum but maintaining position. This is different and it might be hard to troubleshoot for a newb like me.

Possible problem areas are: PID, encoder noise caused by poor wiring, or some config parameters in one of the files.

You have a~50% chance of having axis "runaway" when first setup since you may have the feedback reversed

Basically you need to

1. Get drive enables working
2. Get encoders working in the correct directions and correct scale
3. Get feedback direction correct (you may need to invert the analog output scale)

Expect runaways!

JT has a nice velocity mode servo tutorial here:

gnipsel.com/linuxcnc/tuning/servo.html

As PCW said, this is normal, and is probably just settings, sign error, maybe a wrong scale, bad tuning parameters.

First leave the drives off, and turn the X and Y ball screws bay hand. Are DRO's moving in the correct direction? (would indicate Sign error in the Ini:Is the distance travelled correct? 5mm ball screw, two rotations = 2 mm travel would equal a scale error in that same line.

Manually wind X and Y all the way to the end stops and make sure the end stop switches are correctly set before the ballscrews go on block and self destruct.

Unplug the encoders, and power up the drives. The machine was working under Phillips control, so the drives should be correctly tuned. Without the encoder connected, you should only get very slow drift.

Is yours also a MH400E or one of the larger models? Your P, FF1 and FF2 may well be significantly different to mine. You need to work through that servo tuning link PCW sent you, and need to befriend HALScope. It is going to be your new BFF until you get the tuning set.
Mark

Thanks PCW!

As usual though I've no idea how to accomplish any of the above steps

Thanks Mark!

Mine is an MH600E, so it's probably different in terms of tuning.

I'll try your suggestions so that I can work with Halscope and determine the correct tuninig parameters. It's kind of impossible now when the axis drifts

EDIT: Just saw your edit, why exactly would you set the encoder scale to -? I was under the impression that this was the parameter determined by the accuracy of the linear scales, so that 1000 meant 1 micron. Why would it need to be a -?

What you have now is probably not drift but runaway. Unplug the encoders (The MESA's plugable connector strips are really handy here) and power the Indramat. My MAHO hadn't run in years, but the Indramat was well tuned and the axis only drifted very slowly.

I'd start with Z Encoder disconnected (hopefully you can get the other axis holding before it drifts too far.) Start with only one axis (Y is easiest as you are next to it), so disconnect X encoder as well.

Manually set Y in the middle of travel. Give it a huge min_Ferror in the ini like 10*. When you switch on the drive watch the dro and see which way it runs, verses the actual movement. Runaway is normally a sign error in either encoder_scale and/or output_scale INI parameters. If you look at my INI they are not consistant.

I just noticed that I never reset my Z Ferror when I finished tuning.
Mark

The negating encoder scale or output scale change whether it counts up or down. If it is a wrong sign, linuxcnc detects a position error, and commands a voltage to the indramat to move it back to zero. If the scale doesn't match the axis, the movement causes a larger error, linuxcnc commands still more voltage, and soon you are runaway at max velocity. Emphasis on max as in Boeing 737 Max

The value in encoder scale is the increment 1000=1µm with the EXE you have.
Mark

One thing I managed to quickly determine with the DRO was that the Y axis was actually the X axis, because when I moved the Y by hand it correctly displayed the direction in the X field. So direction error is quite likely as X should have 0 near home while Y has home near 400 (max travel, on the Philips it home on 390; in fact all axes homed 10mm from their limit switch, it'd find the switch, move back 10mm and it was homed).

Oh, reversed axis encoders cables will of course cause run away. It senses an error in Y, powers motion in X which moves, now it commands motions in X to correct that error, and Y accelerates...... both run away.

You just unplug the M23 connectors of the encoder cables and interchange them
Mark

Changed the signs and the machine latches on! The axes have to be switched of course. It keeps going back and forward like on the Philips, but noticeably faster. I guess that means I should get to tuning until it sounds like before?

EDIT: The movement is within 1 micron on the DRO by the way, it just maintains position that way.

EDIT2: okay, the behaviour is definitely wonky and needs to be fixed, but I'm really stoked I managed to get this far! It's time for lunch.

EDIT3: before I go, just in case: Z DRO doesn't register movement at all while the axis moves (but the encoder worked when break released and drive wasn't energized), the rest I have to assign correctly and check with a dial indicator whether the commanded increments check out.