Switch re-triggering issue

[eTech]

I noticed this on the other thread.

"I had considered asking the guys to change the settings in the software to increase the required switch pulse to the maximum of 250mSec ... which may eliminate any spurious pulses ... but they're unlikely to be anywhere near 100mSec let alone 250. Still worth a try on the worst offending units though in case it does improve things."

The switch has a specific fixed "pulse" duration that is set in the switch itself. The micro should detect a button press then wait a shorter duration to prevent missing the pulse. Also, your diagram shows external pull up and pull down resistors, check that "weak pullups" or "pull downs" are not enabled in software on the microcontroller.

Just tossing in some things to check..

eT

 

[Western]

Which one is the "start" button on your diagram?

The "start" button is the one shown ... with the remote switch lines in parallel with the switch.

This is just academic ... but the remote switch is a reed switch ... normally open.

I didn't draw the identical "Manual" switch and circuit, to keep the diagram simple.

So you were able to isolate one switch from the other to determine which "input" is causing the fault?

Yes. First thing I got them to do was to remove the connection to the remote switch.

They just removed them from the first 5 units ... but very quickly saw the fault continue despite having the remote switch lead disconnected from the chocolate block alongside the board.

I also had them disconnect the piezo "start" switch as well ... but they reconnected the remote switch at the same time so they could still use the units ... and the fault continued.


They finally did as I asked ... and removed the switch connections to the board, completely ... directly at the board ...

... so they'd start the process ... then unplug the switches (from the board connection) ... and the fault WOULD NOT OCCUR.

Then they'd have to plug in again to start the next milking ... and remove the switch leads again.

If so, and the switches are not bad, then it has to be the wiring or something in close proximity to the wires inducing a glitch.

That's been my angle pretty much the whole time ... but trying to determine exactly what has been the issue.

When the piezo switches are connected ... there are only 6 inches of leads to pick up any noise/spikes etc ... because with the 3 feet of remote line disconnected ... there is no way for a spike to get onto the board.

... and as above ... I've proved that the boards are not the issue.

The techs are familiar with all the usual interference issues they regularly see ... particularly with RFID tags and readers ... those are very susceptible to noise ... so they have a fair idea what to look for regarding contactor switching, noisy ballasts, power surges etc etc.

The input circuit on your diagram looks a little strange...seems like it should only have transient protection since there is no switch bounce to deal with.

Yes, agreed ... and on top of that ... the software allows you to change the switch reading response time form 0 - 250mSec ... to prevent switch bounce issues.

These are set to 100mSec ... which is what 90% of them are set to ... from my experience with over 500 boards. Again, this is just academic ... as it's not the piezo switches.

 

[Western]

Just had a crossed thread.

"I had considered asking the guys to change the settings in the software to increase the required switch pulse to the maximum of 250mSec ... which may eliminate any spurious pulses ... but they're unlikely to be anywhere near 100mSec let alone 250. Still worth a try on the worst offending units though in case it does improve things."

It's been that slow so far getting action at the other end, that I haven't asked for that yet.

Now that they've seen a change from disconnecting the leads from the board, I'm getting the feeling that they're a bit more interested now ... but still a slow process.

Also, your diagram shows external pull up and pull down resistors, check that "weak pullups" or "pull downs" are not enabled in software on the microcontroller.

That's an interesting thought. There are only a handful of different variations of firmware for the boards ... maybe they all came from a batch that had been programmed wrong.

I could easily ask them to refresh the first 5 boards or so with a different version ... and also change the switch response time at the same time.

I guess highly unlikely ... but I don't care what fixes it as long as it gets fixed.

Just tossing in some things to check..

Thank you to all you guys ... that was exactly why I asked the question in the first place ... it's hard working in isolation and just too easy to miss a whole line of thought that could solve it right away.

 

[eTech]

Yes, agreed ... and on top of that ... the software allows you to change the switch reading response time form 0 - 250mSec ... to prevent switch bounce issues.

These are set to 100mSec ... which is what 90% of them are set to ... from my experience with over 500 boards. Again, this is just academic ... as it's not the piezo switches.

