sticking contacts on a safety relay

[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]

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]

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.