[Colin Carpenter]

Can anyone tell me if it's OK / advised to insert rungs in "online mode" into an RS Logix 500 programme?

Reason I ask is this:

System is a large(ish) SLC 500/5 system with 3 PLCs sharing information by Ethernet through a switch.
Needed to insert a couple of rungs into one of the PLCs while "online".
All seemed to go OK, no fault lights, no error messages .....UNTIL
The PLC that had received the two rungs stopped communicating by Ethernet and all hell broke loose, with the other two running into problems.
Much panicking and head scratching revealed that the rung that called the Comms Ladder (SBR) had become deleted in the MAIN Ladder, so the Comms part of the software was not operational.This rung would have been Rung 3 in the entire Programme.
Re-loaded the backup code and all is now well.

So, it seems like inserting two rungs way down in the programme caused deletion of at least one rung at the top of the programme. It definitely wasn't a human deletion, as there were two of us, each checking the other's actions.

Did we try and do something that's not possible or something that just shouldn't be attempted?

[jstolaruk]

Yes, you can insert lines. About the only thing you can't do online is add new program files, new data files, and increase existing data table sizes.

This post has been edited by jstolaruk: 03 February 2006 - 02:45 PM

[Colin Carpenter]

Thanks ..... goodness only knows how that line managed to become deleted, it's a complete and utter mystery as we never even went into that particular ladder. Very odd!!

[TWControls]

I know you can do this in controllogix but can't remember about SLC

Is it possible that the line had edited for deletion a long time ago by accident and accepted but never assembled?

[jstolaruk]

Colin Carpenter, on Feb 3 2006, 03:45 PM, said:

Thanks ..... goodness only knows how that line managed to become deleted, it's a complete and utter mystery as we never even went into that particular ladder. Very odd!!

Actually, when editing online, all it takes is a fat finger on the delete key while scrolling through logic with the pageUp pageDn keys if those keys are grouped together. Then, if you edit another rung and assemble it, the rungs marked for deletion disappear and go to bit heaven.

[Ron Beaufort]

ok ... so the stone has been turned while I was typing away ... but I'm going to post my version anyway ...

this is some pretty scary stuff ... first of all a disclaimer to one and all ...

Quote

what I am about to post is NOT intended to be complete ... there is much more to this subject than I have time to post right now ...

but this should at least help nail down some basic ideas ... first of all, let's say that we're ONLINE (communicating) with our SLC-5/04 processor ... and suppose that the processor is currently in the REMOTE RUN mode ...

the sun is shining ... the birds are singing ... life is lovely ...

suppose that rung number 0013 in Ladder File #2 contains a JSR (Jump to Subroutine) instruction ... the JSR calls Ladder File #3 ... everything is working correctly ... our cursor (that big red box) is currently located on the rung number (0013) of that JSR rung ...

we scroll up to rung 0002 in Ladder File #2 ... we don't click anything on the screen except the scroll buttons ... we're just taking a look around ... quick question: where is the cursor right now? ... answer: it's still down there on the rung number of that JSR rung 0013 ...

now suppose that somehow/someway we press the "Delete" key on our keyboard ... if we watch carefully we might notice that the "Bill Gates Rolex" (hourglass) shows up on the screen for a second or so ... but let's say that we don't notice it ... or just don't pay any attention to it ... quick question: what just happened? ... answer: we just marked rung 0013 for "Deletion" ... has it actually been deleted? ... no, not yet because we haven't done the "Test" and the "Assemble" steps for our edits ... so IF (big IF) we were to go down and look at rung 0013, we'd definitely see a row of "D" characters marking the rung ... but we're fat, dumb, and happy ... we don't go look ...

the sun is shining ... the birds are singing ... life is lovely ...

ok ... it's getting late and we're through programming for today ... we save the program like good little boys and girls... we notice that as we head out of the plant everything is still working fine ...

the sun is shining ... the birds are singing ... life is lovely ...

three months pass by ... everything is still fine ... eventually we decide to do a little bit of programming ... we need to do this ONLINE to keep the rest of the plant running ... and the processor needs to stay in the REMOTE RUN mode ... no problem ... we've done things like this before ... we'll be REAL careful ...

we go to Ladder File #4 ... we decide to add in a couple of new rungs ... we put the new rungs in and we "Accept" them to send them over to the processor ... so far so good ... but the new rungs aren't being scanned yet ...

so now we do the next step and "Test" the rung edits ... we click the icon ... the friendly popup message says "blah, blah, blah - Are you sure you want to Test Edits?" ... well of course we're sure ... we've done this hundreds of times before ... it's just the next simple step in a well-rehearsed sequence of events ...

the sun is shining ... the birds are singing ... life is lovely ...

and now ... (imagine spooky music playing in the background) ... we ... click ... the ... "Yes" ... button ...

quick question: what just happened? ... answer: that "unknown" deletion that we mistakenly put in place three long months ago has suddenly just been brought to life ... specifically, the JSR on rung 0013 of Ladder File #2 is NOT being executed ... and more specifically, Ladder File #3 is NOT being scanned anymore ...

whoa! ... do you mean to tell me that when we "test the edits" in Ladder File #4, that we also activate any edits that exist in ALL of the program files? ...

oh, yeah ... welcome to the real world ...

back to our story ... so suddenly whatever is programmed in Ladder File #3 is NOT being scanned anymore ... gee, I hope that some DANGEROUS! output wasn't ON when we quit scanning the ladder ... because it's NOT going to go OFF the next time the operator pushes the "Stop" button ... instead it's going to stay in its last state ... that doesn't sound like a good thing now does it? ... (side line: that's one good reason why the PLC shouldn't be the only thing that controls an Emergency Stop function) ...

