Programming styles.

Hi folks..Browsing around between here and MrPLC.com I came across a couple of posts that were simular in nature and got me to doing a little research at work.
http://forums.mrplc.com/index.php?showtopic=6878
http://www.plctalk.net/qanda/showthread.php?t=21028
Both these posts have to do with programming using subroutines or not using them, so I checked a buch of our PLC programs at work and found almost all of them {all but 1} were subroutined programs. The 1 that was not was only 48 rungs long. I guess I have never seen a program broken down or divided in any other way. Could some of ya'll post samples of the way you subdivide a program? PDF format would probably be best. It doesn't matter what the flavor {AB, Siemens, GE,Omron ,Mitsubishi etc etc}. Just stuff you feel safe to post, nothing propiatary or you could just fake it with junk rungs with some comments to give an idea of how you do it.Any and all would be welcome and appreaceated.

Thanks and later...Todd

For intellectual property reasons I can't post whole programs, so I'll share a general rule of thumb that I use:

I tend to use object oriented programmng methods. If there are more than 40 rungs in a subroutine, I haven't broken it down far enough. Obviously, this is not a hard and fast rule - but it serves me well as a general rule of thumb.

Here is an intersting article on using subroutines for structured programming.
http://www.manufacturing.net/ctl/article/CA188297?ref=nbcs

One more thing: In my experience the first place a maintenance tech is going to look when he goes online to troubleshoot something is the rung containing the output he expects to be turned on, so why not make it easy on him. I group outputs in address order in output subroutines. I include permissive bits which I think may help in troubleshooting right on the output rung - even if it is redundant.

I do not use sub-routines myself, time to post a poll on the subject.

regards.....kc

Having done a lot of computer programming with object oriented languages (and others), its hard not include some of those paradigms into ladder logic. Foremost, like Alaric, I make it as readable as possible for the maintenance electrician. He will search out the output that he believes is not working correctly and so its important to have as much information available as possible in the rung that energizes that output.

To assist the electrician and/or the operator, I put a tremendous amount of code into fault, warning, and general annunciating messages as possible. If an operator presses a PB, be it in Manual or Auto, if something doesn't move, there at least should be a message on the screen explaining why and what the machine is expecting next. My prime reason for doing so? I want the number of phones calls ("the machine just stopped working") in that one-year warranty period to be zero; no news is good news.

jstolaruk said:

If an operator presses a PB, be it in Manual or Auto, if something doesn't move, there at least should be a message on the screen explaining why and what the machine is expecting next.

Click to expand...

I agree. The PLC program "knows" exactly why that output is not on, and it is very obendient - so why not just give it the language to tell you about it. The only reason not to, and its not a very good one, is that sometimes around here at least, I don't have enough time to add that detail to a program. As I said, thats not a very good reason, but bit by bit I'm adding it.

Todd,


I have two examples (both by someone else) the 5000 is the best program I have seen, each subroutine was a part of the machine, starting from one end and working to the other. I talked to the programmer he said that this was his second one that he had wrote after he got his degree,to say the least, I am impressed, but as Alaric has pointed out it takes time

The second is SLC500, 179 rungs in lad 2, I know the code good, but its still hard to trouble shoot

Thanks to all

Hi Folks....Thanks for the replys and thanks Casey for the poll and Alaric for the link {printing it now for "the notebook"}and Geniusintraining for the PDFs.Just what I'm looking for.

Thanks and later...Todd

Hi Alaric

Object-orientation and PLCs? That takes me back. I remember a discussion over 20 years ago with a computer programmer who was trying to explain to me what this new things called OOP was. Similarly I was trying to explain to him what PLCs were all about. I was beginning to understand his concepts as far as say a valve or motor was concerned. But one thing we never did agree on was whether an 'object' could be as small as one bit. He felt this was a trivial example and should be ignored. To him 'objects' were much more complex items. I said that things like push-buttons were vital parts of the control process and all the attributes of a push button could be contained in a single bit: it would either be on or off and that was all. We sank a few beers trying to settle that one!

Regards

Ken

Ken M said:

Object-orientation and PLCs?

Click to expand...

I'd love to see some objects, classes and inheritance in some ladder.

Oh come on, Simon!

Even you must have inherited code from someone else at some time?
And did they object?
And we all know JvdCande runs classes.

So there you have it - all neatly encapsulated.

Ken

I'd love to see some objects, classes and inheritance in some ladder.

Click to expand...

I do this all the time with Omron and Device Net for explicit messaging. Perhaps the PLCs are set up quite differently.

Funny that I never was thinking that I was using sub-routines

After looking at the examples I saw I was



For me when its called all the time its a nice way to organise a structure, certainly not a sub. We are farr from Objects here.

My first rungs AND sections is ALWAYS called Watchdogs

Its often where the warez open and what I get to see first. Why its not working?

Pierre said...

Funny that I never was thinking that I was using sub-routines

After looking at the examples I saw I was

Click to expand...

That is probably what is confusing about this to start with, what someone considers a "subroutine" and what not.
Later...Todd

P.S. I don't know if anyone else has checked out the link that Alaric posted but it's pretty neat the way they structure the PLC program. What are some other ways to structure a program?

I have two examples (both by someone else) the 5000 is the best program I have seen, each subroutine was a part of the machine, starting from one end and working to the other.

Click to expand...

Ah ha!!! I do not call that sub routines but sections.

Similarly from Pierre - the program is sectionalised. This can also be done in a long ladder program if the programming software is not set up to be sectionalised. It is just good structure no matter how you do it.

I am accustomed to a sub routine being just that - a function of the PLC and not of the programming software. Turn the sub routine on with a bit and when the section of code has completed, turn it off till once agin required.

I can't post whole programs, but here is a generic example. I set up my programs in RS5000 like this.

Look at the task Drive Format, this is how I prefer it to be done.