sticking contacts on a safety relay

[Tbrzezicki]

I have a robot surrounded with a cage, the doors in the cage have magnetic safety sensors and pallet openings have light curtains. My question is I have a company rep from the palletizer wrapping company (which included the robot) and a questionable co-worker that keeps stating the safety relay in the enclosure is stuck (he claims stuck on). My position is in the PLC (Allen Bradley RS Logix 500) something is made, telling the safety circuit to activate. Theres a 11 flash code (Allen-Bradley Guardmaster) on the safety relay. Robot guys are saying based on what this co-worker is telling them that the safety relays sometimes "stick" (whatever that means). and needs replacing. I have never heard of a safety relay "sticking". Anybody ever hear of something like this? These co-workers, (not electricians) keep powering the panel down and powering it back up to clear the safety relay fault. My contention is that if something were stuck, burned, defective, whatever, it would repeat constantly. This happened once in a while, like once every day or every other day out of a 12 hour operation.

Your thoughts?

 

[GoldDigger]

If the safety relay clears on a power cycle it is not "stuck".
However it may be latching into the ON position because of a short transient pulse and not releasing thereafter until power cycled. Possibly a race condition in the programming of the PLC?
I am not familiar with the general design of a safety relay.

 

[Tbrzezicki]

If the safety relay clears on a power cycle it is not "stuck".
\

This is the point I was making to them, can't be stuck, no such thing as "stuck"

 

[GoldDigger]

This is the point I was making to them, can't be stuck, no such thing as "stuck"

I would be a lot more willing to believe a faulty sensor or bad programming of the PLC rather than a relay problem.

 

[Jraef]

The situation they are describing is exactly what a "safety relay" is designed to NOT allow to take place. Safety relays have what are called "force guided contacts" and monitoring contacts of the contacts. If it is really "stuck" that would make it serious fault and that fault would be, per safety rules, non-resettable because the relay would deem itself defective and be required to fail safe. Cycling power would NOT be able to reset it.

