forum.cncdrive.com

From time to time I encounter an accidental input such as a finicky limit switch being triggered. Sometimes it's unfiltered noise, sometimes it's human error or even just dust on a contact. I enjoy the fail-safe estop condition but after the fact I would like to know what caused it. The console output is only telling me "Limit switch triggered" but it's doing a very good job at keeping which input a closely guarded secret. I've poked around on the forum here and the spots mentioning anything like this are generally asked to correct electrical interference or play with the debounce setting. I can't locate anything in the GUI about increasing the verbosity of the console output.

In the case of accidental triggers they are generally momentary and back to normal by the time I can look into it. Because of this the diagnostic page is no help after the trigger because the indicator will be off by the time it triggers the estop.

I may be able to keep everything running with the help of the debounce setting found in CONFIGURATION > GENERAL SETTINGS > Input signals debounce (msec) but I would really enjoy knowing which input was the culprit. I've had quite the time with inexpensive limit switches sticking.

Is there any possible way to get some increased verbosity in the run console?

In most cases which input is triggered is not useful information, because limit switches are commoned to even a single input pin.

You can try to add a few milliseconds debounce filter to the inputs to filter out noise spikes.
You could also try to add a 100nF ceramic capacitor between the input+ and input- terminals of the AXBB-E or UCBB or UCSB (not sure which one you using?)

cncdrive wrote:In most cases which input is triggered is not useful information, because limit switches are commoned to even a single input pin.

You can try to add a few milliseconds debounce filter to the inputs to filter out noise spikes.
You could also try to add a 100nF ceramic capacitor between the input+ and input- terminals of the AXBB-E or UCBB or UCSB (not sure which one you using?)

Hi Balazs, thank you for the speedy reply to my email and the comments here on the forum! I'm an outlier and went for a larger board in part for the dedicated inputs. Except under rare circumstances I really don't like to merge in/outputs together as it's just too easy to overlook connections and it's even more fun to figure out which one in a series is the problem. This is actually what brings me to UCCNC from M4. The board I was using with M4 was nice, but it had limited I/O and limited my expansion plans.

Maybe the answer here is to customize a screen and add an indicator that turns on (but doesn't self-reset) to off. I have not explored what's available in the screenset customization part of the software yet. At least then I'd know which input it was. Right now it's simply a guess, unfortunately.

Regarding which board is in use, I've got your UC300ETH running atop a UB1 from Weerasak at CNCRoom. To gain some aiddition I/O it is connected to a expansion UD1-U daughter board. There's oodles available here and it's a pity to have it go underutilized.

But I digress, right now the underlying problem is most often vibrations triggering inexpensive switches. Debounce will probably help with this and for possible interference adding in a cap to filter, but there's also times where these limit switches simply fail unexpectedly and this could still end up causing trouble. Actually, this happened today when a Z+ NC switching failed open. This caused the homing procedure to unsafely move in a Z- direction for an excessive travel distance. Ideally it should have acknowledged that something was wrong when it saw Z move beyond the configured back-off distance and spit an error out in the console "Z axis moved -2 units while Z Home was triggered. But back-off is set to -1 unit. This should not be possible. Check Z set parameters. Triggering estop!".

The combined "Limit switch triggered" behaviour of UCCNC is appropriate for general use but I still must insist that having more verbose output to the console would be exponentially more helpful for me and perhaps also help others isolate intermittent triggers. You've gone as far as to allow separate inputs for each axis, and independent outputs for enabling each driver... so why not expose the information to the operator in log that can be reviewed so process can be improved. Taking it a step further maybe not even just for limit switches but it would be insanely helpful for folks like myself if I could turn verbosity up to max and get all status changes to in/outputs shown in the run console. The diagnostic page is neat but fails to show status changes graphed over time.