Not saying its the switches.

So do you know the pulse duration of the switch output? Its specified by the manufacturer. They vary, but some are 100ms, others 250ms, and they have a tolerance. I'm familiar with de-bounce routines used in micro-controllers, and if its set to 100ms and its close to the switch pulse duration...well...then could be random problems.

However, I wasn't aware of the reed contact. That does need to be de-bounced and can be in software.

eT

 

[alec_t]

saw the fault continue despite having the remote switch lead disconnected from the chocolate block alongside the board.

They finally did as I asked ... and removed the switch connections to the board, completely ... directly at the board ...... so they'd start the process ... then unplug the switches (from the board connection) ... and the fault WOULD NOT OCCUR.

Then logically the fault lies in the area of the chocolate block and the board input. Have the block/input terminals been checked for corrosion? Is there any contamination in that area? Any creepy-crawlies shorting the input terminals?

 

[AnalogKid]

The 200K resistor is not a good design in that it unnecessarily raises the impedance seen by the inverter, increasing its sensitivity to noise. I was heading toward a bad solder joint, except for post #16. That one eliminates 90% of the possible suspects.

Whatever the interfering event is, it has a duration. Increasing the switch debounce time may have no effect on non-bouncing switches, but it could act as a discriminator to suppress short interference events (ground bounce, RFI, whatever).

ak

 

[Western]

So do you know the pulse duration of the switch output? Its specified by the manufacturer. They vary, but some are 100ms, others 250ms, and they have a tolerance. I'm familiar with de-bounce routines used in micro-controllers, and if its set to 100ms and its close to the switch pulse duration...well...then could be random problems.

Ok, I checked the piezo switches more closely ... and they switch pretty cleanly ... but depending on the quickness of the jab ... the pulses can be as short as 2.5mSec ... right up to 740mSec for a good hard press and hold.

In fact ... if I just jab some of them ... I can get the start of a dip towards zero ... but only get down to about 2 volts before returning to 4.2 volts.

Sorry if that messes up what we thought they should be doing.

Then logically the fault lies in the area of the chocolate block and the board input.

Yes, that is the logical conclusion for me too. I keep thinking it is some sort of noise or interference that is getting into that area ... hence my idea of twisting the wires between the switches and the board to reduce the chance of interference getting in. I know, desperate!

Have the block/input terminals been checked for corrosion? Is there any contamination in that area? Any creepy-crawlies shorting the input terminals?

The 3 units I have on the bench were supposed to be 3 of the worst offending ones ... and have not missed a beat in weeks.

They are nice and clean inside ... no corrosion or contamination ... and are well sealed boxes with rubber gaskets and glands for the cables.

The outsides are clean enough ... but evidence of calcium scale starting to build up.

I was heading toward a bad solder joint, except for post #16. That one eliminates 90% of the possible suspects

Yes ... no getting away from the evidence.

Whatever the interfering event is, it has a duration. Increasing the switch debounce time may have no effect on non-bouncing switches, but it could act as a discriminator to suppress short interference events (ground bounce, RFI, whatever).

Yes, that makes sense. It will be high on my list of steps to take (to increase the switch time to maximum 250mSec) ... just to see if it makes any difference. It will probably annoy the operators because they will have to conciously press and hold the switch for much longer than they are used to ... but if it helps solve the problem it will be worthwhile.

 

[eTech]

You might consider asking if separate gpio pins could be programmed for the different switch types. One for mechanical switches (provides debounce) and one for solid state piezo switches (no debounce). That way the timings and delays can be set independently from each other...

 

[eTech]

Ok, I checked the piezo switches more closely ... and they switch pretty cleanly ... but depending on the quickness of the jab ... the pulses can be as short as 2.5mSec ... right up to 740mSec for a good hard press and hold.

In fact ... if I just jab some of them ... I can get the start of a dip towards zero ... but only get down to about 2 volts before returning to 4.2 volts.
.

Actually that’s excellent information, but the piezo device sure makes a terrible switch.
Seems to provide more of an analog output than a digital output.

Which kinda leads back to my suggestion to use separate gpio pins.

eT