The relay is doing exactly what it is being told to do. Something is taking place out of the proper sequence and it is staying off because it is SUPPOSED to do that. Now the tricky part is slogging through the logic and sequence of operations, then comparing that to what the operators are doing (and whether or not that's what they were trained to do) to find the problem.

 

[__dan]

I had found one. Robot with a caged area would trip the safety circuit and not reset. It would take a lot of opening and closing of the cage doors, tapping on the relays to jostle bad contacts, guys had tried jumping things out. I believe the error would come up on the robot pendant as an E Stop but it was in the door circuit.They had the problem before and changed the safety board inside the Fanuc robot.

Eventually I found an Omron safety relay, socket mounted on the safety board, inside the Fanuc robot control box, had burned contacts. Changed that off their spare board and it worked perfectly. I had suspected there was an improper implementation, switching transients were not suppressed or too much, burning the contacts. They would close but must have looked open in the circuit.

 

[jimo144]

sticking contacts on a safety relay

Some very good answers that are right on the money. When you are Interfacing PLC and Robotic Movement Controls, things like this happen when Limit Switches begin to wear. As an example of what this could be; When the Robotic Cycle is completed, it Homes that closes a PLC Input to let the PLC know the Robot is out of the way and OK to start the Production Cycle.

When the Limit Switch begins to wear after repeating the Cycle thousands of times; it needs to be adjusted but hasn’t been. The Robot is doing exactly what it is supposed to do so there are no Faults / Errors from the Robot. The PLC is operating the Production Cycle so there are no Faults / Errors there. But the Production Cycle is waiting for the Robot to get out of the way. Killing the power and restarting brings everything back to Home Position and the Production Cycle can start again.

To Troubleshoot and repair this, insist that the Operator of the Machine not Kill and Restart the next time this happens and notify the Troubleshooter. The Troubleshooter should make note of where the Machine is or what Operation Step the Machine is in and make note of the AB PLC Input and Output Indicators. Monitor the active Ladder Logic Program and see Which Line is holding everything up. If you go to the Switch or other Source that the PLC is waiting on and actually find the reason, you know what to do.

Assuming that the Machine has been functioning correctly in the past and there have been no Programming changes done lately to the Ladder Logic, the Ladder Logic can probably be ruled out. If there have been recent changes to the Ladder Logic, it is possible that a Logic error is at fault. The last possible error could be a Sequence of Events by the Operator could be at fault. An example would be a shortcut by stopping the Production Cycle to do something and restarting without Homing.

I agree with the others, the Safety Switch is not ‘Stuck’ it is still being held by the PLC and waiting for something to happen.

JimO

 

[GoldDigger]

Some very good answers that are right on the money. When you are Interfacing PLC and Robotic Movement Controls, things like this happen when Limit Switches begin to wear. As an example of what this could be; When the Robotic Cycle is completed, it Homes that closes a PLC Input to let the PLC know the Robot is out of the way and OK to start the Production Cycle.

When the Limit Switch begins to wear after repeating the Cycle thousands of times; it needs to be adjusted but hasn’t been. The Robot is doing exactly what it is supposed to do so there are no Faults / Errors from the Robot. The PLC is operating the Production Cycle so there are no Faults / Errors there. But the Production Cycle is waiting for the Robot to get out of the way. Killing the power and restarting brings everything back to Home Position and the Production Cycle can start again.

To Troubleshoot and repair this, insist that the Operator of the Machine not Kill and Restart the next time this happens and notify the Troubleshooter. The Troubleshooter should make note of where the Machine is or what Operation Step the Machine is in and make note of the AB PLC Input and Output Indicators. Monitor the active Ladder Logic Program and see Which Line is holding everything up. If you go to the Switch or other Source that the PLC is waiting on and actually find the reason, you know what to do.

Assuming that the Machine has been functioning correctly in the past and there have been no Programming changes done lately to the Ladder Logic, the Ladder Logic can probably be ruled out. If there have been recent changes to the Ladder Logic, it is possible that a Logic error is at fault. The last possible error could be a Sequence of Events by the Operator could be at fault. An example would be a shortcut by stopping the Production Cycle to do something and restarting without Homing.

I agree with the others, the Safety Switch is not ‘Stuck’ it is still being held by the PLC and waiting for something to happen.

JimO

Or in this case the safety relay is responding to its own intermittent contact failure.

Sent from my XT1585 using Tapatalk

 

[cornbread]

Typical safety relays I've used have two contact in series, so it would have to fail both set of contacts at the same time. I have seen impedance problems (solid state output feeding a solid state device) that some times will cause the output float high enough to keep it on. I doubt that is you problem but a quick meter on the circuit will put that to bed.

 

[Tbrzezicki]

possable cause came up

possable cause came up

I agree with the others, the Safety Switch is not ‘Stuck’ it is still being held by the PLC and waiting for something to happen.

JimO

I finally went over by this certain robot and watched this carefully. There's a conveyor infeed to the robot that has light curtains installed, this relay is a light curtain muting relay (Allen Bradley). It has two photo-eyes before it and two after it to mute the safety light-curtain. On the boxes going to the robot there is a silver serial n umber sticker on the side and the second last photo-eye flickers once in a while when shining against the boxes. I know just one little flicker can set off a safety relay. And I notified the guy trying to diagnose this.

 

[Tbrzezicki]

Now the co-worker that said the safety relay had sticking contacts has a code 11 on the safety relay which he looked up as an internal fault. Since I originally posted this last year it has happened maybe 4 times. Now they want to change out the safety relay. I said "fine go ahead,and when that one fails then what" So now the "Co-worker" went out and purchased two of them and the company wants it replaced. Guess they just don't listen. Quest Robots says it's the safety rely so this guy is listening to them, Allen Bradley has never had this problem being specifically caused by the safety relay alone. I'm pretty much giving up as this co-worker is the person they are listening to and not me.

 

[petersonra]

It seems to me if the relay is diagnosing itself as having some kind of internal fault that the only option is to replace it. I don't know why you are opposed to replacing a piece of equipment that is telling you it has fail and should be replaced

 

[Tbrzezicki]

It seems to me if the relay is diagnosing itself as having some kind of internal fault that the only option is to replace it. I don't know why you are opposed to replacing a piece of equipment that is telling you it has fail and should be replaced

Because the guy that does this "diagnosing" knows little if nothing about PLC's, Safety relays or electric circuits. But he thinks he does. Like for instance his remedy so far was to buy 3 new safety relays. He usually buys a qty of 2 new of everything but in this case he bought 3. Doesn't know how to log into a SLC 500 to really see what tripping it so he keeps replacing the relay. We are on number 2 now and $1,700 dollars worth of relays, still not fixed.

BTW theres nothing wrong with the relay I was told to work on something else but this robot still faults out and he just keeps power cycling it.

 

[petersonra]

If the relay is diagnosing itself and saying that it has an internal fault that is not him making the diagnosis that is the relay. They're supposed to do that. In any case there is no reason why you should have to log into a PLC to diagnose a safety relay issue. The safety relay functions are supposed to be completely separate and generally PLC control functions and actual safety functions should not be mixed together.

I don't have any way to judge his level of Competency from here but I don't have a major issue with buying spare parts. It's Not Unusual to find that whatever broke the thing in the first place breaks the replacement especially if it's some kind of wiring problem where the wrong voltage somehow got put into the safety relay circuit.

These kind of things can be maddening to debug because often the Diagnostics available are pretty much go no-go and it's not that unusual for them to be misapplied or apply in ways that make it very difficult to debug. Maybe you're lucky you're not involved. Let somebody else pull his hair out and beat his head against the wall trying to fix it.

Incidentally I don't believe that the relay is stuck either. If it was stuck it would stay stuck. My guess is that something is maladjusted or just wasn't done correctly in the first place. A lot of safety circuits are horribly done by people who don't really understand what they are supposed to accomplish.

 

[Jraef]

...

Incidentally I don't believe that the relay is stuck either. If it was stuck it would stay stuck. My guess is that something is maladjusted or just wasn't done correctly in the first place. A lot of safety circuits are horribly done by people who don't really understand what they are supposed to accomplish.

Amen to that... In other parts of the world where these systems are MANDATORY, there are technicians who specialize in it, because it is a lot to know and learn all by itself. Here in North America, where it is NOT mandatory, it is often handled by general electricians who may or may not have the training and expertise to do it correctly.

But the other aspect of this that bothers me is the "robot mfr." not being able to diagnose and fix this issue. SOMEONE would have had to do a very thorough and official Safety Evaluation on the system as a whole, and PART of that process is a detailed study of what can go wrong and how to avoid it. So I still doubt this is a hardware failure issue, I think it is a procedural issue. Someone is doing something in the incorrect sequence and they are not getting the proper instructions as to HOW it should be done. THAT responsibility lies directly at the feet of the robot mfr. in my opinion.

 

[nec_addicted]

Sticking Contacts* Safety Relay

Sticking Contacts* Safety Relay

Allen Bradley SLC 500 (also verbally known as Slick 500') seems to me 1990's, process control and we used them for the then HART ( highway addressable remote transmitter) interface mainly where the analog signal conductors could be used for communications, and hot swapable I/O.

They are versatile before 'field bus' technology but were stalwart PLC with 32 bit I/O, could be programmed as 1/2 rack if desired and the back plane had these little yellow plastic inserts for the back plane of the bus in the rack(s).

The above background since I am getting in here late. The slick controller was not redundant logic solver capabilities but could have features set up for back up and lead lag functions.

We had occasional mishaps of processors not knowing which had the latest revision of the programmed functional sequence. I am trying to recall if it was FST (function sequence table) or just the plain DB 1 or DB 0 on the 1785 com card.

All these things as well MESG (minimum electrical safe gap) for options of using AB 700 series relays with discreet outputs from the Slick.

If the blue hose Data Highway (com link media IS 7001) is terminated correctly and there does not exist a Allen Bradley Guard PLC ( integrated) you may need a management of change to get your PLC version corrected after checking the scan to see I think that one scans vertically so all the ESD ladder logic has to be in the first or second rung or you will get flavors of problems.

One option you have is determine the latest update to the program then move the key switch on the controller and reload the latest version to the kernel (AKA firmware) inside the controller to set the logic controller straight which one has the lead.
Otherwise you will need to limp along until a shutdown for that particular line can be revised with a real safety PLC such as Triconix triple redundant I/O capable PLC.

 

[nec_addicted]

Another possibility hovers on the fringe Allen Bradley around that time frame allowed block transfer of addresses from one part of the plant to another say feed forward dynamic transfer during request from one processor to another in the network. It was intended as a precursor to ENET (thinner skinny brown or beige twinaxial media) where say distilling process values were need in dehydration. Occasionally these process requirements never made a smooth transition Like ENET over IP networks.

 

[petersonra]

Absolute gibberish. The Slick never had hot-swappable IO. If you pull an IO card out of a rack the processor faults.

The slick and the PLC5 both had redundant systems available. AB took it off the market after the control logic redundancy system became available.

What you are referring to as far as half rack addressing those never applied to the SLC line. It only applied to PLC 5.

 

[nec_addicted]

I thought half racks were one card rack divided into and addressed as two racks with one processor.
The hot swappable must have been the PLC5.

It was quite some time ago 27 years so I kind of following the idea that the SLC was not a safety PLC mentioned previouly but very nice features useful for the time of popularity. Obvious the Contrologix and Micro Logic might be fundamentally a better choice due to an out dated SLC 500 PLC.

 

[nec_addicted]

SLC 500 Fault 1F51h on swap

SLC 500 Fault 1F51h on swap

Evidently the SLC you could goto the Processor status file , to the IO tab, and put a zero on the IO slot enables now you can pull it out of chassis without going into a fault. if the processor processor is still in run mode when we put in the module an seat it even with the slot disabled we always got the stuck runtime error and that was what I thopught you were saying a few post back about it would report stuck.

I just thought with the runtime error might get cleared with or fixed by a fault routine.