Retrofitting a 1986 Maho MH400E

Johns machine already ate a ballscrew with it's previous owner because of a limit overrun crash. I don't see him jumpering that E-Stop system for homing
Mark

If adding a separate home sensor the ideal target for the prox is half the length of the travel, so that the home is in mid-travel and the prox state when homing commences sets the direction.
(ie, if the homing switch is set when the button is pressed then the machine switches "search" and goes to "back-off" immediately)

So the sensor must outputs 1 for half the travel and 0 for the rest half, so searching direction is depending on the state of the sensor. Clean, clever and safe, thank you for that solution. Putting a relay on the estop circuit to disable the limits during the homing and rout the NO contacts of the switches (if there is any) to mesa is one solution but not the safest one. The previous owner of the machine had rerouted the limit switches to mesa card, and during the testing as Mark said he crashed the machine.
John

Darn, I've run out of 0.14mm² ferrules, so I wont be able to permanently wire up the ribbon cable signals from the Maho 28A1 relay boards I/O to the 7i84 yet.

I am trying to get my head around the HAL. I was going to ask for help about three hours ago, but the process of writing the question, clarified it for me. Sort of...

I am trying to get the Maho to latch on under LinuxCNC control.

I have a physical 2 pole "MACHINE START" momentary switch, with one pole (NO) to close the physical E-Stop chain, which won't latch until the NC-Ready signal from the linux CNC closes the 19K1 latching relay.



With the E-Stop circuit temporarily closed, I thought that I could pick up an E-Stop.Ext signal from the MAHO relay boards output.

So I finally cut a MAHO cable. Chopped ribbon cable, no going back now. Wired it up, added the net, looked at it in the HALshow. Nothing. Checked the ribbon cable. Oops, I'd wired up the 5th strand, instead of the 4th. Tried again, still no signal. Came up to write this, pasted the wiring diagram, noticed, oops again, I'd wired up 28X1-4 (MAHO input ribbon cable) instead of 28X2-4 (MAHO output ribbon cable). I'll try that again.
....
net estop-ext <= hm2_5i25.0.7i84.0.2.input-17
Okay that works. Pushing the start switch closes the physical E-stop chain, LinuxCNC detects that and releases the E-Stop button at the top of the screen.

Now to latch it. That second pole of my start switch, which is (NC) and will need inverting, gets fed into LinuxCNC to pin hm2_5i25.0.7i77.0.0.input-04-not
Tested in HALshow okay.

This button will physically be my top RH softkey.


net gmoccapy.v-button-0 <= hm2_5i25.0.7i77.0.0.input-04-not
Question - Shouldn't this be in the postgui.hal?

What I didn't realise is that gmoccapy.v-button-0 is a predefined pin. My net above creates a second gmoccapy.v-button-0 as a signal, which follows the input, but is of course not connected to the gmoccapy functionality. What is wrong with my syntax there? Can you even net pins directly to pins? So far LinuxCNC is detecting the change in E-Etop state, but not yet reacting to the direct machine start command.

In the PNCconf generated HAL you have the line:
net machine-is-on halui.machine.is-on

so I wanted to use that to command the latching relay.
net machine-is-on => hm2_5i25.0.7i84.0.2.output-08

this is putting the tail before the dog, as this signal wont go true until after the LinuxCNC button second from top is pushed. I was going to use that LinuxCNC machine start button for drive enable on the Indramat, but I guess it can do both. Unless there a HAL signal like "LinuxCNC is ready for the machine to be turned on", then to start you'll need to hold down both the physical start switch and the second soft key " machine start", as that does trigger the machine-is-on signal. I tried it the double button push, but it didn't latch. I'll take a break and see what wiring screw up I made on that signal.

Question - is there a "LinuxCNC is ready for the machine to be turned on" signal available?

I guess a two button push start is true to the machines Phillips 432 DNA.
Mark




Mark

RotarySMP wrote: What I didn't realise is that gmoccapy.v-button-0 is a predefined pin. My net above creates a second gmoccapy.v-button-0 as a signal, which follows the input, but is of course not connected to the gmoccapy functionality. What is wrong with my syntax there? Can you even net pins directly to pins?

The "net" command always needs to have a signal as the first entry. And you can choose any name. To connect two pins you can use all on one line, or use multiple lines (quite often in different HAL files)

Question - is there a "LinuxCNC is ready for the machine to be turned on" signal available?

There _no_ pre-defined signals. They are all defined in your HAL files. What you probably want is to make a signal driven by one of the iocontrol pins
linuxcnc.org/docs/2.7/html/man/man1/iocontrol.1.html
There is a chance you might need the "not" HAL function
linuxcnc.org/docs/2.7/html/man/man9/not.9.html
It is also worth looking through the halui and motion pin lists. Between the three you can find pins to do most things.
linuxcnc.org/docs/2.7/html/man/man1/halui.1.html
linuxcnc.org/docs/2.7/html/man/man9/motion.9.html

After sleeping on it, I figured out the problem with connecting to the gmoccapy.v-button-0 pin. This is only available after the gui loads, so I moved the net to the postgui.hal.

net sig_gmoccapy.v-button.0 <= hm2_5i25.0.7i77.0.0.input-04-not
net sig_gmoccapy.v-button.0 => gmoccapy.v-button-0
...works.

When I push both my physical start button and the machine run gui soft key, both the
machine-is-on and hm2_5i25.0.7i84.0.2.output-08, but the 19K1 relay is not latching. Need to take another look at that wiring.

I hope I get faster at this stuff, as keeping making three errors per net will make this project stretch till the cows come home.
Mark