documenting with compact logixs

Hello.



I am in my first compact logix program. I am used to RS500. My typical program has 60-80 rungs. I like to document in 500 with a Title at the top of each change in logic. This comes out highlighted in green then the rung explanations that follow are high lighted in yellow. This allows anyone to easily follow the logic. It also prints up on separate pages like page 1 is close logic. Page 2 is open logic, ETC.



It appears I cannot do this in 5000. I can do rung comments but not titles. Is the only way to create actual sub-routines for open, close, ETC?



My only purpose is to make reviewing and troubleshooting the ladder program easy to read and follow. There are no scan time issues. Thanks in advance for any help



.

Hi

I sometimes use a rung with a single NOP instruction and comment a section of logic there. I don't think there's a way to do it as you are used to with RSLogix 500.

**** Section comment here ****
!--------------------------------[NOP]---!

Rest of logic here.

Tools -> Options -> Ladder Editor -> Display check "Show Routine Descriptions".

Right Click your subroutine -> Properties enter your description of your subroutine, it will now appear at the top of the logic.

g.robert said:

...and was trying to avoid that.

Click to expand...

Why?

Subroutines add useful structure your program.

No doubt....I can't stand programs that are junked together in one routine.

Why? Subroutines add useful structure your program.

Click to expand...

Lack of experience or requirements to do so. All my previous programs consist of around 25-70 rungs max. I also refer to my existing programs for several customers that usually require minimal changes so I never try anything new unless I am forced to.

No doubt....I can't stand programs that are junked together in one routine.

Click to expand...

Before you condemn me too soon I have attached a sample of how my typical program would print and read out. I try to fully document what is happening and I think you will find the presentation anything BUT "junked together ".
I guess my primary concern with subroutines is that I never considered or wanted them to be scanned conditionally with the logic I have. I guess I could create subroutines that are scanned every time by simply adding JMP at the end of each sub like a cascade then back to the main. Is that the way to handle it?

No, you simply break program logic into logical sections, put one in each subroutine, then from the main routine, you JSR to each in series. No return statements are needed either.

Personally I think it would be wise to get into the habbit of using subroutines, either a new project or job will come along and suddenly you're dealing with 1000 lines of code. Subroutines make life very easy.

Robert, what I will typically do is break my program into subs based on either function or zone. I try to break each function down to something that can be described in a few rungs. As a general rule of thumb if a function can't be described in 20 rungs or less it is not broken down enough. Thats not a hard and fast rule. Common sense still should be used. My main routine usually will consist of just JSRs.

A typical small program might have the following subroutines:
INITIALIZE
ANALOG_SCALING
AUTO_CYCLE
MAN_CYCLE
OUTPUTS

The main routine contains unconditonal JSRs to call the subroutines. Only the INITIALIZE subroutine is conditional, it's called on first scan.

Kudos goes to you for using the page titles in RSLogix 500. But page titles were not inteneded for sectionalizing logic but they can be really usefull when using the advanced diagnostics tools of RSLogix500. Our esteemed colleague Ron Beaufort has a really good write up on using page titles and advanced diagnostics in here somewhere.

edit: try this http://www.plctalk.net/qanda/showpost.php?p=113351&postcount=12

Thanks for the reply. RS5000 will force me on this project to use subroutines to avoid "junked together in one routine" results. I will likely start using them for future programs I am forced to start from scratch on in 500. I know mine and my companies limitations so I assure you we will NOT be involved in any "5000 lines of code" or even 100 rungs type programs.

I may be off here but I am talking about common LLR containing typically <30 rungs. I allways break these up into easy to understand "modes" as shown in the original attachment. Would you typically use subroutines on a LLR containing <30 rungs of logic?

I just saw Alex's reply. That makes 100% sense. I guess I have been afraid of the "unknown".

g.robert said:

Lack of experience or requirements to do so. All my previous programs consist of around 25-70 rungs max. I also refer to my existing programs for several customers that usually require minimal changes so I never try anything new unless I am forced to.


Before you condemn me too soon I have attached a sample of how my typical program would print and read out. I try to fully document what is happening and I think you will find the presentation anything BUT "junked together ".
I guess my primary concern with subroutines is that I never considered or wanted them to be scanned conditionally with the logic I have. I guess I could create subroutines that are scanned every time by simply adding JMP at the end of each sub like a cascade then back to the main. Is that the way to handle it?

Click to expand...

Robert,

I wasn't intending to offend you with the 'junked together' comment. That was not directed at you but in general terms, it is very hard to debug a program when everything is lumped together in a flat file. Even though your PDF only showed a few lines, one thing that Alaric referenced, that immediate comes to mind of deserving its own routine is the SCP command. Typically, I will put all Scaling and Block Transfers that have to do with reading Analog signals into their own routine. Then, I don't have to hunt through the program to understand the engineering units being used for a particular Analog I/O point. It's all together and easy to reference.

Subroutines aren't necessarily just to break up chunks of code into a manageable size, but also good for organizing common functions. I'll typically have a scaling subroutine, alarm subroutine, action subroutine, SFC subroutines (I program in Grafcet where I can) based on the area of the machine, manual function subroutine, and so on. Some of these routines may have only a few rungs, but it still logicially delineates common functions and makes it easier to troubleshoot.

Originally posted by robertmee:

Some of these routines may have only a few rungs, but it still logicially delineates common functions and makes it easier to troubleshoot.

Click to expand...

...right up until it's not easier anymore. This concept can be taken too far. Since you can't truly tree the subroutine structure in Logix500 a significant number of subroutines can actually be more confusing. Even with Logix5K you can only go three levels deep assuming you use different periodic tasks.

Granted, there are things you can do with structured subroutine naming. But I have never seen the need to make 5 routines with 5 rungs a piece that perform very similar functions if those rungs can be incorporated with the other logic they are related to. Unless, that is, you are going to actually call them as multiple instances of the same routine.

Keith

No offense taken robertmee (not much anyway)

I truly want to deliver the best product I can. This includes being user friendly for anyone that has to follow my tracks. I am not a PLC programmer. I am a licensed master electrician that is an "expert" in motor controls. I used to do it all with relay logic (I'm not that old, is 43 that old?). We moved up a little to the Moeller smart relays when the times called for it. Then it was an easy jump to PLC. I got my first advice on starting with PLCs here years ago. So now PLCs are a tool I use in my craft. I am aware and comfortable with where I sit (lower end) in the pecking order of PLC programming. I appreciate everyone's advice.

kamenges said:

...right up until it's not easier anymore. This concept can be taken too far. Since you can't truly tree the subroutine structure in Logix500 a significant number of subroutines can actually be more confusing. Even with Logix5K you can only go three levels deep assuming you use different periodic tasks.

Granted, there are things you can do with structured subroutine naming. But I have never seen the need to make 5 routines with 5 rungs a piece that perform very similar functions if those rungs can be incorporated with the other logic they are related to. Unless, that is, you are going to actually call them as multiple instances of the same routine.

Keith

Click to expand...

Certainly, common sense comes into play. If they perform similar functions then yes, they could be in the same routine. Let's say for example, I have 10 exhaust fans to control. Then obviously, I'm not going to make 10 routines to turn on 10 simple devices. They'll be in one. However, contrarily, If I have ten batching tanks, then I will have 10 subroutines for each tank as the controls for these will be more complex.