Subroutine philosophy

I think single stepping would be the most important thing to add to PLS software to aid in troubleshooting. There are so many times I want to stop the PLC on one rung and it just isn't possible. The closest thing I have come to this is the stage programming in the AD PLCs. I can cause the program to stop processing rungs from within a stage just by putting an open contact on the rung the jump is on. Try pausing a for/next loop. I cannot do it. At least I have not found out how yet.

testsubject said:

I think single stepping would be the most important thing to add to PLS software to aid in troubleshooting.

Click to expand...

Yes, quite a useful thing, that. I also especially like Peter's suggestion of a call stack. This would make it so easy to find out 'whodunnit'. Thing is, I know it's already in there somewhere, probably in the SYSTEM area, it's just that A-B has yet to grant me access.

Conditional Subs

For my last several programs, I've programmed multi-station machines. I program a set of subroutines for each station, then a separate set for the system control that handles HMI and coordinates the stations to each other.

Each station has a Main routine that is scanned unconditionally. The Main calls states (based on integer state values) that execute steps in the program sequence for that station. Finally, there is a routine called Status that catches faults for that station, and updates status logic to the System Routine.

Advantage? For each station sequence, regardless of how long the sequence or how many subroutines are involved, only three subroutines per station- Main, one state and status - are scanned. Makes troubleshooting a breeze.

Now I'm working on making it modular so I can import it from program to program

TM

I would say the answer really lies in when did you learn how to program PLCs. Did you learn to program PLCs after you learned an object oriented language or did you learn to program PLCs first?

If I’m writing a program in a high level language, I would create a method to do something, how ever many calls that method makes to get it done doesn’t really matter (to an extent).

If I’m writing a program for a PLC I use subroutines only to break the program into logical sections, i.e. Main logic, Alarm logic, Analog logic, Communication Logic.

But then you said that the program was in Softlogix, so the answer is quite simple, are you creating a PLC program in Softlogix or are you creating a “high level language” program to run on a PLC?

Tark said:

(a.) I would say the answer really lies in when did you learn how to program PLCs. Did you learn to program PLCs after you learned an object oriented language or did you learn to program PLCs first?

(b.) ...are you creating a PLC program in Softlogix or are you creating a “high level language” program to run on a PLC?

Click to expand...

a. I learned assembly, machine code, PLCs, and BASIC more or less at the same time. However, the PLC at the time (A-B 1774) did not have subroutine capability.

b. The program is entirely in ladder logic.

Some people like to use conditional calls because that makes
programming easier for them. Other prefer all logic scanned
all the time and wouldn't dare to touch interrupts.
There is also another group who likes to tweak the last ounce
of performance from the system, often not because it's needed
but to be proud of themself.

I have to do my work fast and efficient so I keep on scanning
all logic where possible - just break it into logical blocks
for simple navigation and to give it some structure.

Why?
Because I don't want to own the machine after it's been
comissioned and given to customer, I don't want to explain
to someone over the phone that just because condition is true
it doesn't have to turn on the output because current file
might not be scanned, etc.

PLC scanning every single rung on every scan? Who cares....
If there is concern, get bigger PLC. Once this is impractical
and/or too expencive and if project does need short scan time,
no problem we'll do something about it WHEN problem arises.
Actually this is something I got used to in the old days while
writing programs in Pascal. Do the job and make it work.
The part that needs optimizing can be fixed with some inline
assembler and voila. Who wants to write the whole thing in
assembly?

I'm trying to make it simple for end user to get familiar
with machine in no time if possible. 99% of all logic structure
is repetition of few simple forms so they don't have to think
much about it after reading first few lines.

I do like more functional programming (and debugging) enviroment
and whole nine yards. But as a programmer I should be able to
create my own structures that system doesn't provide.

No single stepping? Write your own.
This PLC has no FOR NEXT...? Make you own.
Not sure if conditional calls are better than scan-all?
You get the choice, try and see what works for you.
That's what programming is all about.
If one was always better than another, there would be no choice.

