Estop

I have a light curtain reset button on the back of my machine that operators have learned to wedge pushed in and I need write a rung that puts the machine in estop when the button stays mad for more that 5 secounds. what is the best way to write that line? I am using DirectSoft5 and RSlogix 5000 ver. 20

If the reset button is connected to a plc input I would use a delay on timer and add -|/|- timer into the "safety circuits ok" rung of the program.
If it has a HMI, you could set an alarm that warns the operator what he has done!

Ned_Flanders said:

If the reset button is connected to a plc input I would use a delay on timer and add -|/|- timer into the "safety circuits ok" rung of the program.
If it has a HMI, you could set an alarm that warns the operator what he has done!

Click to expand...

The operators are intentionaly doing this so they will not have to press it after each cycle. It is on an input but not being extremely fluent with DirectSoft and there is no details on the program and I cant fint he safety circuit ok rung. How would the delay timer help with not letting them hold the button in?

You need to modify the program so that it sees a change of state this can be done with a timer or a one shot.

Alan

Is this reset pushbutton only being used once in the program? If so, then Ned's suggestion should be easy to implement. Add a new rung with the pushbutton enabling an on-delay timer. Then, on the existing rung with the pushbutton, add a NC (---]/[---) contact of the timer's 'done' bit (just the timer name in DS5) in series with the pushbutton contact.

This will disable the pushbutton indefinitely when it is pressed for longer than the time delay (effectively un-pressing it). While this will not E-stop the machine, the operators will soon learn that their 'workaround' no longer works!...

I would probably use a one-shot as Alan said, but without seeing the program, I don't know how the program is using the pushbutton input. It may need to see the input for more than one scan...



-Eric

I like to examine the button and have that directly drive a timer, then replace all other references to that button with the TT bit (where available): Timer timing.

You can also code it (pseudo):
"Enabled and Not Done" or XIC Tx:y/EN XIO Tx:y/DN.

I use this TT bit also on the timer rung to seal around the mapped HMI or real button input.

This is easier to see, set it for one second, this should be easy to monitor remotely on the screen. If they tie down the button, the timer gets done, and the TT bit goes off and can't come back on until they release the button and press it again. One second guaranteed button presses are (usually) very easy to write logic for and follow live online.

That logic has become my catch all pushbutton logic for real ones and HMI buttons to avoid stuck button syndrome.

Option B: Fire the employees that are overcoming safety devices.

KB1GNI said:

Option B: Fire the employees that are overcoming safety devices.

Click to expand...

You stole my thunder....we have a zero tolerance policy about defeating safeties.

Why would they need to do that anyways? Is there a need to constantly reset the light curtains or is there a flaw in the process that if remedied would not require frequent resets...Just a thought.

I think a timer is overcomplicating the simple, make the reset button a rising edge pulse and call it a day. When depressed the reset input will only be high for 1 scan and then will require another off to on transition to be active again.

Dave

KB1GNI said:

Option B: Fire the employees that are overcoming safety devices.

Click to expand...

While I whole-heartily agree with this sentiment, I would take a step back and ask why they are doing it.

One could argue that they are just a bunch of stupid, lazy SOB's that don't have any common sense or you could look at them as trying to be efficient, productive workers (Theory X and Theory Y).

I obviously have no way of knowing the exact set up of the machine, so the OP will have make the call but does a hazard analysis show that they need to reset it after each cycle. If the machine doesn't start up when they hit reset and they need to hit a separate start button to initiate operation then the reset button may well be redundant.

The question to ask is "Does automatically reseting the light curtain cause a hazard?"

I believe it's the implementation of the "awake state confirmation" ("lights on" operator presence) automatic "enforcement" used within "Auto Pilot" aircraft controls or train locomotives' throttle "latch" circuitry.
If the CPU controller offers it, dploof23's suggestion will be the way to approach the issue (other than the HR irreversible "pink" decision) since it requires minimum editing.

Timbert said:

