Programs in Studio 5k

Hey All

Trying to understand some non standard program hierarchy.

At least non standard to me

Typical my program flow i like this

Under Tasks
---------------------Main Program
---------------------------MAIN (call all sub Routines)
------------------------------------All sub routines here

What is the purpose and what would be an example of having addition programs inside of one project such as


---------------------Main Program
---------------------------MAIN (call all sub Routines)
------------------------------------All sub routines here

---------------------Main Program 2 ( goes and does something)
-------------------------Main (2)
-------------------------------Sub routines pertaining to main program 2



Why would you want multiple "programs" as AB calls it inside of one project?

Can Main 1 call main 2?

Does main two always execute?

Thanks in advance

Here is an abbreviated answer at Rockwell:
(Techconnect Access = Everyone, but you must register and log in)
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/54198

And here is a more thorough discussion I googled, and quickly scanned:
http://www.contactandcoil.com/rslogix-5000-tutorial/program-structure-high-level-program-layout/

why would you separate anything at all? you can put everything in one main routine... just like the old days

rscott9399 said:

Why would you want multiple "programs" as AB calls it inside of one project?

Click to expand...

Modularity, multi-function, a single project can do many things that aren't necessarily related. Easy to standardize a control structure and deploy.

Good read here

I come from batch and process, and I use programs to handle a single, relatively basic process. This basic process actually comes packed with features. State and Sequencing engine, fault handling, use of standardized routines, structure with UDTs and SCADA interfacing. This becomes my common building block.

Say I have a large process, in which I have identified 200 programs will be required for everything the system needs to do. Once I build the skeleton for the 1st program, I can easily generate the other 199 programs I will need and all my common control is programmed. I can then focus on the specific device control required for each program. This can also be expedited as often times programs are identical, less the physical devices they need to control. Tank 1, Tank 2, Tank 3, Tank 4 logic differences are only in the control devices. So Tank 1 easily ports to 2, 3, and 4 with little concern of copy/paste errors. Using alias tags here makes replication almost instant.

Tank 1, Valve 101 -- "InletValve"
Tank 2, Valve 201 -- "IneltValve"

The alias of "InletValve" keeps logic and tag references identical between programs and all you need to do is update the program alias tag. Realize you made a mistake? Fix it in Tank 1, just copy and paste the logic to 2, 3, and 4. Alias updates automatically.

Training is another benefit. I can train a maintenance team on understanding 1 program. Once they understand it, they can easily understand the other 199.

Also makes it stupid easy to expand in the future.

We use them more for changing scantimes. Some of the tasks don't need to run continuously and can just be scanned every 1000ms. Then some would be event tasks. For instance, if one process is not running we don't need to be scanning that task until a start event tells it to.


This wouldn't be just for a machine, we mainly use this on our backbone PLC's.