Override Key on AB PLC's

It sounds dangerous editing a plc program while someone is working at the same machine, is it a standard procedure?

Not all PLCs are controlling "machines"....

Many are running things that don't involve a "machine", such as Fermentation Temperature Control, Filters, HVAC, monitoring building temperatures, etc.
 
It sounds dangerous editing a plc program while someone is working at the same machine, is it a standard procedure?

Yes, it can be very dangerous to work on a machine that someone is editing a PLC program. The PLC must be powered for someone to edit. If powering the PLC means the machine is also powered, then the person working at the machine is NOT FOLLOWING LOCKOUT TAGOUT PROCEDURES!!! So, no, this is not standard procedure. FOLLOWING LOCKOUT TAGOUT PROCEDURES is the STANDARD PROCEDURE.

Now as to editing a PLC program on-line, yes, it is very much a standard procedure. For PLC and DCS system running processes in a 24-7 plant the opportunity to take systems down seldom occurs.
 
papejo,

this is my opinion.
For any machine, any time you edit a machine while it is in remote run mode, there is risk. the plc will do what you tell it to do, not what you wanted it to do. one must think out the process of the whole system, not just a few rungs.

When you edit a plc program when the machine is running, you CANNOT have others working in the machine! Even though you wrote the program and know exactly what will happen, you CANNOT have someone working on the machine! They may trip a sensor or limit switch at the same time you test the edits and things can go sideways real fast.

Many of us on the forum cannot stop machinery to make edits, some machines simply cannot be stopped. Steel plants, food, beverages, medical are just a few examples.

I cannot answer for others, but this is my procedure for online edits while machinery is running.

1. know the location of the machine and the assembly line.
2. talk to maintenance and discover the plc problem, sensor, valve, camera, or what ever it is.
3. discuss what needs to be done.
4. verify that all mechanics and operators are clear of the machine / assembly line and make the edits.
5. verify 1 more time that everyone is clear and then test the edits.
6 have maintenance watch the machine to see if edits are working.
7 exit out of the program when everything is ok.

even when there is a small machine, you must make sure everyone is clear and that you know what is in the machine when you do the edits.

regards,
james
 
I agree. Maybe the mechanics are trying to say they disapprove of remote edits, or worse, downloads.
Then the electrician should be going to his boss and explaining why he thinks leaving the PLC in REMOTE is unsafe, rather than taking it upon himself to switch it and then "throwing away the key."

I'll be honest I'm not keen on leaving PLCs in REMOTE. I know it is done out of convenience, but if you are truly doing something remotely, talking to the operator and have him switch to REMOTE before you start work isn't a bad thing.
 
...

even when there is a small machine, you must make sure everyone is clear and that you know what is in the machine when you do the edits.

regards,
james

Amen brother!

I worked with a number of guys who would sit at their desks making changes without notifying Maintenance or Production. Along with program changes, they were also speeding up the lines beyond the agreed to rate.

There was more than one crash, and it was a wonder no one got hurt.

When the electricians came to me about the problem, I told them to put the key in the run position. This put an end to a lot of that nonsense.
 
a little bit more about that key position ...

well, since we're talking about "safety" while working online – here's a little story to scare the kids with around the campfire ...

suppose that the RSLogix5000 ladder logic code shown below has been working fine for a very long time ... the software is currently online – and the machine is running along ... business as usual ... the sun is shining – the birds are singing – life is lovely ...

and now - someone (programmer, technician, civilian, or whatever) is poking around in the software ... maybe doing some troubleshooting – maybe just browsing around ... nothing remotely serious ... no changes to the code are planned ... just scrolling around and taking a look here and there ...

and then ...

somehow (maybe/probably unintentionally) the mouse gets clicked on the 3000 value shown in the LES instruction ... and with the mouse still clicked – our hero drags the pointer up – up – up – to a location near the middle of rung 0 ...

note that this is incredibly easy to do for folks who use that handy-dandy little "Touch Pad" gizmo on their laptops ... personally I call those things "suicide pads" – and I insist on using a real honest-to-goodness mouse instead ...

and now - maybe our suspect (bless his little heart) just happens to release the mouse button ... oops! ... did you notice the little green target next to the timer's Preset entry? ... the one sort of "hiding in the underbrush" way over at the right side of the screen? ... got any idea what's going to happen to the 10000 value currently stored in that Preset location? ...