While I whole-heartily agree with this sentiment, I would take a step back and ask why they are doing it.

One could argue that they are just a bunch of stupid, lazy SOB's that don't have any common sense or you could look at them as trying to be efficient, productive workers (Theory X and Theory Y).

I obviously have no way of knowing the exact set up of the machine, so the OP will have make the call but does a hazard analysis show that they need to reset it after each cycle. If the machine doesn't start up when they hit reset and they need to hit a separate start button to initiate operation then the reset button may well be redundant.

The question to ask is "Does automatically reseting the light curtain cause a hazard?"

Click to expand...

You make a point in your last sentence, but I do not agree with a point of view they are efficient, productive workers. I have seen cases of reset-buttons being forced pushed in, overriding faults of the machine. in that perticular case only equipment safety was blocked, but in case of faults, things would break down and it would cost a lot, so nothing efficient about it...
In my case, a one-shot in the plc-program would have solved the problem.
In the OP's case; this light-curtain should be controlled by a separate unit, not the PLC. and the reset-switch should be in the circuitry of that light-curtain, not go to the PLC. and it should not be able to be fooled by holding it constantly pushed.

Is the safety device really being overidden by a PLC input??????

wimpiesplc said:

...this light-curtain should be controlled by a separate unit, not the PLC. and the reset-switch should be in the circuitry of that light-curtain, not go to the PLC. and it should not be able to be fooled by holding it constantly pushed.

Click to expand...

I've been watching this one with interest.
Excellent wimpiesplc, and others, for pointing out the bigger picture. Fix it! or design it better! But don't let them defeat a reset, period.

DJacobs, I can see how you are trying to use the tools available to you to overcome this issue. But really it's managements problem, not yours. I would not entertain coding this, to allow them side step the fact that operators are defeating the safety measures put in place to protect them and their co-workers.

The reset is on the back of your machine for a very good reason. If this light curtain allows full body entry/exit it is possible for an operator to pass through into the danger zone. Another operator wanting to reset and start the machine will have to go around to the reset at the back to do so. From this position they should have full view of the light curtain entry/exit points and see if there is any body in there before attempting a reset. Defeating the reset could create an auto reset which may allow an auto re-start, depending on the control design. This practice could have serious implications and should be stopped immediately. They should be trained for this.

If they are defeating a light curtain reset because it's tripping every cycle, is there something wrong with it?

It's mis-aligned?
Product is tripping on entry/exit? >>Muting sensor fault?
Machine stroke is triggering it?
Operators are triggering it?

Whatever it is, fix it. Whether it's your responsibility to do so or not, tell them, your superiors, not the operators, it has to be fixed and they need to stop them doing this immediately. This is managements problem, not yours.
If your doing this to save you fixing the problem....no comment.

Light curtain resets should be wired to the manufacturers specification. As wimpiesplc pointed out, they are nearly always controlled by a safety rated unit, or more modern LCs have built in control. Again, these resets nearly always have anti tie-down as standard.

The PLC anti tie-down methods described here are good, and you can use them to prevent this, but only if the PLC is switching the LCs proper reset, not acting as the reset.

I spent half of last Thursday with another Electrician sorting out a problem with a nuisance tripping light curtain. We sorted it eventually. It deflected us from other planned work, but it's safety, so it comes first. We don't by-pass unless there is a major fault that cannot be quickly fixed without stopping production for a long period. If we do by-pass an exemption order is signed by the shift supervisor and ourselves. Signage and barriers are put in place to prevent access and warn them of the danger. Everyone involved is informed.

Coding around this is letting management off the hook here.
We don't tolerate this behavior what so ever here.
Get your superiors to manage their operators better, train them, warn them, or fire them!

It's against the law to do what they are doing.
But not what you are doing, if the PLC is not the reset.

G.

I ran into this at a previous employer. They were pegging an 800T with a toothpick. The other contact was a PLC input. The system also had a very loud start buzzer. It added a 10 second timer with the done bit added to a new branch for the horn. Problem solved!