Retrofitting a 1986 Maho MH400E

Oh yeah! Now get a backplate, wire this bad boy up and feel the freedom

Normally, German HSS cutters of this diameter are in the 20-35€ range, now I get your easy come easy go attitude about all this. You can sometimes buy tool lots at good prices from places like surplex, which I think would be a pretty good deal if you have a tool grinder.

With this pendant design I would recommend getting a Haimer/Mahr 3d taster for work offsets. You'll be able to stand close enough to the touchscreen to select axis and offset values since these devices have large dials. It saves you from having to see the material edge and distance, while the pendant still allows for precision control in small increments. The original pendant was similar in that regard (but with Linux it's not necessary to memorize values before entering them to the offset table; big win in my book, standard feature on all modern controllers).

I noticed just now that the MC values set following errors for maximum output voltage from the NC. That's why the Philips values are so large. So maybe tuning can go like this: set up an acceleration value from the range suggested by Indramat, increase the axis following error to a large value (probably some 20mm), set PID to 0, command rapid traverse, measure the error in halscope, compare to sample MCs from the MH500C, adjust PID with that range.

The output voltage in the MCs is listed as 9V because Indramat recommends there should be some wiggle room in case of overshoots from the NC. So all these parameters and the servomotors are set up for lower assumed voltages than 10V. Idk if that has any bearing on anything, but I will assume that it's better not to retune the servos themselves and just limit tinkering to the Linux side of things.

Did you look at JTs velocity mode servo tuning tutorial?

gnipsel.com/linuxcnc/tuning/servo.html

The primary tuning parameter for velocity mode drives is FF1

FF1 can be tuned with a small P value
it is independent of P and the error caused by too high
or too low FF1 are more visible when P is small

Basically FF1 (when correct) sets the drives velocity per
servo period to LinuxCNCs velocity (no feedback involved)
So with just FF1 you are "dead reckoning" and will drift out of position
because

1. The drives drift
2. The velocity command is not precise
3. The timing is not precise
4. The velocity feedback in the drives is inaccurate

This is where the proportional feed back (P term) comes in
to correct the errors above, but FF1 is still the primary tuning
parameter for velocity mode drives

Hey PCW,

Yes, I've been tuning the axes like that before. Now I'm trying to compare these results with the original performance before the retrofit. The point was that we want the acceleration to be within the drives' recommended values but it would seem that presupposes a much higher following error. I'm trying to figure out what values for following errors are acceptable based on the old documentation and settings.

It seems to me that it might be possible to "overtune" a drive, limiting its performance by being too stringent with the errors. It's very audible in my case, I can hear how different PID affect the drive's idle state. BTW, I should've said that earlier, I'm using PID as a shorthand for the tuning parameters. I haven't really tried using I or D. It's just easier to write than P, ferror1 and ferror2.

Mark, if when you have an opportunity, please take a picture of your encoder connections to the Mesa card. I think my wiring sucks - I started the machine today and the Z encoder didn't register changes in the slide position. Then I switched it off, checked the wires, took out the TB, put it back in again and it works. I think I should provide better shielding or something, I'm curious to see how a pro made the physical wiring. The original D-sub terminals were massive metal shells, unlike anything I'd seen, I'm sure they provided superb noise shielding and stability.

Do you actually know the original performance? I suspect you are trying to get much lower following errors than the original control (since you can see them)

Too high P term will result in buzzy/rough control, too low will have more following error so its always a compromise. You can reduce dithering at idle by adding some deadzone.

If unplugging/plugging the Z encoder connector fixes a non-working encoder I would

1. Make sure you don't have a loose wire on the connector (its easy to get the wire on
the wrong side of the rising clamp if you don't completely loosen the screw before
inserting the wire)

2. If #1 doesn't fix your problem, replace the Z encoder connector

Thanks a lot! I didn't even realize there was a wrong side of the clamping connector...

Regarding the performance, I did work on this machine for over 1,5 years before plunging into this retrofit. Deadzone is an excellent idea I wasn't aware of.

I know that the acceleration rates were supposed to be higher than what Mark set, and when I tried to increase them I came up with low values as well because I wathced the error value too closely.

It turns out that the recommended acceleration for the Indramats was ca. 220 mm/sec2, and that the machine had following errors orders of magnitude larger than what I was trying to force on it.

So far from further experiments I was able to get an acceleration rate of 320 on X, 280 on Y and Z without following error exceeding 0,04mm in rapid traverse.

This is kind of a forced rapid traverse, I'm just using G1 at the requested feedrate.

At present, Y and Z achieve measured acceleration rates in the vicinity of the recommended Indramat specs, but X lags behind at over 320 ms until 3000 mm/min is achieved. I think the other axes are doing better only because their max feedrates are slower due to finder ballscrew pitch.

Anyway the machine is starting to sound and behave much more like before the retrofit. I'd be curious to hear how you can do Mark.