In this case it will be to provide an external pull-up to provide enough current to assure a reliable contact closure.

Already suggested in post #6 and rejected.

 

I don't see how the limited current, due to the series resistor, will create a "blast" crater sufficient to be a problem.
How is that different then a steady-state current of the same value?

I've seen regular relay and CMOS MEMS contact issues investigated with a SEM (scanning electron microscope). The total current is limited but the current density at the initial contact points is high at the microscopic level with a steep drop-off here back down to the pull-up current level. It will make small areas of clean metal with the contamination cleaned away likely being redeposited near that spot. I've no idea how long or short degradation will take but it likely will happen if he's already having reliability issues with the relay brand/type he's using. These are all band-aid fixes to the real problem IMO being the type of relay used.


Typical images.

 

These are all band-aid fixes to the real problem IMO being the type of relay used.

True, but the TS stated he can't change the relay, so it's a classic case of "Fix It, but don't Change It".

 

True, but the TS stated he can't change the relay, so it's a classic case of "Fix It, but don't Change It".

That is also true ... thank you both for your invaluable input

 

True, but the TS stated he can't change the relay, so it's a classic case of "Fix It, but don't Change It".

I know, you need to play the cards you have but if you're the dealer, don't stack the deck against the house.

There's a reason why good small signal/telecom relays are expensive. There are relays in the frontend of just about every quality scope because nothing beats a top of the line relay.

https://www.mouser.com/datasheet/2/227/TELDS00304_1-2577886.pdf

 

At this point I will ask: HOW LONG does it need to last?? 90 days or 90 months or 90 years?? How many operations? How often does the relay send that command? Some production equipment cycles every minute, 24/7 while bottling systems deliver a dozen bottles a second.
So one valid choice may be another I/O block for the PLC that has a logic output, no contacts. OR possibly just change the module to a DC level output. What are the other circuits controlled by that PLC module? And if a zero-power input arrangement is needed, then the transistor side of an opto-isolator can do that, and the power to drive the LED side, can steal a bit of current from another circuit being switched by that PLC module.
Additional information is needed here.

 

And that being the case, I'm considering using a zener and resistor regulator connected to the 14V source, and briefly activating said regulator using an nFet to check the status of the relay contacts. Having a few mA at 14V run through those contacts for a few microseconds once a second should be enough to break through any layer of oxidation on the contacts. And it would also draw very little power on average.

Wouldn’t it use no power if the relay was open? Perhaps you can maintain a state table and if the previous state is closed your check can omit the extra power since you’ve already seen the relay close. At that point you are just looking for an open relay.

This potential power saving comes at the cost of possible unreliability if the relay can actually stop reading as closed once it has started to conduct. I don’t think this is the case but the value of this solution will also depend in the duty cycle—do you expect open or closed contacts, or is it closer to a 50% thing?

You could even do the “non-enhanced” check and if you don’t know the previous state, fire the enhanced supply as a double check. Since sometimes you don’t need it, you don’t have to do it every time if you get a closed result. It would only be necessary if you got an open indication, and then it would only draw power if it was actually closed after all.

 

At this point I will ask: HOW LONG does it need to last?? 90 days or 90 months or 90 years?? How many operations? How often does the relay send that command? Some production equipment cycles every minute, 24/7 while bottling systems deliver a dozen bottles a second.
So one valid choice may be another I/O block for the PLC that has a logic output, no contacts. OR possibly just change the module to a DC level output. What are the other circuits controlled by that PLC module? And if a zero-power input arrangement is needed, then the transistor side of an opto-isolator can do that, and the power to drive the LED side, can steal a bit of current from another circuit being switched by that PLC module.
Additional information is needed here.

A good question. Contact (or non-contact) detection should last at least two years. Although typically the relay changes state two to four times every 24 hours. As for the rest of your inquiry, unfortunately all I can access is the PLC's relay output. There are no logic outputs that I can connect to, otherwise I would've done just that from the beginning.

This potential power saving comes at the cost of possible unreliability if the relay can actually stop reading as closed once it has started to conduct. I don’t think this is the case but the value of this solution will also depend in the duty cycle—do you expect open or closed contacts, or is it closer to a 50% thing?

Yes, the duty cycle is closer to a 50% thing, although it could become unpredictable depending on external factors. I appreciate your suggestion, but I think I'd rather stick with the "enhanced" check to optimize reliability, even though that might require a little more current.

 

