Retrofitting a MAHO MH500W '89-'90 with hand-feed

I am sharing this, in case anybody has a brain cell or two idling and is interested in what's going on.

Sorry for the long post in advance.

I am retrofitting a MAHO MH500W CNC, from around '89-'90. The machine has about X=500mm, Y=350mm, Z=380mm travels (or close enough).  Also it has a variable pulley for the spindle speed using a 2.2Kw 3 phase motor. It uses INDRAMAT servos and amp and the driver specifically is 3TRM2. 

For the conversion I got a 7i97 and a 7i84 and a MinisForum GK41 USFF PC.

So far so good, but this machine has two very interesting (to me) features, the second I would like to discus here:

• [1] LS403C linear scales which feature Distance Coded Reference Marks: once switched on, using the original Heidenhain control you press some key, the machine moves all axis (one by one) for at least 20mm (the reference marks are apart about 20mm), and the controller identifies/recognizes the machine's absolute position using a lookup table (At least I think it does). But this is to be discussed in the future or never.
  
• [2] The machine has hand-wheels. It can be used somewhat as a manual machine. How? When idle (I don't know what the actual state would be in HAL terms, but when you can jog the machine let's say with a pendant), you pull one of them hand-wheels out and the axis servo motor is released for this particular axis.
  The remaining axes are still enabled so you can cut/jog by just hand feeding. The original controller allows for the spindle to be switched on while hand feeding, so I assume that this mode was intended for cutting too. The super nice thing about all this engineering is that you still have a DRO from the linear encoder.

The screenshot I am attaching is from the MAHO electrical schematics, and shows the INDRAMAT servo amplifier and the inputs that relate to the hand feeding feature. The 8K1, 9K1, 10K1 are directly driven by the controller (LinuxCNC outputs). The 8S2, 9S2, 10S2 which I don't know how to name, are the switches that are activated when you pull out (for about 3-4mm) each of the hand-wheels. The signals 278, 279, 280 are direct inputs to LinuxCNC (previously Heidenhain). 

Now I am trying to understand a bit better where the inputs RF (Controller Release) and JR (Pulse Release) of INDRAMAT 3TRM2 differ (I have a bad quality scan of the manual) but overall I assume that I need to do the following:

When the machine is allowed to be jogged, I should read the inputs 278, 279, 280. If one the them is switched on I should exclusively energize the matching relay 8K1, 9K1, 10K1. I tested the machine with the original controller and the axis you activate for hand feeding stays active until told otherwise (e.g. switch axis by pulling another hand-wheel or using power feeding from the controller, the latter will re-enable all motors). The switches 8S2, 9S2, 10S2 are momentary, not latching.

Although I do SW, it will take me a good amount of time to HAL this thing out. 

The actual question is, it there anything wrong here in my understanding of this?

Note: I've converted a couple Chinese mills so far using steppers (not retrofits) and this is the first time I deal with a serious toy, so what I say might be easy for you, but is not for everybody and definitely not me


 

There is something that I don't understand at all though.

I remember that with the heidenhain cpu, when I was switching the machine off, I could see the Z position drifting by some mm, before the crt display went off. I assume that then the servo brake kicked in.

But if this is the case, how is it possible to release the Z servo for hand feeding and the table not sliding, like when powering down the machine?

This drives me nuts
 

[1] Sounds like a perfect application to use the new pluggable homing module feature:
HOMEMOD here:  linuxcnc.org/docs/2.9/html/config/ini-co...l#sub:ini:sec:emcmot
And a sample homing HAL component:
github.com/LinuxCNC/linuxcnc/blob/master...onents/homecomp.comp
linuxcnc.org/docs/2.9/html/man/man9/homecomp.9.html

When you pull the handwheel out do you then have manual control of the leadscrew?

Yes, I am sure the handwhell get's engaged to the ballscrew (or the rotating nut depending the axis).
I was quite nice feeling tbh, I could feel the dynamics on the hand weel, unlike a jog pendant.

I was careful to retain manual control of my first two CNC conversions. On the third I didn't bother having noticed that I _never_ use the manual option. It's generally just as easy to jog under power.

Really? . I have a small cnc mill that I would like to manual jog quite often if I could.

I hear you. Better to have something working, than something fancy never working.
Nice idea with the offsets.

 I guess you would need to hold the handle, and / or set the slide lock. 

Unfortunately, I might not remember very well, but I think Z-axis was not drifting somehow.

I am trying to understand how my estop configurion will work but I am hurting a bit.

All this is MAHO side: to power on the machine (left side of the picture),

1. the mushroom must be not pushed,
2. K1 relay must be energized and
3. we need to press the power on push button (this is a momentary button).

When power arrives at 7K2 and 7K3 they get energized and subsequently 7K1 is energized.

Then, a contact of 7K1 is in parallel with the power-on push button and thus the power-on circuit retains power.

Additionally, when 7K2 and 7K3 are energized a net with name /ESTOP (NOT_ESTOP) gets 24V and this is indication of normal operation on maho side. If this signal goes to 0V, it means we are in ESTOP.

This /ESTOP signal is a MAHO output (input for my MESA).

The K1 relay is controlled by a mesa output (MAHO input). We need to energize K1 in order to power on the machine and to cut off power to K1 when in ESTOP.

I am trying to think how to wire this to the estop-latch component but I can't.

I am thinking that I don't need to use the user_request_enable for the latch reset, since I do have the push button (so LinuxCNC will work exclusively with only the maho circuitry).

And since the /ESTOP signal (maho output) is indicative of fault, I would wire this to the fault input of my latch (maybe inverted). But how to control the P_ON signal which enables the K1 relay to allow for power on ?

And do I need to use the user_enable_out, is it mandatory? Or phrased better, do I need it in my case?

For sure, emc-enable-in must go to latch.0.output-ok.

The driver/amplifier's motor enable is controlled by this /ESTOP line (the one that goes 24V once the machine is powered on via 7K2 and 7K3). So I don't controll the enable of the amplifier from mesa. 

If you check the screenshot, on the left, only the 3x (+/-) 10V analog controls for the motors I have access to. No drive enable is accessible to control from mesa.

If  /ESTOP goes low, the amplifier is deactivated. Another way to deactivate axis, is by 8K1, 9K1, 10K1 for the handwheels, something that I will not bother with for now.  

There are two signals in maho

1. /ESTOP: this is the external estop (LinuxCNC input)
2. P_ON: the control of relay K1 (LinuxCNC output)

If I wire the /ESTOP to external estop in mesa, what should I do the second signal?
When should I drive it low (and how)?

The complexity in my mind is that when /ESTOP is low (e.g. before trying to power up the machine) then the second signal should be high so the machine can power up so they don't share the same state. 

 

Unfortunately, I am having problems tuning my PIDs.

When the machine is moving with constant velocity shouldn't the f-error be close to zero? like in a resting/idle state? In my case the following error is proportional to moving velocity.

I cannot utilize the I and D terms. I=0, D=0 seems a good value for both and adding any amount bigger than 0.001 to either I or D results in oscillations (different than the oscillations of high P) 

I cannot add either FF1, FF2, FF3, it causes oscillations too. Additionally I don't see why I should add FF0 and FF1, FF2 aren't they related only to the commanded position?

In the pictures, the f-error converges to a non-zero values which is proportional to the moving velocity. 



 



 

 

 




The only settings that work a bit well but (not quite) are:

 


The complete configuration is at

X Axis (all axis have similar configs)
github.com/petmakris/maho-mh500w/blob/ma...onfig/inc/axis-x.inc

Complete configuration:
github.com/petmakris/maho-mh500w/tree/main/config