Slightly confused about "!"...

Nightowl

Currently, my three NO limit switches are set up with these lines in the config.g file:
; Endstops
M574 X1 S1 P"!io8.in" ; configure switch-type (e.g. microswitch) endstop for low end on X via pin io8.in
M574 Y2 S1 P"!io6.in" ; configure switch-type (e.g. microswitch) endstop for high end on Y via pin io6.in
M574 Z2 S1 P"!io2.in" ; configure switch-type (e.g. microswitch) endstop for high end on Z via pin io2.in
As I'm replacing the limit switches with four NC proximity sensors, should I remove the "!" to invert that setting?
(The 4th PS will be set for io3.in for the Y1 axis)
Thanks

Note: I've posted this in the Duet3D Affiliated FB page too.

fcwilt

@nightowl999

Assuming all is as you have stated, yes, you should not need the exclamation point.

But it is easy to determine the state of any of your endstop sensors using the DWC Object Model viewer.

Frederick

Phaedrux

Or by sending M119 to see the switch state.

fcwilt

@phaedrux said in Slightly confused about "!"...:

Or by sending M119 to see the switch state.

True but the Object Model viewer responds in "real time" to any state change.

Frederick

Nightowl

Actually, I've got the EndstopsMonitor installed, but this doesn't show a state change, either (I haven't edited the "!" out yet), but I thought, even if the proximity sensor was inverted, the LED would be 'on' until the sensor was activated, but I'm not getting that, either.

oliof

@nightowl999 are you sure your proximity switches run on 3.3v and did you wire them correctly so they match the pinout on a duet board (which is different than the one on RAMPS boards and all the ones following that convention)?

Nightowl

@oliof They run on 5V adequately, but I'm beginning to think it's a wiring issue.

I'm using CAT6 plugs and sockets, so aligning the cables has proven to be a bit of a pain!

fcwilt

@nightowl999 said in Slightly confused about "!"...:

Actually, I've got the EndstopsMonitor installed, but this doesn't show a state change, either (I haven't edited the "!" out yet), but I thought, even if the proximity sensor was inverted, the LED would be 'on' until the sensor was activated, but I'm not getting that, either.

Do you mean the LED on the Duet?

That LED reflects that state of the hardware. The ! character inverts how the state is interpreted.

Frederick

Nightowl

Ok, @fcwilt, thanks.

I've discovered it's actually a wiring issue, so I'm in the process of sorting that out, but the EndstopMonitor I was referring to is a plug-in (from the Duet3D DSF plug-in page) but I'm not sure why it's only showing 3 of the 4 proximity sensors.

Is it because I've grouped two together (second line):

; Endstops
M574 X1 S1 P"io8.in" ; configure switch-type (e.g. microswitch) endstop for low end on X via pin io8.in
M574 Y2 S1 P"io6.in+io3.in" ; configure switch-type and dual self-squaring high end on Y1 and Y2
M574 Z2 S1 P"io2.in" ; configure switch-type (e.g. microswitch) endstop for high end on Z via pin io2.in

Also, is it necessary for the Endstops to be configured in order, i.e. 2, 3, 6 then 8?

Thanks.

Phaedrux

@nightowl999 said in Slightly confused about "!"...:

Also, is it necessary for the Endstops to be configured in order, i.e. 2, 3, 6 then 8?

The only time order of the endstops matters is your Y axis with multiple motors and endstops. The order of the endstops should match the order of the assigned driver/motors in the M584 command.

@nightowl999 said in Slightly confused about "!"...:

M574 Y2 S1 P"io6.in+io3.in"

So io6.in should match the motor that corresponds to the first Y axis driver listed in M584

Nightowl

Awesome, @phaedrux, thank you

zapta

BTW, moving from NO to NC is a wise move.

Nightowl

Interesting, @zapta. Would you mind explaining why, please?

achrn

@nightowl999 If you use NO and the wire becomes unplugged or a wire breaks the machine doesn't notice. When something reaches the endstop and hits the switch, the machine still doesn't notice. Things crash into things.

If you use NC, as soon as the wire breaks or comes unplugged, it looks to the machine as if the endstop has triggered. Everything stops. Nothing crashes into anything.

That is, if a connection or wire failing looks the same as the endstop triggering, when it happens it's normally a 'fail safe' situation.

zapta

@nightowl999 said in Slightly confused about "!"...:

Interesting, @zapta. Would you mind explaining why, please?

I think NC considered a good practice because disconnection failure is more likely than a short failure. With NC and disconnection, your homing will stop immediately rather than crashing into into the mechanical end.

Nightowl

Brilliant, thank you both, @achrn and @zapta