Logix 5000 Tasks, Programs, Routines

Woah, 1000 programs per task? I've never actually looked at that specification, but that's super encouraging. I have a project in mind that would replace about a dozen CompactLogix PLCs with a single GuardLogix. I was wondering about that limit but hadn't gotten far enough to even investigate it. It's good to know that it wouldn't be limited by the number of programs at least.
 
You should check the guide Rockwell put out as how they advise to group tasks. I believe now its advised to have a fast medium and slow scheduled task and continuous tasks are discouraged.
 
All of our tags are always global scope.

ALL ??? Always ?

For tags that communicate with the HMI -- sure.
For one-shots, timers, holding registers, pointers and other controls -- Why ?

When I have 4 "identical" systems, I'll create one program, and in that program have a whole bunch of program scoped tags that are aliased to controller-scoped tags. For example: Pump_Start local tag is aliased to Pump1_Start global tag. Again, one-shots bits and the like remain local scoped. And not just so that I don't clutter up (make it harder to find) things in the Controller tag list.

Then, once I've got everything how I want it, I create the same tag names in each program, but aliased to different global tags (in the Pump2 program, Pump_Start local is aliased to Pump2_Start, and so on).

What this means is, if I make a change to one routine in one program, I can copy the entire routine from Pump1, paste it into Pump2, and the logic solve the same way, only for the different set of global tags.

No search/replace (which you can't do online anyway). Simple blind delete the old and paste the new. If it doesn't compile, it's because the new code has a local tag/alias that hasn't been created yet. Export/Import will do that for you, but requires care to make sure you do everything right.

Makes managing changes easy, because I'm not having to make the same change in 4 places, get interrupted half-way through, and then try to remember where I left off. Or make some stupid typo in one of them.

Obviously naming conventions and UDTs help a lot in doing this. If "Pump" aliases the "Pump1" UDT, then "Pump" has the same structure.

Just a suggestion.
 
ALL ??? Always ?

...When I have 4 "identical" systems, I'll create one program, and in that program have a whole bunch of program scoped tags that are aliased to controller-scoped tags. For example: Pump_Start local tag is aliased to Pump1_Start global tag. Again, one-shots bits and the like remain local scoped. And not just so that I don't clutter up (make it harder to find) things in the Controller tag list.

Then, once I've got everything how I want it, I create the same tag names in each program, but aliased to different global tags (in the Pump2 program, Pump_Start local is aliased to Pump2_Start, and so on).

What this means is, if I make a change to one routine in one program, I can copy the entire routine from Pump1, paste it into Pump2, and the logic solve the same way, only for the different set of global tags.

And to build on that, if you copy ProgramA and paste it in and rename it as ProgramB you will find all of those locally scoped (Program) tags have already been created. No need to create them all over again. Just update the aliases to the proper I/O for that program. For identical type systems, it is a really slick feature.

But I understand the hesitation as you might want ProgramA to see tags in ProgramB. Or you need another PLC to be able to see tags in that program. That's where you start needing to get creative.

OG
 
And to build on that, if you copy ProgramA and paste it in and rename it as ProgramB you will find all of those locally scoped (Program) tags have already been created. No need to create them all over again. Just update the aliases to the proper I/O for that program. For identical type systems, it is a really slick feature.

But I understand the hesitation as you might want ProgramA to see tags in ProgramB. Or you need another PLC to be able to see tags in that program. That's where you start needing to get creative.

OG

Another PLC being able to read them is actually a supporting reason for program-scoping: like you said, naming consistency and so on.

Here's another trick:
Make an array of string at the controller scope, then have each program "register" its name into this array with a GSV. Could even make this array a member of a UDT with a capacity member to tell other controllers how many strings to expect. The other controller could then iterate this list with CIP data table reads while having knowledge the interior naming of each program, and then be able to collect data from a lot of different program entities.
 
Last edited:
As long as it is coded with no conflicts, you should be ok.

if you are unsure, then just make certain the JSR for each routine is in the main routine with no prerequisites (just a single rung with a JSR)
 

Similar Topics

Hi everyone, I hope this isn’t too much to ask?!? I hope no one minds my “new programmer” questions. Deep breath, here goes… I am having some...
Replies
2
Views
1,588
Hi, I'm trying to delete the tasks as shown in the picture attached, but I am not having success. I looked at some articles on this forum and...
Replies
25
Views
41,161
I am currently adding pide's to an existing RSLogix 5000 program (ver 13)for controlling our scrubbers. I am putting the pide's in a periodic...
Replies
18
Views
10,729
Does anyone know how to set the background colors of instuction blocks (TON, MOV, etc)?
Replies
1
Views
89
Hello all, I have a question in regards to RSlogix 5000. I am having issues with the program force closing when I try to make online edits. We...
Replies
0
Views
95
Back
Top Bottom