but remember, we're up in the control room ... we're not even aware of any problems with the machinery being controlled (or rather NOT being controlled) by Ladder File #3 ... that machinery is way on the other side of the plant ... as far as we know, everything is still fine ... the new rungs that we just programmed in are being scanned now ... and they're simmering along just fine ... we feel good ... so let's go ahead and do the next step ... we click the "Assemble" icon ...

the friendly popup message says: "Are you sure that you want to Assemble Edits?" ... heck yeah ... let's nail this thing down and go home ... and now ... (more spooky music) ... we ... click ... the ... "Yes" ... button ...

quick question: what just happened? ... answer: all traces of the JSR rung (number 0013 in Ladder File #2) are GONE ... but let's say that we don't even notice ... the stuff that we just programmed in is working fine ... so we save the program and close up for today ...

as we're heading out of the plant, we hear some commotion going on over by the "Ladder File #3" machinery ... hope those guys on night shift have fun with "their" little problem ... but as for us, well, we've had a good day working with Ladder File #4 ... we're out of here ...

end of story - for now ...

folks, when I demonstrate these particular concepts to my students, I can always spot the ones that are really "on the ball" ... they're the ones that literally turn pale ... but some guys just nod once and are ready to move on to the next lesson ... those are the ones that really scare me ...

anyway ... here's something that you should train yourself to look for ...

Attached image(s)

• 

This post has been edited by Ron Beaufort: 03 February 2006 - 04:42 PM

[TWControls]

LOL - You crack me up Ron. I like your explaination much better

[Chris Elston]

Gosh dern it....I am going to make a forum called "The Best of Ron" and move posts like these into that forum so we can all honor it.... great post Ron!

[Colin Carpenter]

Yes, Thanks, that was really good...... now you mention it, it did seem that we had to "Test and Assemble" more often than the two rungs merited, but assumed that it was a function of inserting lines , which neither of us had done before in "Online" mode.

Excellent, Thankyou ....

[Alaric]

I train all of our maintenance guys to do exactly what our resident Guru Ron just talked about.

When ever they go online the first thing they are supposed to do is look to see if edits exist. When ever they go offline they are to look and see if edits exist. I drill it in and drill it in. And guess what?

The other day Bubba needed to go online to force a bit while he aligned a limit switch he had replaced and so he asked me to come and look over his shoulder and see if he was doing it right. So what do you think was the first thing Bubba did after going online?



You teach and you drill over and over again and sometimes it just never ever sinks in.

Nothing gives me the warm fuzzies [/sarcasm] quite like when Bubba calls at 2:00 am and says "I'm online with the XXX plc and I have a question"

[Colin Carpenter]

Ummm ..... one more thing ..... if edits do exist, is there a quick way of finding them? Can they be found when "offline" or does the PC have to be "online" to find them?

Thanks again.

This post has been edited by Colin Carpenter: 04 February 2006 - 02:19 PM

[Ron Beaufort]

Greetings Colin,



the figure below should help ... you can do this search ONLINE (communicating with the processor) or OFFLINE (working on a computer resident file) ... but ... if you do the search OFFLINE, then there is no guarantee that someone (you or someone else?) hasn't recently made an edit ONLINE in the processor ... so ... if you only did the search OFFLINE, then you could still be in trouble ...



basic idea: it would be best to do this search ONLINE ... probably the only reason for doing it OFFLINE would be if you were planning to download the file to the PLC ...

Attached image(s)

• 

[jstolaruk]

!! good tip Ron !!

[Colin Carpenter]

Wow .... thanks, Ron!!

Reason I ask is that on Monday, I aim to have another go at adding those two pesky rungs, but this time, I'm gonna make 100% sure that those are the only lines that get modified. I'll use the above to search and find out what may still be lurking in the programme.

For future use, is there a quick way to "CLEAR" ALL pending edits that others might have unwittingly left in as potential time bombs. This particular system (programmed by others) is so bug ridden that it has an RS Logix PC connected at all times and requires continuous fiddling with by maintenance electricians, some good, some not so good, so it's always open to this type of problem.

Thanks again.

[Ron Beaufort]

Greetings Colin,

Quote

is there a quick way to "CLEAR" ALL pending edits

the answer is "yes" ... BUT ... you have to think VERY carefully before you use it ...

let's say that someone has previously made a change to the program ... for example: an XIC has been changed to an XIO ... the altered rung has been "Accepted" ... and the altered rung is being "Tested" ... the new rung is marked with "I" characters which means that the rung is marked to be "Inserted" ... the machine is working fine with the new XIO in place ... but ... the old rung (with the old XIC in it) is STILL present in the program ... that old rung is marked with "R" characters which means that it is marked to be "Replaced" ... now the old rung is NOT presently being executed by the processor ... you can tell this because the "power rails" at the left and right ends of the old "R" rung are NOT highlighted ... instead, the power rails of the new "I" rung ARE highlighted ... so ... the processor is using the new (XIO) rung - and ignoring the old (XIC) rung ... and as I said, the machine is working fine this way ... many months go by ...

preview: the "Edits Active" figure at the bottom of this post shows how this condition will be indicated on the screen ...

now it's time to do some more programming ... we need to do this ONLINE and with the PLC in the RUN MODE ...

we walk in and we notice the "Edits Active" message ... we realize that we are NOT going to be able to add, or delete, or change any other rungs until those presently "active" edits are taken care of one way or another ...

right now, we have two choices available ... we can either:

(1) "Untest" the active edits ... and get on with our programming ... or we can
(2) "Assemble" the active edits ... and get on with our programming ...

and now we're to the scary part of the show ...

to some people, the natural thing to do next is to simply "untest" the existing edits ... but STOP! and think first ... if we do that, then the old XIC rung will spring back into life ... is that what we want to happen? ... probably not ... because, as we've already said, the machine has been running correctly for several months with the new XIO in place ... if the processor goes back to executing that old XIC rung, then SOMETHING about the machinery's operation is going to change ... and smart money says that the change will NOT be a good thing ...

and so ... of the two choices that we've been given above, the best/safest thing to do at this point is to "Assemble" the edits ... that means that the old "R" rung with the XIC will vanish from the program ... and the new "I" rung with the XIO will be "permanently" installed ... but at least the operation of the machine will not be altered by our actions ...

now then ... some other programmer might come back to work from vacation tomorrow and be very angry with us ... perhaps that new XIO rung was just a "temporary" repair that he had planned all along to remove someday ... but now we've messed up his plans by "Assembling" the edits ... and so now he'll be forced to re-enter his old XIC rung from scratch ... such is life ...

going further ... now that you know how to search for all of the edits in the program, you're in a good position to make wise decisions about whether you want to "Untest" active edits - or "Assemble" active edits ... but the point of all of this is that you should carefully THINK before you simply "Untest/Clear/Cancel" any active edits ... in many (most?) cases, that is NOT the correct path to take ...

now ... on the other hand ... let's say that the message reads "Edits Exist" instead of "Edits Active" ... specifically, there ARE edits in the program - but they are NOT actively being used right now ... if the machine is already running fine without actually executing those edits, then in that particular case, you could simply click the big red "X" and Cancel the edits ... that operation should NOT change the present operation of the machine ... of course you might want to use that handy search feature and go take a look at those edits before you wipe them out ... but at least the machine shouldn't go nuts if you were to simply skip that step ...

so that's some more of the story ... as with EVERYTHING that we do with PLCs, we need to carefully think about what the results of our actions will be BEFORE we take the action ... the scariest part of it all is that there are a LOT of people out there working with these things day in and day out who don't realize just how easy it is to mess things up ...

finally ... thanks to everyone for the kind compliments ...

Attached image(s)

• 

This post has been edited by Ron Beaufort: 05 February 2006 - 06:22 PM

[Colin Carpenter]

You're right, this is truly scary stuff!

I must confess to not realising some of the implications of online editing, namely the exact meaning of the words "Accepted", "Tested" and "Inserted" and "Replaced". I had assumed that:

"Accepted" - meant that the line being edited was now complete.
"Tested" - meant that the line was being checked (verified) for syntax etc. by RS Logix
"Inserted" - meant that the line was now, and only now, being inserted into the CPU.

But, it seems like "Tested" means that the line is now "operational" in the CPU, but is waiting for you to confirm that you want it to stay in there.

This is similar but very different to online editing using Mitsubishi's IEC Developer, but there are very big differences.

With IEC, you select "Online Editing" mode, then you start to edit the rung. As soon as you move outside of that particular rung, then the software assumes that you have finished editing and starts to compile and check the code. If it compiles OK, then and only then do you get the choice of writing the code to the CPU. If it compiles incorrectly then it returns the rung to the original state unless you tell it to carry on.

Sounds more restrictive, but maybe that's a good thing in the light of the problems that can arise with RS Logix and multiple edits all waiting to be actioned, maybe without your knowledge.

Incidentally, we managed to insert those two rungs today without any further mishap. The re-loaded backup software (backed up just prior to the original mods) strangely didn't contain any pending edits when we went online. We had also assumed (wrongly) that you had to double click the rung below which you wanted to insert the new line, which kind of explains our "extra" tests etc, but then found out that all you have to do is drag a rung to anywhere you like in online mode.

So I'm still slightly baffled about how that line managed to get deleted, but in a way, I'm glad that it did because, thanks to your time and patience, I've learned one heck of a lot about online editing in the past few days.

Once again, many thanks ......

[Ron Beaufort]

first ... a disclaimer ...

PLEASE NOTE: all of the following applies ONLY to editing while ONLINE with RSLogix5, RSLogix500, and RSLogix5000 software ... "ONLINE" means that the programming computer is connected to - and communicating with - the PLC processor ...

PLEASE FURTHER NOTE: all of the following applies ONLY to editing while the PLC processor is operating in the REMOTE RUN mode ... this means that the processor's keyswitch is in the "REM" (Remote) position - and that the processor is currently scanning/executing its ladder logic program ...

Quote

ACCEPTING A RUNG

when we "Accept" a rung, that rung is:

(1) automatically verified for syntax errors AND then (most importantly) ...
(2) also SENT from our programming computer over to the PLC processor ...

and so "Accept" should be thought of as a two-step process ... we could nail down the two steps by saying (1) verify, and (2) send ...

great source of confusion: in the English language, the word "accept" means to "take" ... for example: "I can't accept (take) that gift. It is far too expensive." ... on the other hand, with RSLogix software, "accept" means to "send" ... so a rung with syntax errors might generate a message something like this: "Rung has errors. Cannot Accept (send to the processor)." ... this message does NOT mean that the processor refused to "take" the faulty rung ... in fact, the processor never even saw it coming ... instead the RSLogix software caught the syntax error and refused to even try to "send" the faulty rung to the processor ...

so ... "take" vs. "send" ... how did they get it backwards? ... I don't know, folks ... I wasn't there ...

further detail ... suppose that you "Accept" a new rung ... suppose that you do not "Test" or "Assemble" the program ... then suppose that you remove the processor from the chassis ... of course the power to the processor is now OFF - but the processor's battery is now maintaining the processor's memory ... suppose that you ship the processor to another location and then plug it into another chassis ... that "Accepted" rung (which was SENT/ACCEPTED into the processor) is STILL THERE ... specifically, if someone else with a completely different programming computer now goes ONLINE with the processor, they WILL see that new "Accepted" rung still in place in the program ... the rung will be marked with "I" characters ...

Quote

TESTING EDITS

when we "Test" the edits, the PLC processor begins to scan/execute the changes/edits that we have already made and "Accepted"... specifically:

any new "I" rungs (marked for Insert) ARE now scanned/executed ...
any old "R" rungs (marked for Replacement) are NOT scanned/executed ...
any old "D" rungs (marked for Deletion) are NOT scanned/executed ...

further detail ... it is literally the PLC processor that is being told to "TEST" the edits - NOT the RSLogix programming software ... long before the edits are "Tested", the RSLogix software has already made its own "verify/test" for syntax errors ... specifically, the software always makes that "syntax test" even BEFORE the rung is actually sent over to the processor ...

note that the "I" and "R" and "D" marks above are CAPITAL LETTERS ... secret handshake: changes/edits marked with capital letters ARE physically located inside the PLC processor ... on the other hand, changes/edits which are marked with lower-case (little) letters are NOT located inside the PLC processor ... specifically, those lower-case changes/edits exist ONLY on your programming computer ...

going further ...

when we "Test" the edits, the PLC processor does NOT scan/execute any changes/edits that are marked with lower case letters ... the simple reason is that those "lower case letter" changes/edits are NOT even physically present inside the processor ... specifically: changes/edits marked with lower case letters have NOT been "Accepted" (or in other words "SENT") to the processor ... so how could the processor possibly scan/execute a change/edit that he knows absolutely nothing about? ... simple truth: he can't ...

nailing this down ... suppose that you make edits/changes to a rung but you do NOT "Accept" it ... such changes are shown on your programming computer screen marked with lower case (little) letters ... now suppose that you remove the processor from the chassis ... of course the power to the processor is now OFF - but the processor's battery is now maintaining the processor's memory ... suppose that you ship the processor to another location and then plug it into another chassis ... that "UN-Accepted" rung (which was NOT sent into the processor) is NOT (I repeat: NOT) in there ... specifically, if someone else with a completely different programming computer now goes ONLINE with the processor, they will NOT see that new "UN-Accepted" rung ... nugget of truth: until you have "Accepted" the edits/changes, then those edits/changes live ONLY on your programming computer ... specifically, edits/changes must be "Accepted" in order to be sent to the PLC processor ...

Quote

ASSEMBLING EDITS

when we "Assemble" our edits, we tell the PLC processor to "nail everything down and make our program neat" ... at this point, the temporary changes/edits that have been marked with "I" and "R" and "D" are made permanent ... specifically:

any new "I" rungs (marked for Insert) are now fully inserted into the program ... and the "I" characters disappear ...

any old "R" rungs (marked for Replacement) are now finally replaced by their corresponding "I" rungs ... the "R" rungs disappear from the program ... and the "R" characters disappear ...

any old "D" rungs (marked for Deletion) are now finally removed from the program ... and the "D" characters disappear ...

our "Assembled" program is now at peace with the universe ...

finally ... repeating the same disclaimer ...

PLEASE NOTE: all of the above applies ONLY to editing while ONLINE with RSLogix5, RSLogix500, and RSLogix5000 software ... "ONLINE" means that the programming computer is connected to - and communicating with - the PLC processor ...

PLEASE FURTHER NOTE: all of the above applies ONLY to editing while the PLC processor is operating in the REMOTE RUN mode ... this means that the processor's keyswitch is in the "REM" (Remote) position - and that the processor is currently scanning/executing its ladder logic program ...

so ... are we having fun yet? ...

finally, I've been teaching all day and I'm tired ... and so I might have made some errors in the above ... as always, if anyone spots anything wrong, I'd appreciate a correction ... but ... I really think that I've got it right ...

This post has been edited by Ron Beaufort: 06 February 2006 - 07:20 PM

[hakko808]

It seems as if some of the confusion comes from RSlogix terminoligy being chosen from the perspective of the PLC even though the software is being run on a PC. I had some confusion over upload/download seeming backwards until I figured this out.

[Colin Carpenter]

Thanks, Ron.

I'm going to incorporate all your text and diagrams on this subject into a PDF file and call it
"Online Programming ... what it all means" and make sure that it's easily accessible on my laptop for future reference.

[R.Dave]

Ron Beaufort, on Feb 3 2006, 09:36 PM, said:

ok ... so the stone has been turned while I was typing away ... but I'm going to post my version anyway ...

this is some pretty scary stuff ... first of all a disclaimer to one and all ...

Quote

what I am about to post is NOT intended to be complete ... there is much more to this subject than I have time to post right now ...

but this should at least help nail down some basic ideas ... first of all, let's say that we're ONLINE (communicating) with our SLC-5/04 processor ... and suppose that the processor is currently in the REMOTE RUN mode ...

the sun is shining ... the birds are singing ... life is lovely ...

suppose that rung number 0013 in Ladder File #2 contains a JSR (Jump to Subroutine) instruction ... the JSR calls Ladder File #3 ... everything is working correctly ... our cursor (that big red box) is currently located on the rung number (0013) of that JSR rung ...

we scroll up to rung 0002 in Ladder File #2 ... we don't click anything on the screen except the scroll buttons ... we're just taking a look around ... quick question: where is the cursor right now? ... answer: it's still down there on the rung number of that JSR rung 0013 ...

now suppose that somehow/someway we press the "Delete" key on our keyboard ... if we watch carefully we might notice that the "Bill Gates Rolex" (hourglass) shows up on the screen for a second or so ... but let's say that we don't notice it ... or just don't pay any attention to it ... quick question: what just happened? ... answer: we just marked rung 0013 for "Deletion" ... has it actually been deleted? ... no, not yet because we haven't done the "Test" and the "Assemble" steps for our edits ... so IF (big IF) we were to go down and look at rung 0013, we'd definitely see a row of "D" characters marking the rung ... but we're fat, dumb, and happy ... we don't go look ...

the sun is shining ... the birds are singing ... life is lovely ...

ok ... it's getting late and we're through programming for today ... we save the program like good little boys and girls... we notice that as we head out of the plant everything is still working fine ...

the sun is shining ... the birds are singing ... life is lovely ...

three months pass by ... everything is still fine ... eventually we decide to do a little bit of programming ... we need to do this ONLINE to keep the rest of the plant running ... and the processor needs to stay in the REMOTE RUN mode ... no problem ... we've done things like this before ... we'll be REAL careful ...

we go to Ladder File #4 ... we decide to add in a couple of new rungs ... we put the new rungs in and we "Accept" them to send them over to the processor ... so far so good ... but the new rungs aren't being scanned yet ...

so now we do the next step and "Test" the rung edits ... we click the icon ... the friendly popup message says "blah, blah, blah - Are you sure you want to Test Edits?" ... well of course we're sure ... we've done this hundreds of times before ... it's just the next simple step in a well-rehearsed sequence of events ...

the sun is shining ... the birds are singing ... life is lovely ...

and now ... (imagine spooky music playing in the background) ... we ... click ... the ... "Yes" ... button ...

quick question: what just happened? ... answer: that "unknown" deletion that we mistakenly put in place three long months ago has suddenly just been brought to life ... specifically, the JSR on rung 0013 of Ladder File #2 is NOT being executed ... and more specifically, Ladder File #3 is NOT being scanned anymore ...

whoa! ... do you mean to tell me that when we "test the edits" in Ladder File #4, that we also activate any edits that exist in ALL of the program files? ...

oh, yeah ... welcome to the real world ...

back to our story ... so suddenly whatever is programmed in Ladder File #3 is NOT being scanned anymore ... gee, I hope that some DANGEROUS! output wasn't ON when we quit scanning the ladder ... because it's NOT going to go OFF the next time the operator pushes the "Stop" button ... instead it's going to stay in its last state ... that doesn't sound like a good thing now does it? ... (side line: that's one good reason why the PLC shouldn't be the only thing that controls an Emergency Stop function) ...

but remember, we're up in the control room ... we're not even aware of any problems with the machinery being controlled (or rather NOT being controlled) by Ladder File #3 ... that machinery is way on the other side of the plant ... as far as we know, everything is still fine ... the new rungs that we just programmed in are being scanned now ... and they're simmering along just fine ... we feel good ... so let's go ahead and do the next step ... we click the "Assemble" icon ...

the friendly popup message says: "Are you sure that you want to Assemble Edits?" ... heck yeah ... let's nail this thing down and go home ... and now ... (more spooky music) ... we ... click ... the ... "Yes" ... button ...

quick question: what just happened? ... answer: all traces of the JSR rung (number 0013 in Ladder File #2) are GONE ... but let's say that we don't even notice ... the stuff that we just programmed in is working fine ... so we save the program and close up for today ...

as we're heading out of the plant, we hear some commotion going on over by the "Ladder File #3" machinery ... hope those guys on night shift have fun with "their" little problem ... but as for us, well, we've had a good day working with Ladder File #4 ... we're out of here ...

end of story - for now ...

folks, when I demonstrate these particular concepts to my students, I can always spot the ones that are really "on the ball" ... they're the ones that literally turn pale ... but some guys just nod once and are ready to move on to the next lesson ... those are the ones that really scare me ...

anyway ... here's something that you should train yourself to look for ...

R.Dave, on Feb 16 2006, 06:06 PM, said:

Ron Beaufort, on Feb 3 2006, 09:36 PM, said:

ok ... so the stone has been turned while I was typing away ... but I'm going to post my version anyway ...

this is some pretty scary stuff ... first of all a disclaimer to one and all ...

Quote

what I am about to post is NOT intended to be complete ... there is much more to this subject than I have time to post right now ...

but this should at least help nail down some basic ideas ... first of all, let's say that we're ONLINE (communicating) with our SLC-5/04 processor ... and suppose that the processor is currently in the REMOTE RUN mode ...

the sun is shining ... the birds are singing ... life is lovely ...

suppose that rung number 0013 in Ladder File #2 contains a JSR (Jump to Subroutine) instruction ... the JSR calls Ladder File #3 ... everything is working correctly ... our cursor (that big red box) is currently located on the rung number (0013) of that JSR rung ...

we scroll up to rung 0002 in Ladder File #2 ... we don't click anything on the screen except the scroll buttons ... we're just taking a look around ... quick question: where is the cursor right now? ... answer: it's still down there on the rung number of that JSR rung 0013 ...

now suppose that somehow/someway we press the "Delete" key on our keyboard ... if we watch carefully we might notice that the "Bill Gates Rolex" (hourglass) shows up on the screen for a second or so ... but let's say that we don't notice it ... or just don't pay any attention to it ... quick question: what just happened? ... answer: we just marked rung 0013 for "Deletion" ... has it actually been deleted? ... no, not yet because we haven't done the "Test" and the "Assemble" steps for our edits ... so IF (big IF) we were to go down and look at rung 0013, we'd definitely see a row of "D" characters marking the rung ... but we're fat, dumb, and happy ... we don't go look ...

the sun is shining ... the birds are singing ... life is lovely ...

ok ... it's getting late and we're through programming for today ... we save the program like good little boys and girls... we notice that as we head out of the plant everything is still working fine ...

the sun is shining ... the birds are singing ... life is lovely ...

three months pass by ... everything is still fine ... eventually we decide to do a little bit of programming ... we need to do this ONLINE to keep the rest of the plant running ... and the processor needs to stay in the REMOTE RUN mode ... no problem ... we've done things like this before ... we'll be REAL careful ...

we go to Ladder File #4 ... we decide to add in a couple of new rungs ... we put the new rungs in and we "Accept" them to send them over to the processor ... so far so good ... but the new rungs aren't being scanned yet ...

so now we do the next step and "Test" the rung edits ... we click the icon ... the friendly popup message says "blah, blah, blah - Are you sure you want to Test Edits?" ... well of course we're sure ... we've done this hundreds of times before ... it's just the next simple step in a well-rehearsed sequence of events ...

the sun is shining ... the birds are singing ... life is lovely ...

and now ... (imagine spooky music playing in the background) ... we ... click ... the ... "Yes" ... button ...

quick question: what just happened? ... answer: that "unknown" deletion that we mistakenly put in place three long months ago has suddenly just been brought to life ... specifically, the JSR on rung 0013 of Ladder File #2 is NOT being executed ... and more specifically, Ladder File #3 is NOT being scanned anymore ...

whoa! ... do you mean to tell me that when we "test the edits" in Ladder File #4, that we also activate any edits that exist in ALL of the program files? ...

oh, yeah ... welcome to the real world ...

back to our story ... so suddenly whatever is programmed in Ladder File #3 is NOT being scanned anymore ... gee, I hope that some DANGEROUS! output wasn't ON when we quit scanning the ladder ... because it's NOT going to go OFF the next time the operator pushes the "Stop" button ... instead it's going to stay in its last state ... that doesn't sound like a good thing now does it? ... (side line: that's one good reason why the PLC shouldn't be the only thing that controls an Emergency Stop function) ...

but remember, we're up in the control room ... we're not even aware of any problems with the machinery being controlled (or rather NOT being controlled) by Ladder File #3 ... that machinery is way on the other side of the plant ... as far as we know, everything is still fine ... the new rungs that we just programmed in are being scanned now ... and they're simmering along just fine ... we feel good ... so let's go ahead and do the next step ... we click the "Assemble" icon ...

the friendly popup message says: "Are you sure that you want to Assemble Edits?" ... heck yeah ... let's nail this thing down and go home ... and now ... (more spooky music) ... we ... click ... the ... "Yes" ... button ...

quick question: what just happened? ... answer: all traces of the JSR rung (number 0013 in Ladder File #2) are GONE ... but let's say that we don't even notice ... the stuff that we just programmed in is working fine ... so we save the program and close up for today ...

as we're heading out of the plant, we hear some commotion going on over by the "Ladder File #3" machinery ... hope those guys on night shift have fun with "their" little problem ... but as for us, well, we've had a good day working with Ladder File #4 ... we're out of here ...

end of story - for now ...

folks, when I demonstrate these particular concepts to my students, I can always spot the ones that are really "on the ball" ... they're the ones that literally turn pale ... but some guys just nod once and are ready to move on to the next lesson ... those are the ones that really scare me ...

anyway ... here's something that you should train yourself to look for ...

I liked the story Ron....
But What I don't believe is that even if your cursor is NOT on the edited rung to test the edits, how come it might test those edits? Yes, I am pretty sure that once you test all the edits then irrespective of your cursor pointing to - it will assemble all the tested edits when asked to do so..
Any comments - always welcome!!

Regards,
--Rahul Dave.

[Ron Beaufort]

Greetings R.Dave,



and welcome to the forum ...

Quote

I liked the story Ron....

thank you ...

Quote

But What I don't believe is that even if your cursor is NOT on the edited rung to test the edits, how come it might test those edits?

no offense intended, but I’m not 100% sure that I understand exactly what you’re saying ... so let me say it this way and see if you agree - or disagree ... then, if necessary, we can continue on from there ...



first of all, suppose that we’re working “ONLINE”; and in the “Remote Run” mode; and using RSLogix5 or RSLogix500; and we’re talking about edits which have already been “Accepted” (or “sent” to the processor) ...



now then ... when you “Test” edits, then ALL of the edits will be tested at one time ... regardless of where the cursor is positioned ... specifically, all “I” rungs WILL be executed ... and all “R” rungs will NOT be executed ... and all “D” rungs will NOT be executed ... and I repeat (just for clarity) under these conditions, it does NOT matter where the cursor is positioned, ALL edits (throughout the entire program) will be “tested” by the processor ...

Quote

Yes, I am pretty sure that once you test all the edits then irrespective of your cursor pointing to - it will assemble all the tested edits when asked to do so...

if I understand exactly what you meant to say here (and I think that I do), then this statement seems to be correct ... specifically, you do not get to “pick-and-choose” which edits WILL be “Assembled” and which ones will NOT be “Assembled” ... more specifically, “Assembling” is a “blanket” operation which covers the entire program at one time ...



and ... by the same token, you do not get to “pick-and-choose” which edits WILL be “Tested” and which ones will NOT be “Tested” ... more specifically, “Testing Edits” is another “blanket” operation which covers the entire program at one time ...



I apologize if I don’t fully understand exactly what you’re saying ... but it looks like you are drawing a distinction between the “range” of what parts of the program that “TESTING” operates on - and the “range” of what parts of the program that “ASSEMBLING” operates on ... and apparently you think that the position of the cursor plays some part in selecting these “ranges” ...



let me say this: there is NO difference between the “range” of TESTING and the “range” of ASSEMBLING ... specifically, they EACH operate on the entire program regardless of where the cursor is located ...



finally ... if I haven’t completely nailed these ideas down, then please post again and rephrase your comment/question ... quite possibly I’m just not understanding exactly what you meant ... statements that would make perfect sense in the context and “flow” of a spoken conversation are sometimes quite confusing when presented on the printed page ...

This post has been edited by Ron Beaufort: 17 February 2006 - 12:53 PM

[Pierre]

Ron Beaufort, on Feb 3 2006, 05:36 PM, said:

the sun is shining ... the birds are singing ... life is lovely ...

Thanks Ron what a nicely writen post.

Real life scenario.

[mellis]

First off, let me join in and thank Ron for another great post.

I am going to have to wait until I get back from RSTechEd and can get my hands on a test processor but I think I'm not in 100% agreement with everything Ron said.

Disclaimer #1 - I have a lot of faith in Ron and am prepared to eat my words. <g>
Disclaimer #2 - I haven't worked with a SLC recently, so I'm not going to comment on SLC behavior.

From my memory (last week) when I paste multiple rungs into a PLC-5, the only way I can get them all to accept together is to highlight all the rungs. I agree that when I test, all rungs that have been accepted will be processed, including rungs marked for deletion anywhere. But I am pretty sure that if I paste 5 rungs in and leave the cursor on just one rung, that when I accept I will only process that one rung and 4 rungs will still be marked for insert. I don't know if SLC works the same or not.

From my memory, (much longer then last week) when I paste multiple rungs into a ControlLogix, when I accept I will process all the rungs in that program. When I test, any rungs marked for deletion in that program will be gone. But rungs marked for deletion in a different program will be unaffected.

I think Ron nailed the cause of the problem. And I think AB PLCs are solid. But once in a blue moon you can run into an actual bug. So far it's only happened to me once. No one was hurt, no equipment was damaged, but it was dramatic, it was bizzare, and it was embarrassing.


Edit:
After re-reading what Ron said, I don't think we really disagree after all. My comments are on the differences in how rungs are accepted in PLC-5 and ControlLogix. Ron didn't really get very detailed about that step.

This post has been edited by mellis: 15 June 2006 - 09:21 PM

[Ron Beaufort]

Greetings mellis,

Quote

First off, let me join in and thank Ron for another great post.

thank you (all of you) for the kind compliments ...

Quote

... I think I'm not in 100% agreement with everything Ron said.

personally I think that we’re both on the same track ... but there might be some slight misunderstanding due to interpretation ... I’ll try to nail things down in this post ...

Quote

I haven't worked with a SLC recently, so I'm not going to comment on SLC behavior.

this thread was specifically about the SLC and about RSLogix500 ... BUT ... everything that I’ve already posted about the SLC and RSLogix500 should also apply directly to the PLC-5 platform and RSLogix5 software too ...

Quote

From my memory (last week) when I paste multiple rungs into a PLC-5, the only way I can get them all to accept together is to highlight all the rungs.

that’s completely true ... and if something that I posted earlier seems to contradict that, then I’m sorry for not having been more specific ... let me try to nail it down ...



suppose that we’re working with either RSLogix5 or with RSLogix500 ... suppose that our processor is in the Remote Run mode ... suppose that we are online (communicating) with the processor ... suppose that we enter in a series of several new rungs ... each rung will initially be marked with a series of lower-case (“little letter”) e’s ... the e’s stand for “edit” ... the fact that the letters are lower-case (and not capital letters) indicates that the rung edits are NOT currently in the processor ... specifically, the rung edits presently exist only in the RAM of our programming computer ...



brief side trip: at this point, we can “verify” the rungs if we want to ... this step will simply check the rungs to make sure that they don’t contain any obvious syntax errors ... I usually skip this extra “verification” step ... the reason is that the “accepting” step which comes up next in our discussion will automatically perform exactly the same “verification” syntax test for me ...



now suppose that we’re finally ready to send our new rungs to the processor ... we can do this in two ways ... we can send each rung individually (one-rung-at-a-time) ... or we can send them all at once ...



to send just one rung, we first click on the rung’s number (in the left column) and then click the “big-E-with-a-check-mark” icon ... (note that “right-click” menu choices are available for this and for most of the following actions) ... the tool-tip for this particular icon says “Accept Current Rung Edits” ... the key word for today’s discussion is “CURRENT” ... this word literally means “the particular rung that you CURRENTLY have selected” ... in other words, if you haven’t clicked on a rung number (and thus marked it with a big red box) then you do NOT have a rung “currently” selected ... that’s why the “big-E-with-a-check-mark” icon is “grayed-out” when no rung numbers are marked ... specifically, you can’t “send” or “accept” a rung unless you’ve explicitly nailed down exactly which rung you want to send ...



now suppose that we want to send/accept more than one rung at one time ... again we MUST mark the rung numbers to specify exactly which rungs that we want to accept/send ... but (as mellis correctly says) we certainly CAN send more than one ... we can use the common Windows trick of “Control-clicking” to select multiple specific rungs ... or we can use the other common Windows trick of “Shift-clicking” to select a continuous start-to-finish range of rungs ... now once the rungs have been selected (highlighted with the big red boxes) then we’re finally ready to “accept” (or in other words “send”) them over to the processor ...



and now that the rungs have been “accepted/sent” to the processor, we’re ready for the next steps which I’ve already detailed in the previous posts ...



more from mellis:

Quote

I agree that when I test, all rungs that have been accepted will be processed, including rungs marked for deletion anywhere.

yes, we’re in complete agreement there ... as I said earlier “testing” edits is a “blanket” operation ...

Quote

But I am pretty sure that if I paste 5 rungs in and leave the cursor on just one rung, that when I accept I will only process that one rung and 4 rungs will still be marked for insert.

yes, you’re completely correct ... and after carefully re-reading what I’ve already posted, I don’t see anything that seems to contradict that statement ... but again, if somehow I’ve been ambiguous, I apologize ... hopefully the extra detail in this post will make everything more clear ...

Quote

I don't know if SLC works the same or not.

yes ... the PLC-5 and the SLC platforms both work the same way for the operations that we’re discussing here ... (note: of course we’re talking about only the SLC processors (SLC-5/03 and up) which do allow “online” edits ... the smaller units do not ...



so let me try to nail down the “big ticket” ideas of this thread ... and these are specifically for RSLogix5 and for RSLogix500 ...



(1) “Accepting” rungs is NOT a “blanket” type operation ... specifically, if you want to accept/send more than one rung at a time, you can do that ... but you MUST select all of the rungs that you want to operate on ...



(2) “Testing” edits IS a “blanket” type operation ... specifically, you will “test” ALL of the accepted rung edits in the processor at the same time ... more specifically, you can NOT select some rung edits to be “tested” and other rung edits to be ignored ...



(3) “Assembling” edits IS a “blanket” type operation ... specifically, you will “assemble” ALL of the accepted/tested rung edits in the processor at the same time ... more specifically, you can NOT select some rung edits to be “assembled” and other rung edits to be left “unassembled” ...

Quote

From my memory, (much longer then last week) when I paste multiple rungs into a ControlLogix, when I accept I will process all the rungs in that program.

that depends ... we haven’t been discussing ControlLogix and RSLogix5000 in this thread ... but here’s a BRIEF (probably too brief) rundown on that subject ... (and please note that different versions of RSLogix5000 might be slightly different) ...



in RSLogix5000 there is an icon for “Accept Pending RUNG Edits” ... this particular operation will accept/send only one rung at a time ... and it works on the specific rung that your cursor is located on ... (note that with RSLogix5000 the cursor can be located anywhere on the “selected” rung ... specifically, the cursor does not have to be located on the rung number as it must with RSLogix5 and with RSLogix500) ...



once again, the “Accept Pending Rung Edits” will accept/send only one rung at a time ...



going further ...



in RSLogix5000 there is ALSO another (related) icon for “Accept Pending PROGRAM Edits” ... this particular operation will accept/send ALL of the edited rungs in the entire “Program” at one time ... when you click this icon, it opens a window which informs you of which routines within that “program” are about to be affected by the “accept” procedure ...



I think that this particular icon (and its “blanket” accept operation) is the one that mellis is describing ... certainly it’s the one that most programmers are more familiar with - and the one which is much more commonly used ...

Quote

When I test, any rungs marked for deletion in that program will be gone. But rungs marked for deletion in a different program will be unaffected.

well, not quite ... during the “test” step, the “marked-for-deletion” rungs won’t actually be “gone” ... more specifically they will simply become “unscanned” ... in other words, the processor will no longer execute the logic on those “marked-for-deletion” rungs ... the rungs won’t actually be “gone” until the “Assemble” step is done ... (and yes, I know that it sounds weird to use the word “assemble” to make something “go away” ... but I didn’t come up with these terms, folks) ...



a final (at least for now) note on ControlLogix (in the context of this discussion) ... the meaning of the word “program” as used in ControlLogix differs considerably from the meaning of the same word “program” as used in the PLC-5 and SLC platforms ... this can be quite confusing - but unfortunately I don’t have time to adequately cover the subject right now ...

Quote

After re-reading what Ron said, I don't think we really disagree after all. My comments are on the differences in how rungs are accepted in PLC-5 and ControlLogix. Ron didn't really get very detailed about that step.

absolutely no disagreement ... and I specifically targeted the SLC platform when responding to this thread ... again I apologize if I didn’t make it perfectly clear that I was NOT intending to include the ControlLogix platform in the discussion at all ... but ... if there’s enough interest in it, maybe someday I’ll tackle ControlLogix step-by-step too ... as in many (most?) things, ControlLogix is indeed a horse of a different color ...



I hope this helps ... and thanks, mellis, for bringing the topic back up for this further discussion ...