Multiple main programs

Hi All,

I recently completed a project where I had a lot of duplication, there were 3 sub-systems with the same functionality, which all had to be tied into the same process. I did the routine for a single sub-system and afterwards copied/pasted the code, renaming alliances as necessary.

I realize that RSLogix 5000 compatible processors are capable of running multiple main programs simultaneously. What would be the best way to implement such a system in the case above and what are some advantages/disadvantages to using multiple main programs?

As far as I can seen, if I were to implement multiple main programs in my project, I would save the time on having to rename the alliances and the additional debugging from spelling mistakes...

Thanks in advance.

rroze002 said:

Hi All,

I recently completed a project where I had a lot of duplication, there were 3 sub-systems with the same functionality, which all had to be tied into the same process. I did the routine for a single sub-system and afterwards copied/pasted the code, renaming alliances as necessary.

I realize that RSLogix 5000 compatible processors are capable of running multiple main programs simultaneously. What would be the best way to implement such a system in the case above and what are some advantages/disadvantages to using multiple main programs?

As far as I can seen, if I were to implement multiple main programs in my project, I would save the time on having to rename the alliances and the additional debugging from spelling mistakes...

Thanks in advance.

Click to expand...

For something like this, you'd want to very carefully make your TagDatabase flexible enough to do this.
So, you might have a 2-dimensioned tag like MOTOR[x,y]
MOTOR[1,1] is Motor 1 on Machine 1
MOTOR[3,9] is Motor 9 on Machine 3

Your MOTORRUN routine would use the MOTOR[x,y] tag as an in/out tag, and, well, you'd just build calls to it.

Yes, you can multi-task (which is to say, have more than one continuous task), but only in the ControlLogix (I think), and not in the lower cost Compact Logix.

There are probably other ways to do this, but this is what comes to mind at first.

I'm getting to the point where if I have two of anything, I'll write AOI's and UDT's, right off the bat. It always saves time.

Multiple programs means modularity. If you do it right, then you can simply export your 1st program to a .L5X file, re-import it, change your program scoped tag aliasing and you're finished. No risk of typo's and testing/debugging is non-existent assuming you caught all the bugs in your first program. Much like your copy&paste method but now that you can export the entire program to a .L5X file you can build libraries of code that are easy to store and import for future use if needed.

If you use programed scoped tags within your programs, and alias them back to your controller scoped tags it becomes really easy to change your tag referencing while not losing any meaning.

Plus if you have to make changes and need to port them to your other program you can simply copy & paste the logic, and the alias will automatically update as you paste it into the other programs. Makes updates very very easy and low risk.

Plus, if you get into the right habits now on these smaller systems, you've got a great base for developing extremely large systems.

jd - I like working with array, but just not in a ladder program. I've been reading about different script type such as structured text which would be helpful in implementing more complicated operations. Is there a way to integrate structured text with ladder diagrams?

Also your AOI and UDT method sounds a lot like writing subroutines and calling them individually. Or is there something that I am missing?

Paully - if I want to alias the tags in my programs to physical I/O, should I just define the tags as controller scope or do you recommend creating program tags and then cross referencing with the controller tags?

I don't ever directly alias physical IO. I always create buffer/mapping routines.

For instance:

Program Tag: Motor

For Each Program, "Motor" would alias to a controller scoped tag:
"Motor_01"
"Motor_02"
"Motor_03"

Then I would buffer Motor_0x to the appropriate physical tag:

   Motor_01.Start        Physical Output

-----||-------------------( )---

This is exactly where Siemens S7 is way ahead of Rockwell with their Multiple Instances. I'd like to see this functionality implemented in AB PLCs as well.

Kind regards,

I'm with Jean Pierre on this one, Siemens lead the way in this respect. I believe that the AOI/UDT is the closest methodology available to Rockwell users.

I did a project a couple of years ago in S7 with 60 drives on profibus split in to 20 separate production lines for processing steel rod. If everything was hard coded with absolute addresses then I think I would still be there debugging. Many functions within the code were repeated - one function was called 40 times. If you need to modify the code, you only modify it in one place and not 40 times. If a customer tells you that one of the 20 lines behaves differently to the other 19 then you can tell them that it isn't a bug in the software.

Each function to be duplicated needs to be written with this in mind: Do not directly address anything within the block, always pass parameters as arguments or pointers.

Taking this approach to software has other advantages too. You can copy a function from one project to another secure in the knowledge that it will not over write tags or I/O used in other parts of the project.

Nick