If there is any DC switched anywhere in the system nearby the PLC, then oe option will be to have the contact CLOSEURE ACTIVATE THE led IN AN OPTIO-ISOLATOR, then the PHOTO-TRANSISTOR in the isolator can signal the MCU

 

I've decided to try the following circuit.

​

V1 represents the main battery bank, which can deliver up to 14V. I set up the sim so that said voltage increases with time, showing how the output at the zener is affected. Unfortunately, I couldn't find a 3.3V zener in the LTspice library, so I had to settle with a 4.7V zener for the simulation.

Anyway, the graph clearly shows that the circuit's output is stabilized after V1 reaches about 8V. I'm expecting that this will be about 6V when using a 3.3V zener. Either way, a maximum current of about 12.5 mA and a minimum of 5 mA runs through R1 (and hence through the relay contacts) when the battery supply is within the 8 to 14V range, which should be enough for the mechanical contacts to perform reliably, I think.

My concern now is that the simulation is not taking into account that V1 is actually being delivered through the relay contacts, and therefore V1 will be removed when the contacts are open and Vline will be left floating. My plan is to connect this circuit's "out" to an MCU's pin that will be configured as a digital input, with its internal pull up deactivated. Would that be a problem?

 

I've been working on a project that requires interfacing a PLC's relay output to a custom made circuit using a PIC10LF320 working at 3.3V

The way both devices are connected is extremely simple:

View attachment 316958​

The MCU_Pin connected to the relay's contacts is configured as an input with its internal "weak pull-up" feature enabled.

Some of the circuits have been behaving well. But some others have been a bit erratic. That is, a few of them have not been detecting the MCU_Pin being pulled to ground when the relay's contacts are closed, or have been detecting it intermittently. I attribute that behavior to the relay's contacts being of the "dry" type, as Max has pointed out in other posts of his. That is, I think that the contacts have been developing some sort of electrical oxidation on their surface, and said oxidation has been acting as an insulator. And this has been made worse due to the low voltage at which the circuit works. Thus explaining the MCU's failure to detect if the relay is closed.

Now, the MCU draws its power from a regulator, and the regulator draws it from a set of batteries connected in series that deliver a bit over 14V when fresh. It is very important that any change I make to the the circuit does not pull more than 5 µA in addition to what it's already being drawn from the batteries.

Any suggestions as to how best to overcome this PITA? ... use an external Zener or an nFet while cancelling the pin's internal pull-up perhaps?

@MaxHeadRoom, @crutschow

I think there is a simple fix.

1. The MCU pin should be configured as a "digital" input, not as an analog input.
2. The input pin requires debouncing. This can be done in the MCU software. The debounce routine should wait longer than the bounce duration before a final read of the input pin.
3. Don't use the weak pull-up feature (its actually a mosfet switch, so the value is vague). Turn off the weak pull-up feature and use an external resistor with a small(est) value that doesn't violate the 5uA current requirement. Also, add a 0.01u cap from the pin to ground (or you can reverse the input logic and swap the connections). The external pull-up will also ensure the input stays pulled-up during sleep mode or a reset.

You haven't written how log the relay contact is open or closed. It will bounce like a switch for roughly 10ms-20ms.

There also could be a GPIO pin configuration issue in the software.

 

I think there is a simple fix.

1. The MCU pin should be configured as a "digital" input, not as an analog input.
2. The input pin requires debouncing. This can be done in the MCU software. The debounce routine should wait longer than the bounce duration before a final read of the input pin.
3. Don't use the weak pull-up feature (its actually a mosfet switch, so the value is vague). Turn off the weak pull-up feature and use an external resistor with a small(est) value that doesn't violate the 5uA current requirement. Also, add a 0.01u cap from the pin to ground (or you can reverse the input logic and swap the connections). The external pull-up will also ensure the input stays pulled-up during sleep mode or a reset.

You haven't written how log the relay contact is open or closed. It will bounce like a switch for roughly 10ms-20ms.

There also could be a GPIO pin configuration issue in the software.

The root problem here is the actual relay. The contacts oxidize from being open and the wetting current is too small when they close to keep the contacts clean. The thread is a classic story of band-aids fixes of a root problem, a relay designed for this sort of long-term dry contact operation. The only simple fix is a proper relay.

