How to log triggering of endstop microswitches

Triet

Hello
Is there a way to put a message somewhere if any endstop microswitch is triggered, specially when this happens unexpectedly (for example due to EM noise)?

Assuming that an executable trigger file can be associated with this event, then modifying it to output a message to a file would be fine. Is this possible?

moth4017

@Triet im not sure you can trap a false trigger in the object modlel there are the following

If you getting false triggering check you have pull up/down resistors

soare0

@Triet Yes, this would be ok to do. BUT: I myself did not found a gcode to write in/a random file! I you find it, please let me know. So, for now, listing the events in console is the easiest thing to do.
However, as moth4017 specified, you should check on your pull-ups/downs, first.

Triet

@moth4017 said in How to log triggering of endstop microswitches:

If you getting false triggering check you have pull up/down resistors

I never cared about resistors because I was assuming that they are built-in in the Duet2 WiFi PCB.
Could you confirm I need the resistor in this case?

I just rewired the connection to NC (normally closed) mode, still getting layer shifts of unknown origin. Belts are tight...

Triet

@soare0 said in How to log triggering of endstop microswitches:

Yes, this would be ok to do.

Which trigger file should be used to put the M118 (output some text) then?

I am just checking if any message can be output anywhere besides the console.
I have enabled some output alread using:
M929 P"eventlog.txt" S1

But I am still unsure if it is possible to log endstop triggering there.

Triet

@soare0 said in How to log triggering of endstop microswitches:

However, as moth4017 specified, you should check on your pull-ups/downs, first.

I just found this sentence in the Gcode documentation describing the M571 command:

"Enable pullup resistor with ^ if using Duet 2, running RRF3, using the Z probe input pin, and the probe type is a switch or BLTouch."

I am checking if this is also valid for the endstop microswitches.

Triet

@Triet
Again, in the documentation of the M574 command ("Set endstop configuration") I can read:

"Pull up resistors on Duet 2/Duex5 inputs should be configured for connecting a digital inputs (like a switch, BLtouch, etc) only on inputs not labelled "n"Stop (xstop, ystop etc)."

So it states clearly that no pull up resistors should be "configured". Does that refer to the built-in resistors or does that imply that no external additional pull up resistor should be connected?

I don't understand why the user is supposed to tinker with the Duet board (like soldering resistors) in order to do something that is even recommended in by the vendor.

oliof

@Triet you can enable the pullups in the board config by prepending the pin identifier with ^, i.e. ^xendstop

Triet

@Triet said in How to log triggering of endstop microswitches:

"Pull up resistors on Duet 2/Duex5 inputs should be configured for connecting a digital inputs (like a switch, BLtouch, etc) only on inputs not labelled "n"Stop (xstop, ystop etc)."

Reading more carefully, this might be valid only for Duet2 boards used together with a Duex5 expansion board. This wording is unfortunate, as it is not clear how exactly it is meant: Duet2 alone OR Duet2+Duex5?
I do not use Duex5.

Triet

@oliof said in How to log triggering of endstop microswitches:

@Triet you can enable the pullups in the board config by prepending the pin identifier with ^, i.e. ^xendstop

OK, I will try changing my config lines to

M574 X1 S1 P"^xstop"
M574 Y2 S1 P"^ystop"

and see how it goes.
Thanks for confirming.

gloomyandy

@Triet The Duet2 endstops already have a pull up resistor on them. You can see the details here: https://docs.duet3d.com/User_manual/Connecting_hardware/Sensors_endstops along with the recommendation to use normally closed switches with the switch between ground and the input pin.

Triet

@gloomyandy said in How to log triggering of endstop microswitches:

The Duet2 endstops already have a pull up resistor on them.

Thanks, that is fine. I have already enabled them.

gloomyandy

@Triet You don't need to enable a pullup, the board has them built in on the endstop inputs as part of the circuit that includes the indicator LEDs. Take a look at the link I included it is all explained under the Duet2 tab. That same link also explains what the best way is to wire your endstops to avoid emi issues.

Triet

@moth4017 said in How to log triggering of endstop microswitches:

@Triet im not sure you can trap a false trigger in the object modlel there are the following

I even found an "Endstops Monitor Plugin", so that now I can see the same thing unter "Settings->Machine-Specific":

I don't see how to configure a possibility to log anything either.

droftarts

@Triet The endstop plugin just shows the state from the Object Model. It's also not being updated for RRF 3.5, as the endstop status is shown on the axis legend in DWC now.

Another way to log disconnections is to use triggers. Endstops are only active during homing, the rest of the time they can act as limit switch triggers. Set up with M581:

M581 T3 X Y S1  ; invoke trigger 3 when the X or Y endstop switch is triggered

Set up a file called sys/trigger3.g that appends a message to a file (see https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#echo-command

; trigger3.g
echo >>"endstop_error.txt" "Endstop triggered at {state.time}"

Make sure sys/endstop_error.txt exists before this starts. Or add some conditional gcode to check if it's there, and either create it or append to it. Note: the above is not tested, and may contain errors!

Ian

Triet

@droftarts
You have put a lot of valuable information in a couple of lines - thanks!

Edit:
I changed the trigger3.g file this way:

echo >>"endstop_error.txt" "Endstop triggered at ", {state.time}