Debug for endstop activation possible?

gnydick

I'd like to output a message to the debug stream when endstops are hit, but I can't seem to find anyplace that happens. I have all of the debugging enabled, but nothing outputs when the endstop is hit.

Phaedrux

If it doesn't currently do that, maybe you can explain what you're trying to accomplish, maybe there is another way.

gnydick

@Phaedrux I have a sensor/switch that triggers for only 20 microseconds. There is no way to verify it's getting tripped. The DWC won't show it and a volt meter went respond that quickly. So I just want to see if the firmware sees it tripping.

Phaedrux

Well I suppose if you set it up as a trigger you could see if it will trigger the macro you create.

gnydick

@Phaedrux that's why I want the debug output. I don't know if it's failing to trigger because it's so fast and the firmware can't catch it or if the sensor isn't working. Only way to know for sure is from the horse's mouth.

dc42

@gnydick said in Debug for endstop activation possible?:

@Phaedrux I have a sensor/switch that triggers for only 20 microseconds

Existing main board firmware almost certainly won't see a pulse as short as 20us. Duet 3 expansion and tool board firmware might see it, if it gets through the debounce filter.

gnydick

@dc42, thanks. While we're in the topic though, can you have a crack at the original question? I'm happy if you just point me to the source code that enumerates debug events of you want.

gnydick

@dc42 what about 20 milli-sec?

dc42

In current main board firmware, the endstops are polled in function CheckEndstops which is in class DDA. So you could put a call to debugPrintf in there.

A 20ms pulse will be long enough provided that the step rate is at least 1 step per 20ms, so 50 steps/sec, which should always be the case when homing. For example, 10mm/sec @ 80 steps/mm would be 800 steps/sec.

Expansion board firmware uses interrupt-driven endstop inputs. Future main board firmware will too.