joint 0 limit error
![:ohmy: :ohmy:](/media/kunena/emoticons/shocked.png)
Please Log in or Create an account to join the conversation.
![:) :)](/media/kunena/emoticons/smile.png)
John
Please Log in or Create an account to join the conversation.
Re-connecting for N/C didn't help. I think I will give sheilding a go next, but I don't have anything at home to try that with so it will have to wait. Thanks all for your help.
Please Log in or Create an account to join the conversation.
There are probably 5 reasons why NC is better. There is the noise immunity issue, thenAccording to halscope, you are correct Jon. there are random spikes which sometimes lineup I guess to trip it on limit error. Currently yes the switches are snap action micro's, when hit pulls the line to ground. I do have pull-ups on the line, can't remember the value right now, but prolly 1K on a 5V system. I should note, this is NOT connected directly to the paraport. It goes though a uP which just multiplexes the switch's so I have enough I/O. I suppose this could be my uP screwing up, but I really doubt that since removing the switches removes the problem.
Would I be better to connect them to the NC side and have them always closed?
what happens if a wire breaks, or oil gets into the switch and makes the contacts have
poor contact. NC is somewhat more "fail-safe".
You could add some capacitors that slow down transients on the sense wires.
Jon
Please Log in or Create an account to join the conversation.
If you have noise on your limits circuit(s) there are a couple of things you can do besides checking grounding, shielding etc.
One is to put a debounce component into the limit signal chain. This will have the effect of filtering out very momentary spikes and dips, because the level has to be low for x cycles before a condition is triggered.
I have used this before with a 3 phase motor driven mill which put noise into the power supply despite filters etc.
Another lateral solution, is one I used with a small mill with a particulary 'dirty' DC motor controller, unshielded, just plonked in a ABS housing. It continually triggered limit errors despite cable shielding etc.
Take a small 12v relay and a plugin 12v power supply.
Wire the limits in series to the relay coil, all powered by the 12v supply
Connect the NO relay contacts to your BOB as the signal.
The limits carrying 12v just to power a load coil, are pretty much immune to any noise and the signal pin gets a clean on/off from the relay contacts if a switch goes open circuit.
Unless there is some compelling reason to have separate limit switch inputs, I would chain them together, it saves inputs.
It is immediately apparent which axis triggered just by looking at the machine.
If you set up your soft limits properly and don't get your co-ordinates systems screwed up, you should never get to a limit switch situation anyway (in theory
![:laugh: :laugh:](/media/kunena/emoticons/laughing.png)
regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
debouncing would be perfect. I can debounce it through my I/O card. I was not aware EMC had a debounce component. I may just use it instead.
Here are the docs...
linuxcnc.org/docs/html/hal_rtcomps.html#sec:Debounce
But that page assumes you are loading from the command line rather than a HAL file. (hence the halcmd commands)
Your HAL file needs to contain code a bit like this. Note that I am not at an EMC2 machine at the moment, and all the pin and signal names are from memory and probably wrong.
loadrt debounce cfg=3
...
addf debounce.0 base-thread
...
setp debounce.0.delay 5
net X-unfilt parport.0.pin-02-in => debounce.0.0.in
net X-lim debounce.0.0.out => axis.0.home-sw-in axis.0.pos-lim-in axis.0.neg-lim-in
net X-lim debounce.0.1.out => axis.1.home-sw-in axis.1.pos-lim-in axis.1.neg-lim-in
net X-lim debounce.0.2.out => axis.2.home-sw-in axis.2.pos-lim-in axis.2.neg-lim-in
Please Log in or Create an account to join the conversation.
. This will have the effect of filtering out very momentary spikes and dips, because the level has to be low for x cycles before a condition is triggered.
Note the use of very momentary
Obviously if the debounce were set too high, the axis could overrun and cause damage before a condition registered.
(You could calculate your cycles per second, your max velocity movement per second and see how far the axis could travel in the
time required for activation if concerned)
Extracts from my mill .hal file
## problems with limit switch activation errors due to 3 phase noise
## try a debounce component to iron out momentary spikes
loadrt debounce cfg=2
addf debounce.0 base-thread
setp debounce.0.delay 30
net all-limit-raw <= parport.0.pin-13-in => debounce.0.0.in
net all-limit <= debounce.0.0.out
net all-limit => axis.0.neg-lim-sw-in
net all-limit => axis.0.pos-lim-sw-in
# above repeated for each axis
regards
PS I see I have just duplicated Andys input - should learn to type faster!
Please Log in or Create an account to join the conversation.
You seem to have taken the time to get the pin names right thoughI see I have just duplicated Andys input - should learn to type faster!
![:-) :-)](/media/kunena/emoticons/smile.png)
The "delay" parameter is the number of base thread periods. That is typically a few tens of microseconds. With your value of 30 the axis could over-shoot the switches by almost 0.02mm at my max axis speed.
Which is a roundabout way of saying that it can actually be quite high and not cause problems. If you go _too_ high there is then a danger of the debounce retriggering, and never seeing enough identical states to switch state.
I think I have a two-channel debounce, with limits on a long filter and homing on a shorter one, but I think that is probably pointless in practice.
Please Log in or Create an account to join the conversation.