Rungs vs Routines

I'm sure this has been covered before, but which is better? Should I have fewer routines with hundreds of rungs, or many routines with like 20 rungs each?

I'd say it depends on ur process.. We use a standard for programming at RSLogix and I think its pretty efficient.

It's like this:

Folder: Analog_Alarms
Routine: TI15001 (Example)
Routine: TI15002 (Example)
Routine: TI15003 (Example)

Folder Digital_Alarms
Routine: PISA15001 (Example)
Routine: PISA15002 (Example)
Routine: PISA15003 (Example)

Folder: Pumps
Routine: BB22001 (Example)
Routine: BB22002 (Example)
Routine: BB22003 (Example)

Folder: PIDs
Routine: TIC18002
Routine: TIC18002_PIDE (PIDE Function Block Routine)


This makes things pretty simple to maintenance people to understand and find problems

Monolithic programs are harder develop and harder to troubleshoot.

As a general rule I break a project down into parts that can be coded in 25 rungs or less. The parts are divided by what seems logical for the project - sometimes that is equipment zones, sometimes it is process steps or functions. Sometimes it is a combination of zone/function. In most cases I find that if I cannot code something in 25 rungs or less then I haven't broken it down enough - most functions in fact code in one to five rungs and the majority of subroutines are less than 10 rungs.

This is a general rule, not a hard and fast rule. There will sometimes be subroutines that contain more than 25 rungs. On example might be a subroutine that handles all alarms.

I usually code all writes to output addresses in a single subroutine however the logic that drives it may be elsewhere, so the output subroutine will be long for large IO systems. I do that because over the years of working with maintenance technicians I have observed that when they have a non-functioning actuator they usually go to the output bit first and then trace backwards through the program to identify what isn't working. By placing all outputs in an output subroutine they always have a single place to go to in order to begin troubleshooting instead of hunting through a large program.

I will sometimes duplicate interlocking logic on the output rungs solely for the purpose of making some input states visible just to make things easier on a maintenance tech. One example of this might be a valve that should be open during the fill state. The only logic needed to turn on an output to a valve might be

 State.Fill         Valve

----] [--------------( )---



A level switch might control the change of state so putting it on

the rung is redundant, but I might still code



 State.Fill  LevelSw   Valve

----] [-------] [-------( )---



just to make the input more visible to a maintenance tech.

Just do what seems to make the program the most manageable.

Alaric said:

I will sometimes duplicate interlocking logic on the output rungs solely for the purpose of making some input states visible just to make things easier on a maintenance tech. One example of this might be a valve that should be open during the fill state. The only logic needed to turn on an output to a valve might be

 State.Fill         Valve

----] [--------------( )---



A level switch might control the change of state so putting it on

the rung is redundant, but I might still code



 State.Fill  LevelSw   Valve

----] [-------] [-------( )---



just to make the input more visible to a maintenance tech.

Just do what seems to make the program the most manageable.

Click to expand...

I would never ever do this - in the example, duplicating the conditions for State.Fill on the rung that controls the output does not make the program easier to understand.

Next week you may decide to add another condition - State.Fill has another pre-requisite, e.g. Tank.Temperature < 50 deg....

You should only need to make 1 rung edit to achieve this, and you should not have it controlling State.Fill and the Valve output

Hello,

I am having a discussion at my place of work about a machine and changing the "style" of the logic. I have been programming for almost 8 years now and I have been in a lot of automotive plants. Without a doubt this area is a grey area at best.

What we are looking into here is replacing the logic on a fairly complex machine. One programmer is sold on the idea of the 5 Rung logic (safety, pre-condition, condition, output, motion complete.) The thing with this style is the high number of "rungs" in order to do the same job as a sequencer (software instruction not a device.) But....and it's a big but....it's easier for beginners to follow. This is key if your plants runs shift without a solid Programmer present all the time. It goes into the K.I.S.S theory (Keep It Simple Stupid). I can also say as a programmer that was trained in school (that was almost 100% allen-bradley equipped) that 5 rung is the first style I learned and it was in pneumatics class with a micrologix 1000.

On the other Hand as far as the question goes for rung vs sub-routine I have to say a better program is broken down into sub-routines. This is because a massive program that is one routine is overwhelming to follow. Now RSLogix 5 & 500 does allow for titles to be added to a rung which can help with breaking up a massive routine. This will only help with the option of advanced tree diagnostics box checked under "tools" and "options" (I believe). With this option "on" the titles added to the routines are now shown, once you expand the "+" beside the routine, all the titles and when clicked on bring you right to that rung.

So if you are not comfortable in re-writing an entire program, there are some options out there. I would however suggest to map out the sequence (flow chart can work) and get an idea of what order the program runs to avoid a slow scan cycle or sequences that get out of control. Hope this helps