"Hit limit switch" interrupt during placement? Check switch!

[mrandt]

Hi,

I spent quite some time debugging an issue with almost random stops of TinyG during pickup and / or placement of components.

TinyG would shut down with "Hit limit switch" message from time to time when moving Z-axis but could not figure out why at first.

Turns out, the switch I was using for Z-max had electrical bouncing. When the Z-axis was moving up again after pickup or placement, TinyG would not "see" one deterministic state change of the switch but multiple.

See the following oscillogram:

Oscillogram of bouncing limit switch state change

z_limit_switch_scope.jpg (62.58 KiB) Viewed 4213 times

Not sure, if there is any software debouncing done in TinyG firmware and how / with which delays it is implemented.

Anyways - once I replaced the switch by a new one, the issues disappeared.

Hope this is helpful if anyone suffers similar issues

Malte

P.S.: I am currently considering replacing the microswitches for Z-axis by optical or magnetic endstops, like the ones used on RepRap 3D printers:

http://reprap.org/wiki/Endstop

I do assume this mod would improve vertical accuracy and eliminate any potential bouncing issues. For X and Y the mechanical switches are fine as optical / camera homing is already very accurate.

However, if bought or produced in bulk, opto endstops for all axis might be cheaper than precision micro switches - something Juha might want to consider

[Lars]

You could also debounce with a simple RC low pass.

[mrandt]

You could also debounce with a simple RC low pass.

Sure, or even use cross-coupled logic gates

But why build hardware if the problem could easily be solved by a digital filter in software / TinyG firmware?

My point in using optical / magnetic endstops would rather be to improve accuracy and durability for Z-axis compared to microswitch. I also think that the force required to trip the switch when pushing the needle down is still too high. But for now this is not really at the top of my list.

[JuKu]

We don't have control of the TinyG software.

[danmcb]

and usually solving issues at source is a good idea - it only needs a couple of gates ...