Forgive me...rookie question

[shoelesscraig]

Ok, so I've got a decent amount of experience working with Logix 5000, but I'm a little fuzzy on the details of something.

I know that Logix 500 processors scan top to bottom and then update outputs. I've got lots of experience there. I also know that the newer Logix 5000 processors do this differently, updating I/O differently.

The other day I ran into a program where someone had written 2 simple rungs. The first moved an integer (say 3 for example) to a DINT. The rung below that moved another integer (say 10 for example) to the same DINT. Both rungs were true, and the DINT had "10" in it. Basically, the last rung won. This is what I expect from a Logix 500 processor, but I didn't think that you could count on the "last rung wins" scenario in Logix 5000...?? So, I'm a little confused.

My guess is that maybe the ladders are still scanned the same way as in 500, top to bottom, and that its just the physical I/O that are updated throughout the scan, but I'm not sure. Can I still program using the "last rung wins" theory in 5000 when my rung is not dealing with physical inputs or outputs?

Somebody school me!

 

[Operaghost]

Nothing has changed for how the logic is scanned and when a tag updates. Last rung still wins.

For physical outputs, they are updated at the end of a task similar to how the 5/500 system work. But, they also update at a user defined timed interval.

For a remote module, the RPI is the number that matters.
There is a great graphic on page 141 of the following manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um001_-en-p.pdf

In that doc you will see that the biggest difference is actually when inputs update.

OG

 

[sthompson]

From my understanding, your comments are correct. You can use a Synchronous Copy (CPS) to move your Inputs to a DINT, and use them so your Input Status doesn't change during your PLC Scan. You can also use a CPS to update the Outputs at the end of your Scan.

Stu....

 

[Ken Roach]

Your understanding is largely correct: "...[T]he ladders are still scanned the same way as in 500, top to bottom, and that its just the physical I/O that are updated throughout the scan."

Outputs are updated from the tag database when the RPI value expires. This might be between instruction or even in the middle of a file instruction or FOR/NEXT loop. This is why techniques for data buffering, and the CPS instruction, exist.

Unlike in the SLC-500 controllers, communications is not just processed at the end of scan or at a SVC instruction.

If you ran a trend on that tag you described, you'd see "10" 99.99% of the time... but every once in a while the read would occur between those two rungs and you'd see "3". This has puzzled more than a few folks who overlooked that important difference between the Logix OS and the SLC/PLC operating systems.

 

[shoelesscraig]

Ok, Ken. So if there is the "possibility" that I will see the first rung win (even if its a long shot), then am I correct in thinking that I need to always program as if there is no "last rung wins" rule?

 

[lostcontrol]

I think that the last scan rule would still apply, the exception being where that same tag is being used. If it is being used in the same task, then it would be the last scan that worked.
However, if there was another task running in parallel, and the tag mentioned was being used in this task, then it would be possible that this value could use either result (this is what I think ken was referring to with his trend example).
The same could be said if an i/o attribute was referencing this tag.
At least this is my interpretation, happy to be corrected.

 

[rdrast]

Ok, Ken. So if there is the "possibility" that I will see the first rung win (even if its a long shot), then am I correct in thinking that I need to always program as if there is no "last rung wins" rule?

This case is only possible if the first MOV is going to a physical output, and it is updated before executing the next MOV rung.

If you are just dealing with an internal tag, its value is always defined, even though you might change it multiple times in logic.

I use a few TEMP_ variables for calculations, and do reuse them multiple times in a program... even in a single rung, but before I use them for another purpose, the results of the prior calculation are saved somewhere that isn't temporary.

Be aware on the Logix OS platforms, that if you do re-use temporary tags, create a different set of temporary tags for EACH and EVERY Program, and create them in the program scope.

 

[Ron Beaufort]

a possible source of much confusion ...

there's a POTENTIAL problem regarding that "flow chart" that my distinguished colleague Operaghost recommended back in post #2 – at least in the area of how the real-world Inputs and Outputs are updated ...

the tread starter asked about RSLogix5000 – but he didn't mention the specific hardware PLATFORM he's using ...

that same "flow chart" appears in many (most? – all?) manuals for COMPACT-Logix systems ... BUT ... it is almost completely INCORRECT for that hardware platform ... specifically, the "flow chart" only works for the CONTROL-Logix hardware platform – even though both platforms use RSLogix5000 ...

so ...

which hardware platform are you programming with RSLogix5000? ... one size answer does NOT fit all ... (at least in the area of real-world (physical) outputs ...

important point ... I realize that the potential "issues" I've raised here will NOT apply to the OP's question – since he wasn't asking about real-world (physical) inputs and outputs ... but ... the ensuing discussion has also brought up how real-world (physical) inputs and outputs are scanned – and so there's the possibility that someone is going to be very confused someday by what's being written here ...

let me just nail it down to this: do NOT apply that nifty "flow chart" to a COMPACT-Logix system ... the COMPACT-Logix platform doesn't work that way ...

now going further ...

I'm not trying to needlessly complicate this discussion – but there's another aspect of this "what gets scanned when?" question – which MIGHT apply to the OP's question ...

IF (big IF) you're working with Periodic or Event Tasks – and those tasks have the potential for altering the data that is being "moved" (or otherwise operated on) then you might want to read the discussion that starts here:

http://www.plctalk.net/qanda/showthread.php?p=376167&postcount=61

I specifically recommend that you take a look at the two simple tests that I posted in that thread ...

 

[Johnster]

Ok, Ken. So if there is the "possibility" that I will see the first rung win (even if its a long shot), then am I correct in thinking that I need to always program as if there is no "last rung wins" rule?

IMHO - yes.

I was under the impression that is is bad programming practice to depend on the 'last rung wins' rule- no matter what hardware you were using, or what the manuf. said. (due respect to the manuf. guys here)
- I wouldnt try it based on the fact that even if you had the sequences and scan times lined up properly now - chances are that down the road, someone (maybe you =) would mess with them and then you'd get that funny value once every couple scans...(...or a machine trip, or an open vent valve, or an inaccurate count....) Variance like that happens enough for mechanical reasons =)

-John

 

[shoelesscraig]

Thanks everyone for the responses.

Ron, actually, I wasn't really thinking about either Contrologix or Compactlogix specifically. I use both of them all the time, so I am interested in how both of them work.

Ok, so the flow chart works only for Contrologix...what about Compactlogix? Is there a flow chart I can look at for it? What is the difference about it?

And again, this is only for real world I/O, correct? As far as internal stuff goes, I can still depend on the last rung wins rule. (Of course keeping in mind the periodic task thing)

 

[brucechase]

OK, just piling on here since my question is very similar. I do program with the last rung wins mentality since I have hundreds of SLCs. I am also getting into the contrologix world (not compactlogix) and wondering if the following attachment would actually work - all of the time. It definately works in my SLC (and has for 12 years), but if I convert to RS5000, then I am concerned.

The rungs are part of a long series in which I look at the lowest queue size and fill the lanes with the lowest number first (hence the last out wins). Any thoughts?

 

[OkiePC]

Bruce, that will work fine in the Logix5000 world as long as that tag is not being used by any other task or routine that might interrupt it.

When in doubt, buffer to a program scope tag. Just copy the value ahead of your existing logic, and copy it to the controller tag after the existing logic.

That way, if any other programs might interrupt this one and make use of an interim value that isn't meant to stick, they will only see the old value until the task that updates it is complete, and executes its move to overwrite it.