Logix 5000 Tasks, Programs, Routines

[AMarks95]

Since I've started with PLCs all of the routines have always been under the "MainProgram" folder. Would love to organize things further into sub-systems, but not sure of the implications for functionality, etc.

For instance, let's say I have 4 sets of 3 pumps that operate independently, but controlled by the same PLC. Typically, we'd have a routine for "Pump_Set_1", "Pump_Set_2", etc. all under the MainProgram folder.

Instead, what if I make 4 programs, one for each set of pumps, and add those programs to the task's program schedule? Would there be any real difference? The programmer in me says it shouldn't matter, but my experience with AB tells me it might.

Any insights are much appreciated.
TIA

[parky]

No essentially, the only time it would really make a difference is the order you call them in but even then it would not make any difference unless you are relying on things like timed interrupts. AB is a bit different as I believe that the update of the I/O is asynchronous which means inputs & outputs can be updated during the scan of the program where many others only update real I/O before or after program scan, but with the exception of requiring high speed I/O update then it will not make any difference.

[joseph_e2]

Only caveat I can think of is if any of the programs need to know what's going on in any of the other programs. If they do, you'll have to use global controller-scoped tags for the interface. Other stuff can be kept local to each program.

[JeremyM]

Originally Posted by joseph_e2

Only caveat I can think of is if any of the programs need to know what's going on in any of the other programs. If they do, you'll have to use global controller-scoped tags for the interface. Other stuff can be kept local to each program.

You can just use public parameters.

[joseph_e2]

Originally Posted by JeremyM

You can just use public parameters.

I'll have to look into that. It would have made some things a lot easier for me...

[AMarks95]

Originally Posted by joseph_e2

Only caveat I can think of is if any of the programs need to know what's going on in any of the other programs. If they do, you'll have to use global controller-scoped tags for the interface. Other stuff can be kept local to each program.

All of our tags are always global scope.

[Operaghost]

I think it is a very good idea. That is sort of the intention with Programs. I would sometimes refer to them like folders. Create a folder for a piece of equipment and put all the logic and tags you need for that equipment all in one place neatly separated from the other equipment.

A benefit to Program scoped tags would be that you could create a tag called Start (for example). That Start tag would be unique to that program. I know not everyone likes aliases, but you could alias that tag to the actual digital input tag used to start that equipment.

When you move to a different program, that Start tag doesn't exist. You could actually create a new tag in the other program and also call it Start, but alias it to a different digital input.

So when you have similar/identical pieces of equipment you could actually copy that entire program and paste it as a whole new program and then just update the aliases with the proper inputs and outputs for the other piece of equipment.

As for making that information available to other programs, you could always create a controller scoped alias to the particular tags you want visible to the other programs. Newer versions have parameters which are sort of like program scoped tags, but you can make them visible to other programs. It's a nice feature but sort of convoluted at first.

But, even if you don't use Program scoped tags and stick with Controller tags, Programs are still a really good idea. Like some of the comments here, we almost exclusively use Controller tags.

OG

[AMarks95]

Originally Posted by parky

No essentially, the only time it would really make a difference is the order you call them in but even then it would not make any difference unless you are relying on things like timed interrupts. AB is a bit different as I believe that the update of the I/O is asynchronous which means inputs & outputs can be updated during the scan of the program where many others only update real I/O before or after program scan, but with the exception of requiring high speed I/O update then it will not make any difference.

Does an "unscheduled" program mean that it's not being called?

EDIT: looks like that's the case: http://www.plctalk.net/qanda/showthread.php?t=78378

[Operaghost]

Correct. Unscheduled programs are not scanned.

OG

[AMarks95]

Originally Posted by Operaghost

Correct. Unscheduled programs are not scanned.

OG

How about an inhibited task? Same thing?

[JeremyM]

Originally Posted by AMarks95

How about an inhibited task? Same thing?

Yes.

[cardosocea]

I'd look at the number of programs limit... but also whether the logic is repeated or not and choose accordingly. Programs seem too large of an organization unit to manage a pump.

Originally Posted by JeremyM

You can just use public parameters.

Can he modify these online?

[JeremyM]

Originally Posted by cardosocea

I'd look at the number of programs limit... but also whether the logic is repeated or not and choose accordingly. Programs seem too large of an organization unit to manage a pump.

IMO, it's a massive improvement over blobs and blobs of controller-scoped tags that are constantly renamed or added - interlocks, permissives, alarms, and so on - why not just rename a program and maintain common naming within the local scope?

Can he modify these online?

No, but one can create a public parameter of the same type and update the logic to reference it.

[cardosocea]

Originally Posted by JeremyM

IMO, it's a massive improvement over blobs and blobs of controller-scoped tags that are constantly renamed or added - interlocks, permissives, alarms, and so on - why not just rename a program and maintain common naming within the local scope?

As I remember, there's a limit on number of programs... a pump seems too small of an oject to take up a program. That was my comment.



As for segregation, it's pretty good.

Originally Posted by JeremyM

No, but one can create a public parameter of the same type and update the logic to reference it.

Thus increasing dead code and confusion.

[Operaghost]

Program limit has bumped up twice over the years.

• The limit prior to version 15 was 32 per task
• The limit from version 15 - 23 was 100 per task
• The limit from version 24 and newer is 1,000 per task

There really isn't much overhead involved in using a program. But there is some certainly. Not all that much different than creating a subroutine.

OG