One of my NCD PR16-9-5 “2-Channel General Purpose SPDT Relay Shields” with an embedded Particle Electron microprocessor is misbehaving.
Firmware on the Electron responds to continuity across the first set of input terminals on the relay board (continuity occurs when a float switch in a water tank closes a circuit). The application has been running reliably for a couple of years, turning on a pump to fill the tank when the float switch’s contacts close at a pre-set low water level and turning the pump off when those contacts open, i.e. when the tank is full.
Recently the Electron’s firmware stopped notifying the pump that it needs to stop, i.e. when continuity has been lost because the float switch’s contacts opened. Consequently, the pump keeps running and the tank overflows.
I have verified with a meter that, indeed, there is no continuity across the input terminals when the water reaches its prescribe level (the float switch is working). The firmware on the Electron has not been touched in years and it does reliably turn the pump on when the contacts close. Clearly, something has failed and I suspect it’s the NCD board.
Can anyone suggest a course of action to better diagnose or resolve this issue? Replace the board? Move the wires from the float to a different pair of input terminals (and modify the code appropriately, of course)? Maybe look harder at the Electron rather than the relay board?
Hi,
So are you saying that the float switch is connected to a digital input on the board and the digital input can read when the input closes but cannot read when the input opens? That is very strange, I’ve never heard of anything like that. I would definitely try a different input on the board if you have additional inputs to see if that works. Try using just a jumper wire to close and open the inputs rather than the float switch just for sanities sake.
Hi Travis. Thanks for your reply. Before I saw it, I decided to do exactly what you suggested. But I first connected the Electron to its backup battery while leaving the NCD board unplugged. That allowed the code to run on the Electron while the relay board was without power. The firmware checks the status of input #1 upon startup and every 5 minutes thereafter. It immediately sent a ‘0’ to the Electron at the well (‘0’ being the ‘off’ command) since it got no response from the relay board.
Next, I powered up the relay board and at the next 5-minute check, the Electron sent a ‘1’ even though the tank is full. That confirmed that the relay board was indicating that the float switch circuit was closed even though it wasn’t (I again checked with a meter).
The last step was to move the two float switch leads from input #1 to input #2 and update the code accordingly, i.e. to check #2 instead of #1 (“int status = controller.readInputStatus(2);”). After restart, the Electron sent a ‘0’ as expected.
ISo that seems to prove that there is something defective with input #1 only. Might that be covered by warranty?
Follow-up: I was planning on watching until the tank level drops again to make certain that everything is back to normal, but your suggestion is one that should have occurred to me (duh!): bridge the two terminals with a piece of wire to simulate float switch contact closure. I will do that and follow-up here.
Hi,
It sounds like that input on the MCP23008 chip on the board is damaged. Many times this can be caused by a static discharge on the wiring connecting the float switch to the input on the board. This is common if the wire run between the float switch and input is long and not a properly shielded twisted pair wire like Cat5 or Cat6. I have also seen this happen many times after bad weather(lightning strikes, high winds, etc).
We can attempt to repair the board for you by replacing the surface mounted MCP23008 on the board. You can fill out an RMA form here and follow instructions to return the board for repair:
https://ncd.io/contact-us/product-returns/
Let me know what else you find.
I haven’t had time today to go back to the tank site and manually close the circuit, but will do so in the AM if the float switch doesn’t beat me to it.
BTW, the wires from the float are 12 gauge Romex. Go figure…
If input #1 is, indeed, faulty, I don’t think it’s worth worrying about. There are four other sets of inputs and this is the only application that particular relay board is used for, so there’s plenty of ‘life’ still in it (if input #2 is working properly as evidence suggests). However, I do have a problem with the second board - the one at the pump - that necessitated that I replace it with our maintenance spare. I’ll chat with you about that in a future message
I’d send that bad board from the pump in for warranty repair. Having a maintenance spare means you can stay up and running while a board is in repair so kudos to you on that one.
Will do Travis. FWIW, the problem was that periodically - but not always - the red R1 LED would come on, as expected, when a command was received to turn on the pump, but, in fact, the relay did not close and the pump would not come on. I’d discover this when my code would send me an email - via Particle and IFTTT - that three hours had elapsed since receipt of an “On” request but no “Off” command had not yet been received.
Bit of a quandary now, Travis. The leads from the float switch had originally been connected to the terminals labeled ‘IO1" and “GND” in the attached image.
. When the thing stopped responding to an open circuit, I simply moved the wires up two places, assuming that each set of two terminals was a "pair’. Well, I just discovered that they are not (I didn’t look at a diagram and couldn’t read the labels on the board)!
As you suggested, I bridged those two terminals but my firmware still sent '0’s when I expected it to send '1’s. Only then did I decide to look at the terminals a bit more closely and realized that I was using the wrong two of them (‘IO2’ and ‘IO3’).
So my next questions for you are:
- Why are there two GND terminals?
- Since all I am doing is responding to contact closure, can I assume there is no polarity requirement, i.e. I can connect either of my two wires to one of the GND terminals and the other to any numbered terminal?
- If the two GND terminals are not in common, should I use the one closest to terminal ‘IO7’ in case the other is the culprit responsible for my earlier problem?
Put another way: which two terminals do you recommend that I use?
Thanks yet again Travis. I bet that this will be working before the day is out (once it stops raining here).
Yay. It seems to be working. I moved the wires and at my firmware’s next 5-minute check, the Electron sent a request for the pump to come on (the tank was well below the high-water mark at the time). I then pulled one of the wires and at the next 5-minute check, the pump turned off. Reconnected the wire and five minutes later the pump was back on. So I think the issue has been successfully addressed! Time for a beer.
Have one for me, I gotta sit in this office chair all day 
One more weird thing, Travis. Now that ‘automatic’ operation of the pump as a function of the position of the float switch in the tank has been restored, I noticed in the tank’s Electron’s event log that every once in a while, at one of my code’s regular 5-minute check intervals, it’ll send a ‘1’ to the far end, causing the pump to come on even though the float switch circuit is open (tank almost full).
I’ve attached a screen shot of a portion of the log. Can you look at the code that is running on that Electron (https://go.particle.io/shared_apps/5faab8f4e6f0b000092b8521) and see if you can explain why that code would ever reset the value of the ‘start;’ variable from ‘0’ to ‘1’ for any random reason? If the returned value of the ‘status = controller.readInputStatus(2)’ statement is a ‘1’ even though the float circuit is open, are we seeing yet another fault with this relay board?
If you disconnect the float switch from the board and either leave the input open or close it using a short jumper wire do you still see random open/close events that are invalid? I highly recommend testing that to see what you find.
I haven’t yet, but will. Just disconnecting one wire should be a sufficient test I think. If the code still decides to transmit a ‘1’, then it obviously isn’t a relay board issue. If it never does so again, then it probably is a relay board issue. Stay tuned (again)…
I’d recommend disconnecting both wires from the board that connect the float switch. I’m thinking that wire might be picking up some noise that is causing false triggers on the board.
Disconnected both wires about 10 hours ago Travis. Not a single ‘1’ transmitted since. Tomorrow I’m going to move one wire further away from the ground terminal in case proximity between the two is somehow the issue. If I again see the previous random transmissions of a ‘1’ when the tank is full (it has been overflowing due to this error), then I will need to get yet another board while NCD fixes this one.
If the problem went away when you disconnected the float switch from the board then my suspicion is that you are getting noise picked up on that wire run. Replacing that with a shielded Cat5 cable will fix the issue.
Except that we’ve never seen the issue before in 2 or 3 years, not until input #1 went south. Nothing else has changed. I have another relay board that has a defective relay that may be OK on the input side. If rearranging the wires - moving them apart - doesn’t make the problem go away, I may substitute that relay for the current one at the tank to see what happens.
Another follow-up: after moving one of the wires to input #3 from input #2 to provide further separation between it and the other wire that remains connected to a ground terminal, I still saw occasional "1’s being transmitted, but at a lower frequency than before (specifically, 7 times amongst the 108 total transmissions in 11 hours).
While no where near as much of a problem as when I was using input terminal #2 (which caused the tank to overflow), it is still unacceptable. I am convinced that the board is damaged or defective. So, as mentioned before, I will swap out the board for the one with the defective relay and will let you know if the problem goes completely away.
On a side note, I just noticed that the labels on the input terminal block on my board do not match those shown on the NCD website (shown above). Originally, the float switch wires were connected to the first two terminals and my code monitored input #1 (which, as you can see from the attached photo, is labeled “GP2”). I next moved one wire to input #2 (while leaving the other on the “GND” terminal) and modified the code to monitor input #2, but that is labeled “GP3”). Currently, the wire is connected to terminal #3 and the code monitors that, but the terminal is labeled "GP4’. Can you confirm that, indeed, the board is mis-labeled and the on-line diagram is correct?