My main thinks: Program speed, monitoring, x-referencibility.

1'stly PLC-program must be as fast as possible.
2'ndly maintenance must see as much as possible.
3'rdly even 'standard-fuctions' have used, every used variable bits must be on view in the x-ref list, even they are handled by bytes, words etc.
4'thly PLC-program must be as fast as possible.

Maintenance approach

Everyone has their own approach, so I'm not disparaging anyone else's methdology - just trumpeting my own

When I started using conditional subroutines, it wasn't for speed or exclusitivity- it was to ease troubleshooting. And the difference I explained to my maintenance guys boiled down to two questions :

Old question : "What output didn't turn on?"
New Question : "What was the machine supposed to do that it didn't?"

Now really, these are the same question, but it's a difference of approach. If Cylinder X is supposed to go up and didn't, the sparky, and even myself, would probably search for the output bit, and try to figure out what logic didn't execute.

In my fault programming, I make every fault for every commanded movement unique. I don't just say "X did not go up" I say "X did not go up during homing" or "X did not go up after getting parts". Since every routine is clearly labelled, you know not only what stopped, but where.

Lastly, if the program hangs for some "mystery reason", since only a handful of routines are active, I can trace down through a handful of logic to look for where it stalled, instead of hundreds of rungs.

I guess I advocate conditional subroutines for the reason some others hate them - troubleshooting. With a little planning and the extra work up front, they make it alot easier.

TM

Trumpet away, Tim!

TimothyMoulder said:

In my fault programming, I make every fault for every commanded movement unique. I don't just say "X did not go up" I say "X did not go up during homing" or "X did not go up after getting parts". Since every routine is clearly labelled, you know not only what stopped, but where.

Click to expand...

A man after my own heart...

beerchug

-Eric

Tim's concept is exactly like mine... except my "sub-routines" are integrated into the ladder.

My "flags" indicate which module, sub-module, sub-sub... etc, is active (or hung).

Hey, AB guys... can you edit Sub-Routines on-line, in run-time?

Hey, AB guys... can you edit Sub-Routines on-line, in run-time?

Click to expand...

most definitely, emphatically ... YES!

Gerry said:

most definitely, emphatically ... YES!

Click to expand...

And, depending on the processor, you can create new program files for the subroutines to go in while in run mode.

Thanks for all the replies

After twenty seven posts I see no consensus, just a lot of different, well-presented viewpoints. No surprise there. I've even picked up a few ideas to throw in the bag.

Doug-P said:

Terry,

Speed is not an issue for this Softlogix engine application.

I understand that ladder can do it all and that subroutines add a level of complexity. However, I gravitate toward the clarity (to me anyway) and compactness that they provide. Besides, if, down the road something needs to be tweaked the subroutine allows said tweaking to happen in one place for all rather than sifting through the program to find every instance to be changed.

Click to expand...

yeah... that's a big plus... imagine if the same logic was in 10 different places... instead of 1 adjustment.. you'd have a tylenol moment on your hands.. hahaha

Suprised to see this one pop back up, but since we're on the subject, my approach is alot like Terry's. In fact, I've used Terry's exact approach before.

The M90 controllers from Unitronics do not support subroutines, everything is in one ladder. So, to create a "subroutine structure", I start the ladder with a bank of logic that amounts to an "ON x GOTO" ...

If state = 0, jump to label State 0
If state = 1, jump to label State 1
If state = 2, jump to label State 2

...and so on and so forth. Each state ends with an unconditional jump to a status routine, followed by a jump to END. If more than one station is involved, instead of END, the last jump is to the routing logic of the next station, and repeat.

It is robust and efficient because only needed states are scanned. I generally use subroutines instead, when available, for clarity's sake - it's just easier on the eye than a single 1000-rung ladder, regardless of how well-commented it is. But the principle then is still the same.

TM