Using subroutines

Hi to all,
I have been using Allen Bradley RsLogix 500 software for over 12 years in which, when I change or write programs, I kind of hack at them to get my results. I would like to come up with a way that is quicker. I am trying subroutines which make programs more clearly to me in organization and more easy to fallow. I am just looking for a better way to program ladder logix. Am I on the right path or is there a better way to program more clearly? Thank you all for your help.

every person has his own way of doing things.

the simplest way to do code i've found is to divide it into components.

a 6 station machine would have 8 subroutines - one for each station. each has ist own files.

for example.
ladder 2 - main program - power up logic, auto/manual logic
ladder 3 - manual controls
ladder 4,5,6,7,?? - fault logic

ladder 11 - station 1 logic - files b13,t14,c15,r16,n17
ladder 12 - station 2 logic - files b23,t24,c25,r26,n27
ladder 13 - station 3 logic - files b33,t34,c35,r36,n37

i think you get the point.
we have done 36 stations like this, but the files got a little complicated.

write / type the machine sequence out on paper.
expand it little by little while you try to think of what the machine is doing in slow motion.
keep expanding until you can add sensors and outputs.

keep things in order.

the fault logic files has the logic for each station.

if each station has the same operation, write one file, save the logic to a library file, and insert the library file - editing the addresses.

for this example, i would have designated slots for each station i/o to make it simpler to write (if you get to design it).
regards,
james

Thank you very much for your help James

Breaking things up into well defined subroutines does help, but that is definitely just one of many things that will affect code robustness, readability.
James gives some good guidance.
I am a big fan of figuring out as much on paper as possible before you start coding. If you just start writing code without having a good plan, that is when it becomes a mess. I typically use excel for this. In each row I type in a written explanation of what that network should do. A flow chart is just as good or better, but tends to slow me down. I will often start my ladder programming by going through and simply typing in the comments for each rung first prior to even writing the code.
If your process is very sequential, you will want to work how you wish to handle the sequencing. You will want to keep in mind at all times not only how the machine will function when things go right, but how it should operate when things don't go right. The worst programs are the ones that did not have good consideration for recovery.
You also want to work out how you wish to handle switching between Auto and Manual modes. It is typical to have a subroutine dedicated to outputs. It is (in my opinion anyhow) good practice to only reference your physical outputs here and only here, and in only one spot. You can interlock your outputs here if for instance you have a double solenoid valve or reversing starter. You can have an Auto branch and a Manual branch and a separate set of control bits for Auto and Manual.

Being consistent also helps. Especially with naming conventions. Try not to be ambiguous. An example of this is in many programs you will see a contact labeled or commented “estop”. Does it mean the machine estop is in, that the estop relay needs to be reset, or that in fact it is NOT in estop and that "ON" means OK? Comments go a long way here.


James also points out good practice in regards to grouping your data. This is where thinking things out ahead of time really helps. If you can group your data in a consistent and organized fashion it can save you a ton of time in searching and may also have huge benefits in copy and paste situations.
It is my feeling that every minute you spend beforehand working things out and organizing you will get back several times when it comes time to start both writing and debugging your program.
Becoming less mouse reliant and making an effort to learn and set up your hotkeys will also reap huge benefits in time saving as well.
Good luck and have fun!

Not sure where or when I started doing this but I tend to create my control narrative as an outline.

I try to break things down as process functions and relate them to the system's sub-assemblies.

An example would be a discharger.

I would have a routine for the manual functions, auto functions,a function for the conveyor motor, a function for each flow aid... etc.

This allows me to add and remove things as the design changes. I also like to group my inputs/outputs for a given machine function together. This eases troubleshooting.

I will be the first to admit that this is not a perfect method but is the one that works best for me.

I think most would agree that programming is kind of an art and everyone has their own style. I like to organize my programs using subroutines and page titles. (Page titles are set in the same dialog as rung comments.) If you turn on "Integrate Advanced Diagnostics in Project Tree" [Tools menu > Options], links to the page titles will show up under the subroutines. So, I might create one subroutine for all sequences and have a page title at the start of each individual sequence--this lets me get to any point in the program very quickly.

I will often start my ladder programming by going through and simply typing in the comments for each rung first prior to even writing the code.

Click to expand...

Great method, Damian. I use that one also. Many beginners find it difficult because they really do not know what each rung should do. They are forced into using the old trial-and-mostly error method.

Lancie1 said:

Great method, Damian. I use that one also. Many beginners find it difficult because they really do not know what each rung should do. They are forced into using the old trial-and-mostly error method.

Click to expand...

I had an instructor ( my father ) drum a method in my head of how to always call it out as a If then statement.

If input 1 is on AND Input2 is off OR Input 3 is on then Output 1 is on.

He hammered that in when he gave me my first PLC in 1981 and I have used it ever since. Above is just a basic line , you can even describe timers, counters ect... using the same method. Having word and excel making a narritive is easy and for me really helps organize things and speed the actual code writing up.

I know that if I write it out I can make the code, ironically since I have started programing more in C+ this method has helped me there also. The syntax in C+ still kicks my butt though

Clay B. said:

He hammered that in when he gave me my first PLC in 1981 and I have used it ever since.

Click to expand...

Man that was 10 years before I was born. You have been doing this stuff a long time clay.

You rule.

Thank you all for your help. I appreciate it a lot.

The Plc Kid said:

Man that was 10 years before I was born. You have been doing this stuff a long time clay.

You rule.

Click to expand...

Yea I have probably let out a lot more smoke than you. But hey give it time and you will catch up....LOL