Retrofitting a MAHO MH500W '89-'90 with hand-feed
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
Please Log in or Create an account to join the conversation.
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
[2] When you pull the handwheel out do you then have manual control of the leadscrew?
The main trick with making that work would be preventing the machine from instantly f-erroring when you move the axis.
You could use HAL to make the f-error limit very wide, but then the macchine would want to instantly shoot back to the original commanded position when the handwheel is pushed back in.
It would be far easier to disconnect the handwheels from the mechanics and fit MPGs in the same place (or somewhere more ergonomic)
I think that the real answer probably involves doing something with external offsets. But there might be a way to use a (Python) HAL component to MDI a G0 to the new position, then wait until commanded position and actual position match, and then re-enable the servo amps and set the f-error limits to a sensible value.
An alternative might be to unhome and then rehome the joint when the handwheel is pushed back in.
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.
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
I guess you would need to hold the handle, and / or set the slide lock.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?
Please Log in or Create an account to join the conversation.
[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
Yes, I am sure the handwhell get's engaged to the ballscrew (or the rotating nut depending the axis).When you pull the handwheel out do you then have manual control of the leadscrew?
I was quite nice feeling tbh, I could feel the dynamics on the hand weel, unlike a jog pendant.
Really? . I have a small cnc mill that I would like to manual jog quite often if I could.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.
I hear you. Better to have something working, than something fancy never working.
Nice idea with the offsets.
Unfortunately, I might not remember very well, but I think Z-axis was not drifting somehow.I guess you would need to hold the handle, and / or set the slide lock.
Please Log in or Create an account to join the conversation.
All this is MAHO side: to power on the machine (left side of the picture),
- the mushroom must be not pushed,
- K1 relay must be energized and
- 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.
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
- Posts: 19285
- Thank you received: 6457
If yes,
-leave everything as is
-estop input in Mesa to e-stop-ext in hal
-drive enable to x-enable or machine-is-enabled in hal
-no latch
--
Some things to keep in mind,
-you do not want the machine to cut power to everything because of a joint error or a tripped limit or home switch
-as long as LinuxCNC has full controll of drive enables, the rest is more or less OK.
-you have a physical e-stop, so no need for a software one, in case of need, finding the e-stop on screen and clicking on it takes much longer than pushing a button by palm/hand/foot.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
- /ESTOP: this is the external estop (LinuxCNC input)
- P_ON: the control of relay K1 (LinuxCNC output)
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.
Please Log in or Create an account to join the conversation.
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
Attachments:
Please Log in or Create an account to join the conversation.