Do you use Sub-Routines?

On another thread, the subject of subroutines came up.

I do not use them myself. I spoke with everal others that do not either.

Perhaps it is a regional thing, or maybe dependant on some industries.

Collectively, we have a lot of large machines and conveyors, 100-300 I/O running without them.

What do you do? Are they neccessary in every application?

Yes, on almost every job that is more than 20 rungs long. At the very least there is an output subroutine. Often there is a usually a start up subroutine as well as a fault routine.

Are they necessary in every application? No. But why force a technician to hunt through 600 rungs to find the twenty rungs that control a pick and place robot at one carousel station?

However, IMO, its not something to get overly passionate about.

Always.
Different functions, different subs.
Especially when using the same subroutine on multiple valves, crane axes, etc.

Unless its a handfull of rungs (like in a smart relay), absolutely always.

All the time!!!

Subroutines are a very useful tool. Learn how to use them wisely.
If you are a Siemens programmer you couldn't do much without them.

All the time as well. I couldn't even be competitive without using sub-routines, not to mention that my programs are much more readable (as all programs are) if they are divided up into logical components.

I never use sub routines. My preferred PLC is Omron and the CJ/CS series with CX-Programmer offer "sections". Each section can be named. I have my first section as the set up section - setting up any parameters for scaling, initialisation bits etc.

As most of the work is diesel generators, the second section is shut down alarms.

The third section is non shut down alarms.

The next section is warnings.

The next section is alarm handling using bit counters, compares, shut down bit, warning bit, alarm lights, alarm sounder.

The next section is screen handling - if there is a screen.

The next section is control and is generally very short.

The next section is fuel control.

The next section is communications.

The program sections are very easy to follow and reasonably brief. For example, if there is a shut down bit on in the alarm handling section, then go to the shut down alarm section to check on the actual alarm.

One can further break the program down into tasks. If a task is not turned on it is not scanned. Each task can then have many sections, as required. No need for sub routines really.

Rarely use jumps or interlocks either. Too hard for many to understand. I have to keep it really simple for others to diagnose.

Have started using FBs and have been roundly criticised by the engineer and had to go back and re-write it into "simple ladder logic".

I suspect that there are two main influences here:

1. The type of application, high speed applications tending away from subroutines, because the of the scantime overhead they may introduce.

2. The type of PLC. I would observe that the S7 and CLX guys are likely to be much more comfortable with them.

As an example of this, at one time I rarely used true subroutines, but after using CLX for some years, I find that when I do use an SLC class processor these days, I'm now quite happily using them.

1. The type of application, high speed applications tending away from subroutines, because the of the scantime overhead they may introduce.

2. The type of PLC. I would observe that the S7 and CLX guys are likely to be much more comfortable with them.

Click to expand...

Very true. Point 1 - I think that is partly why Omron introduced tasks - if they are not turned on they are not scanned, up to 16 of them.

I thought the European PLCs used tasks too????? Anyone????

Bob,

As a total thread hijack it is interesting that I have just spent a week doing some tidy up work on an interesting system I built a few years back

1.Two 800 kVA Mains Supplies each connected to two separate halves of a Board. With both Mains on the Bus Coupler between each half is OPEN.

2. Each half of the building is fed off one side of the Board. Total load up to about 1200VA

3. Each side has a 400kVA generator that can be attached.

4. Whenever a Mains is not connected, close the Bus Coupler.

Question....how many possible Breaker switching transitions are there?


Oh and yes...the thing is full of conditional routines in order to minimise scantime.

Philip,

It is fun sometimes. I would assume that each generator has an ACB as well - bit hard without one - and that if there is a power failure the bus coupler opens - or it is closed and the generators synch together across the coupler - or .....????

I had one in Sydney some years ago where I had to control 48 ACBs. These include 6 generators - 1 in the basement, 3 on level 26, 2 on level 54. The generators synchronised together through risers - pyrotenax - that go all the way up the building - and load share. Long analogue comm lines that caused all sorts of problems. Then there were 12 mains ACBs and many interconnecting ACBs. Some of the interconnectors were used for both mains and generator.

They were old NAB ACBs. I do not know if you are familiar with them but they were mongrels. Bounced the whole generator system off a sub one night because an auxiliary contact failed and the PLC system thought the mains breaker was open and it was not. Called the council and we could hear the guy puffing and cursing all the way up the 26 floors. He was lucky it was not the sub on level 54.

We were invited to re-hash the system here some time ago and declined due to the consultant that had been appointed. Other companies came in to quote and I understand one crowd spent 4 days in the switch rooms trying to get their heads around it.

Fortunately the hardware on this project was new, all new Merlin Gerin boards.

There are 4 Main MCB's, each with a supply that can be On or Off. Any sequence of events is possible.

Each supply can be in one of 2^2 = 4 states.

For each of these 4 supplies, there are 3 other supplies that can be in any of 4 states = 4^4 = 256 other possible states.

For any given state there are 256 *255 = 65,280 possible other states that can occur. Toss in the Bus Coupler for (my head started to hurt about now) and there are 65,280 *2 = 130,560 possible states the system could attempt to go to from any given starting point. Cool eh!

What I did was simplify it down into a sort of 9 state Karnaugh Map that had 24 generic transitions between them. The most challenging aspect is handling the MCB faults because the logic wants to chase it's tail unless you are very careful....the thing you are controlling is the very thing you are responding to.

The end result is very cool...any combination of supply restore or failure can be handled and the logic will always seek the maximum possible connected supply. It's kinda fun testing it though because the generator room is 200m and several swipe card doors away from the switchroom.

Toss in a Devicenet loadshedding system with 40 controlled nodes and it is fair to say I bit off a lot more than I expected to be chewing on.

Toss in a Devicenet loadshedding system with 40 controlled nodes and it is fair to say I bit off a lot more than I expected to be chewing on.

Click to expand...

I know what you mean. Had at least 1 load shed per floor (sometimes 5) over 68 floors. They were hard wired though. My boss did not trust PLCs. Sometimes wondered why he employed me. Got there in the end but it took 8 years. I finished up doing what I wanted to do.

I have honestly never tried to work out the combinations but tended to use an interlocking system - if this and not that do something else. One of the greatest traps is that ACBs do not like getting a close signal too close to an open signal. They just lock up - need a timer gap between open and close - I normally use 2 seconds unless the requirement is tight and then use about 3/4 second. Mechanical problem of course!!

Personally I tend NOT to use subroutines unless really necessary. I do however split my program into several parts to help maintenance and understanding, but these tend to be constantly scanned. I only use subroutines when I have some number crunching or messaging that only has to be run on requested occassions.

On a related note, when I am doing process control, and items have to stop quickly and accurately via the PLC, I like to ensure that the scan of the PLC is as consistent as possible, otherwise items can overrun if the scan goes up due to running a subroutine etc.

We do not have any subroutines. We have several fairly large assembly machines and conveyor systems. All of our pick and place robots have the program in the robot, not the plc. It all seems to work fine. This was the way it was set up when we still had engineers, which we don't anymore.

Del