Build 435.10 - Homing does not work on NO switches

[aldenhart]

As the title says. From TinyG forum: https://www.synthetos.com/topics/testing-edge-builds-435-xx/

[aldenhart]

The problem is a result of a change to the homing cycle.

Short answer - A temporary fix is located here: https://www.dropbox.com/s/snsztu9h8x5iy3z/tinyg_445.01_dev.hex When the final fix is rolled into edge this link will be deleted.

Long answer - A test was added to the homing routine that would abort the homing cycle if a user manually entered a feedhold in the middle of the homing cycle. Unfortunately, this is the same condition as a normally open switch that opens before the deceleration from search occurs. This check was removed until we have a more permanent solution that distinguishes between the above race condition and a user-initiated feedhold.

Question for JuKu - what kind of switches are you running and is there any reason the NO switch would open before the search has come to a stop? Are you running opto switches?

[jkuusama]

There is more headroom from 3v to logic low than 0v to logic high, especially at the end of a long cable that shares routing with motor and spindle cables. Therefore, I have double throw switches that go from 3v to 0v, Omron micro switches. The switching feels solid, but I haven't looked at the waveforms with a scope. Maybe there is some debounce or noise in the lines? What I saw was that the switch was ignored, the machine crashed at the ends, each time. Fortunately, my mechanics are far stronger than my motors. :)

By your opinion, is there an advantage in switching from 396.12 (which seems to work ok) to this dev? I'm planning to go to customers in about a month.

[cmcgrath5035]

jkuusama I understand your headroom logic, but wouldn't you expect improved noise coupling (lower induced noise) with a grounded (low impedance) NC switch? Of course that ground should be from a separate lead, not to the shield(I think). Do you extend 0V and 3V out to each DPDT microswitch? Are they well bypassed (ceramic cap) at the switch end? Otherwise, seems those wires would be great noise antennas as well. And I guess I forgot the most important question - is this a theoretical discussion, targeting best design, or have you had significant noise issues with your machine?

[jkuusama]

Short answers:

but wouldn't you expect improved noise coupling (lower induced noise) with a grounded (low impedance) NC switch? Not enough (but see below). Do you extend 0V and 3V out to each DPDT microswitch? Yes. Are they well bypassed (ceramic cap) at the switch end? No (doh). That is a good idea. is this a theoretical discussion, targeting best design, I was merely reporting an issue with homing and NO switches, but this seems to go into that direction... have you had significant noise issues with your machine? Yes, but not after I went to NO switches.

Long answer: I mounted one pole. double throw switches. I first mounted them with unshielded cable as: TinyG - cable - switch input -- wire 1 -- lever GND -- wire 2 -- NC

This didn't work at all, even with added filtering. A scope showed much noise. Second attempt was with a shielded cable: input -- wire 1 -- lever GND -- shield -- NC

This improved things a lot, but there were still occasional false alarms. Third attempt is working reliably: input -- wire1 -- lever 3v -- wire2 -- NC GND -- shield -- NO

No doubt a cap would help and even might have done the trick on my second attempt. I have no idea why I don't have a capacitor at the switch, this seems so obvious.

If I understand you right, you are proposing this, with a capacitor at the switch: input -- wire1 -- lever gnd -- wire2 -- NC gnd -- shield -- no connection

This feels better than what I have, and I believe would work well. On the other hand, what I have now works well aslo, so I'm not too keen on "fixing" it.

[cmcgrath5035]

Interesting info, may be helpful to others;thanks. To me it's clear that running shielded cable is important; this is a noisy environment. Important to connect the shield to gnd at only one point, which probably means at tinyG where all the shielded cables come together and there is a GND to be had. Noise mitigation is 40% art, 60% science.. I'll also guess that tinyG would benefit from some low pass filtering at the Switch inputs; have not had time to play with that. You might experiment with a ferrite core around the cable as well. And, probably a good idea to put a resistor (1K, 10K, ?) in series with 3V so a inadvertent short while working on the machine won't kill the tinyG. Good info; thanks

[aldenhart]

The v8 boards do have filtering. There is a low-pass filter with a 2.7K resistor and a 470 nF capacitor on each input.

[cmcgrath5035]

Ah so, I am still in V7 mindset. I have been contemplating some sort of noise robustness test that could be implemented with out lab equipment(oscilloscope, noise meter, spectrum analyser, etc). Is it possible to configure tinyG to send a status message or report when it detects something on an input pin that could be actionable? One could then filter the return status stream for asynchronous random messages, using various wiring techniques, as an indicator of implementation robustness.

[aldenhart]

I am actually developing that. There's a new group called "switch state" ($ss, {ss:n}) that returns the state of the switches. It's comprised of members $ss0 (Xmin), $ss1 (Xmax), $ss2 (Ymin)... etc. It will return 1 if the switch is "thrown", 0 if not thrown. Thrown is closed for a NO switch, and open for an NC switch. Not thrown is of course the opposite.

I still have a bunch of testing to do, but this should be out there in a couple of weeks.

[aldenhart]

The switch reader group (ss) already takes switch conditioning into account. It does not read the raw switch. It reads the conditioned input which has the debouncing in place.

[cmcgrath5035]

In another issue thread here I see reference to a $test=3 command that apparently also reports switch state. Are the $test=nn tests documented anywhere?

[aldenhart]

The self tests are documented in the command line help. Type $test. I've also added them to the wiki: https://github.com/synthetos/TinyG/wiki/Test-Drive-TinyG

There is currently no test that tests switches. The homing test might be able to be used for this, but it's a stretch.