Overload Fail Safe

[cidchase]

My employer is in the habit of applying a roller limit switch on a P&F chain overload in a non-fail-safe manner. The LS is only operated if the spring-loaded cat-drive mounting sled moves enough to indicate an overload condition. If the LS is adjusted improperly, or if the wire is cut, or if the LS arm is missing, etc., there is NO protection.
Other vendors I have worked with apply this LS so that its roller is always in contact with the floating striker, until such time as an overload causes it to roll off the end, stopping the motor.
I don't know how much of a stink to create, but I really wish we would stop this practice. Anyone have a similar situation, or comment on the safety aspect?? I feel like there is no regulatory standard covering this. Thanks for your input; I realize it's not truly PLC related, but certainly controls-related.

Cid

 

[JeffKiper]

I had a customer doing the exact same thing with limits. I showed them all the failure point of doing that.
I then showed them if we used a prox switch that was positive placement on the drive. If we lost the cable or prox or the tension went to high or to low. We would lose the signal and shut the system down. They wanted limit switches until i showed them old limit switches covers in grease that didnt allow them to move any more. Each system has it's pros and cons. Document both ways and let them make the call. I also ibcluded the cost of limit switches abd prox. They very quickly went with prox switche. Just by looking at points of failure. If you can get the man hour to mount and adjust and test the limit you can also show that. We had the prox welded to the base plate so it wasnt easy to move. The limits they always had on unistrut so anyone could move them.

 

[ASF]

.
I don't know how much of a stink to create...

How much of a stink you should create depends on a lot of factors but at the absolute minimum you should raise it, in writing, clearly outlining your concerns and the risks you perceive there to be. You should get confirmation (again in writing) that your communication was received and read. At that point you've at least covered your own backside.

Beyond that, my considerations regarding the quantity of stink to raise would include:
- Has a risk assessment been done on the equipment?
- Do I have relevant expertise or qualifications regarding this particular machine/hazard/design/process?
- Does my expertise/qualifications (if any) oblige me to take any particular action?
- How engaged or otherwise are management etc when it comes to safety?
- What is my role within the company/on this site?
- What is my relationship like with management etc?
- How important is my continued employment at this site?
- Am I directly exposed to the perceived risk?
- Could I live with myself and the amount of stink I was willing to raise about this issue if something went wrong and someone got hurt?

 

[I_Automation]

I stick by one simple rule:


Current must flow for there to be motion.


I have had chain-break LS's riding on a chain and held on, if the chain breaks or got too much slack the LS would release, open the contact and the fault condition handled however it needed to be. (Stop motion, interrupt the E-stop loop, sound an alarm, etc.)


If anyone suggests the opposite I simply tell them that in the event of a failed switch or relay contact, or broken wire, they would never know the fault appears and the machine would try to keep running until it kills every person in the country and no one is left to generate electricity for it to keep running.


Sometimes you have to be blunt and direct with management.

 

[JeffKiper]

We are getting away from mechanical switches because the springs in them are a point of failure. We have switched to solid state whenever possible.

 

[I_Automation]

Also, I think the "There must be current flow..." is a written standard - just not sure which.


At least that's what I seem to remember when I was taught that, that has to be back in the 1990's so maybe the Olds-heimers might be kicking in here.