I've had good relays switching weak pull up controller inputs for decades.
https://omronfs.omron.com/en_US/ecb/products/pdf/en-g6b.pdf


https://forum.allaboutcircuits.com/...ic-controlled-battery-array.32879/post-204585

 

The root problem here is the actual relay. The contacts oxidize from being open and the wetting current is too small when they close to keep the contacts clean. The thread is a classic story of band-aids fixes of a root problem, a relay designed for this sort of long-term dry contact operation. The only simple fix is a proper relay.

I've had good relays switching weak pull up controller inputs for decades.
https://omronfs.omron.com/en_US/ecb/products/pdf/en-g6b.pdf
https://forum.allaboutcircuits.com/...ic-controlled-battery-array.32879/post-204585

You might be right, but at least the TS can try the mods I've suggested before using a more costly approach.
The TS hasn't written if the operational failure is permanent or intermittent. I'd like to know that also.

 

You might be right, but at least the TS can try the mods I've suggested before using a more costly approach.
The TS hasn't written if the operational failure is permanent or intermittent. I'd like to know that also.

Thanks for chiming in, ee. All help is thoroughly appreciated. The failure seems to be intermittent, but once it starts to show, it becomes permanent. That is, I've built hundreds of circuits just like the one I've described, and several dozen have shown the symptoms I mentioned and have been causing considerable trouble.

It seems that the only way out of this conundrum is using a higher voltage with a current of at least 10 mA, so that the relay contacts can stay "clean". Debouncing has never been a problem since I can have the luxury of checking the relay's status once every two seconds (even once every five seconds, actually). I can't blame you if you haven't thoroughly read all posts in this thread.

Anyway, What do you guys think of my plan? The one I described in post #30?

 

Still think my idea to add a capacitor to provide an momentary (relatively) high current when the contacts close will clean the contacts of any oxide.

 

Still think my idea to add a capacitor to provide an momentary (relatively) high current when the contacts close will clean the contacts of any oxide.

And I also think your idea an excellent one. God knows, your opinion is one that I've always respected and kept in high regard. And I've always been thrilled every time you've come forward.

My worry is this is a battery operated circuit that is supposed to last at least 4 to 5 years before the batteries need changing. Do you think a cheap-o brand relay with ordinary dry contacts will behave acceptably well using your proposal?

EDIT: Also, would you say my circuit is overkill?

 

My worry is this is a battery operated circuit that is supposed to last at least 4 to 5 years before the batteries need changing.

Are you referring to the affect of my suggested addition?
That draws only a very small transient current and no steady-state current.

Also, would you say my circuit is overkill?

I think there is a fair chance it is.

 

Are you referring to the affect of my suggested addition?
That draws only a very small transient current and no steady-state current.
I think there is a fair chance it is.

Sometimes things worth doing are indeed worth OVER-doing. This seems like one of those times. Just be sure to use a very low-leakage capacitor..

 

So, I've implemented the aforementioned circuit in my project, and it's behaving quite well so far. I'm going to have to wait a few months, though, to make sure that its behavior is as reliable as I need it to be.

One question, though. Here's the code I'm using to sample the state of the relay. It runs at 31 kHz:

;*****************************************************************************************
; Read the state of the relay's contacts 
;                        1.- Activate the sampling current
;                        2.- Read the RELAY_PIN state
;                        3.- Deactivate the sampling current
; The resulting reading is reported in w
;*****************************************************************************************
Read_Relay_State_W:
    bsf LATA, SAMPLE_ENABLE_PIN ;enable the sampling circuit
     nop                        ;wait for the circuit to stabilize
     movf PORTA, w              ;read the state of the RELAY_PIN
    bcf LATA, SAMPLE_ENABLE_PIN ;disable the sampling circuit
    andlw nRELAY_FILTER         ;filter the concerning bit
    movwf ACT_RELAY_STATE       ;the resulting reading is stored in ACT_RELAY_STATE and 
  return                        ;reported in w

Would you say that the nop operation before reading the state of the pin is unnecessary? ... I put it there because I feel that a period of 0.129 ms might be too short a time for the current going through the relay contact to stabilize. It's a signal debounce of sorts, if I may call it that.

Or maybe I'm just being paranoid?

 

actually debounce time should be on the other of 10ms, not 0.1ms