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 ...
.