Limit switches triggered on machine off

Hi, I'm finalizing my mesa 7i96 setup, in which I used a contactor to cut the power to all the PSUs when the machine is turned off.
However today, during the first test, I discovered a problem: when the machine is in its off state the 7i96 (correctly) detects the missing power on the limit switches input (i'm using PNP NC sensors, so 0v means that the limit switch is triggered), and it reports an out of travel error which prevents the machine from being turned on.
How could I solve this issue? I was thinking about combining the limit switch signal with the "machine on" one with an AND, but it takes a little while for the power to reach the sensors, so it might still not work.

Another question: in my machine (a 3d printer) i configured the vertical axis as W to obtain better smoothness during printing, but this way I can't jog the vertical axis using the keyboard anymore. Do you have a hint to find what part of the source of axis/gmoccapy I should edit to change the key bindings, so that I can move the W axis usig page up /down?

Personally, I would not cut the field power. I would have thought disabling limit switches was a safety issue in itself.

But using and2 makes sense. If you add the timedelay component, you can allow everything to power up again.

generally I believe most people turn on sensor power with estop rather then machine on - avoiding this problem.

I wonder if ignore limits button would work?
Other wise some fancy HAL/or adder trickery to ignore the limits when machine is off (seems wrong to probably will work) maybe a mux that switches between a constant when the machine is off to the actual limit switch when the machine is on.

Can you explain how W gives you better smoothness then Z?

Let's say that cutting power to the switches is more of a consequence of how I built the control box than a planned thing.
I have my limit switches powered with the same psu that gives power to the heating elements, and that needs to be powered off in case of any malfunctioning.

On the other hand the mesa board is powered by a small 5 volt psu, and I have abother 24v psu which only powers the contactor through the mesa board and the estop button.
I could power the switches with that, but I find it cleaner to just have a source dedicated to the contactor.


By using the Z axis for the extruder motor and W for the vertical joint I get most of the movements in the X Y Z space (the only exceptions are layer changing lines) where the newer trajectory planner can be used.
On the oher hand by leaving the extruder motor set up as W 99% of the gcode lines move the machine in a XYW space, and this causes very low speed on curves / corner due to poor blending of the lines (for what I have been told the tp introduced in linuxc 2.7 only works with XYZ movements ).
However this choice has its downsides (wrong key binding, messed up preview etc)


I'll start looking into the timedelay component, so that I can test it tomorrow. Any idea for the jogging problem? Axis and Gmoccapy are python based, I should be able to modify that kind of stuff without compiling everything right?

Muz94 wrote:

Any idea for the jogging problem? Axis and Gmoccapy are python based, I should be able to modify that kind of stuff without compiling everything right?

Its a long time since I ventured into it but Gmoccapy.py is about 5000 lines of python code. AND yes, you don't need to recompile.
See: github.com/LinuxCNC/linuxcnc/blob/master...gmoccapy/gmoccapy.py

I'm not sure where it ends up once its built.

cmorley wrote:

generally I believe most people turn on sensor power with estop rather then machine on - avoiding this problem.

This is actually a cool idea. Instead of tying the field power to the x axis amp signal as i'm doing I could connect the mesa pin to the estop signal (inverted). This way I should be able to turn on the machine as the switches would be powered on when releasing the e-stop.
Or maybe the limit error triggers the e-stop? I don't remember.
This would have the consequence of having the machine actually fully powered before turning it on with f2, but at least any alarm would still be able to cause the machine to power off.

Another question: in my machine (a 3d printer) i configured the vertical axis as W to obtain better smoothness during printing, but this way I can't jog the vertical axis using the keyboard anymore. Do you have a hint to find what part of the source of axis/gmoccapy I should edit to change the key bindings, so that I can move the W axis usig page up /down?

If using AXIS I think you could use the .axisrc option to redirect keybinding.
These seem to set the bindings for jogging:
bind_axis("Left", "Right", 0)
bind_axis("Down", "Up", 1)
bind_axis("Next", "Prior", 2)
bind_axis("KP_Left", "KP_Right", 0)
bind_axis("KP_Down", "KP_Up", 1)
bind_axis("KP_Next", "KP_Prior", 2)
bind_axis("KP_4", "KP_6", 0)
bind_axis("KP_2", "KP_8", 1)
bind_axis("KP_3", "KP_9", 2)
bind_axis("bracketleft", "bracketright", 3)

The number represents the axis 012345678 = XYZABCUVW

So maybe
bind_axis("Next", "Prior", 8)
bind_axis("KP_Next", "KP_Prior",,8)
bind_axis("KP_3", "KP_9", 8)

Great, i'll try that tomorrow.
I actually used gmoccapy on the machine, but I switched to axis recently as it seems more stable and light ( but lacks the industrial look of gmoccapy) .

I want to fix the jog issue because I already crashed the machine once as the interface got stuck during jogging from the gui, and i'd like to avoid that

I managed to solve the main problem using AND2 and timedelay components.

Using axisrc with those commands instead didn't make a difference for the key bindings.