Slightly confused about "!"...

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