well, hang on - here's what's going to happen ...

the 10000 value is going to get INSTANTLY changed to a value of 3000 ... and that means that our 10-second timer is suddenly set to be a 3-second timer ...

that means that the next time the TON timer gets energized, the output on rung 1 is NOT going to wait for 10 full seconds before it gets turned on ... instead it's going to come on after just 3 seconds ... now in some situations that change in timing won't amount to a hill of beans – but in other situations it could turn out to be a "lawyer-level" problem – something of biblical proportions ...

and the output on rung 2 is NOT going to stay on for 10 full seconds before it gets turned off again ... now it's going to come on and run for just 3 seconds instead ... so is that a "big deal" for this particular piece of machinery? ... well, maybe it's not – but then again – maybe it is ...

now consider the output on rung 3 ... this one is supposed to come on 5 seconds after the switch gets turned on ... but suddenly it's been "rescheduled" – and it's not going to come on at all ...

the output on rung 4 (bless its little heart) still works exactly like it always did ...

the important thing here is that the changes to the machine's operation were UNINTENTIONAL ... they were UNEXPECTED ... and they were UNANNOUNCED ...

did the software give us a little pop-up message to warn us? ... nope ...

did we have to Accept – then Test – and then Assemble the changes to put them into effect? ... nope ...

and notice that the mouse pointer on the screen was over 3 inches away from the little green target when we made this tiny little mistake ...

personally I think that it's entirely too easy to make these types of changes – but that's the way it works, folks ...

oh – and I almost forgot to mention ... you can make this type of drag-and-drop change to the code even while the processor's key is firmly and fully set to the RUN position ...

so maybe we should always work "offline" for safety ... wouldn't that be better? ...

well, yes, certainly "better" ... but then again – it's still extremely easy to make these types of long-distance – unintended – unannounced – unnoticed - changes to the code by simply clicking and dragging ...

and if the individual making the change "offline" doesn't even notice the mistake – guess what happens when the offline code is eventually downloaded to the processor - and finally put into operation ...

the main point here is that you really – REALLY – need to be careful around this stuff ... and having the processor's key in the RUN position is NOT necessarily a foolproof way of eliminating unintended changes to the code ...

party on ...
.

mouse_grabs_a_target.jpg
 
Last edited:
...

note that this is incredibly easy to do for folks who use that handy-dandy little "Touch Pad" gizmo on their laptops ... personally I call those things "suicide pads" – and I insist on using a real honest-to-goodness mouse instead ...

I'm stealing that. Two of my partners use a touchpad, and I occasionally help them with something and I insist on turning off "Tap to click" at the very least. So now I have a new term for it "Suicide Pad"...

Thanks Ron!
 
My #1 task on startup is to place the PLC in Remote, remove the keys and walk to the nearest trash can and toss them in it!

PS. You can use the end of a small pocket knife just the same anyway.
 
Glad to see I'm not the only person that flips out when he sees someone with "tap to click" enabled on their laptop. Another dangerous one is a touch screen on a maintenance toughbook.
 
I have a compact logix controller that the key has been turned to RUN mode, if the key is switched back to REM, will it shutdown the process?



thanks,
 
No. The controller will remain in "Remote Run" mode.

I am sometimes a little nervous because the (modern) CompactLogix uses a toggle switch instead of a rotating key, but if I do it carefully I've never had the toggle go all the way to PROG.
 

Similar Topics

Hi all, I have a PIDE block (Logix5000) where I am introducing interlocks. I am using the ProgOverrideReq to set the CV to 0% (shut a control...
Replies
3
Views
1,599
I am practicing PLC programming with Rslogix500 and SLC500. I got a typical seal-in branch circuit (see the picture). I am trying to add a HMI...
Replies
17
Views
4,195
Hello, I have an application where I need to implement an override of a temperature trip. Essentially, this is a distillation column, but when...
Replies
16
Views
7,003
I have some code that is going to trigger calculations to happen either when "A" happens, or every 1 second. For the 1second trigger, I am...
Replies
3
Views
1,616
Dear all I am working on a little project where i want to use the Function Override control with PID_TEMP(See attached). You can compare the...
Replies
0
Views
1,429
Back
Top Bottom