Suggestions on writing a generic peice of code

Hi there
I am trying to write a generic peice of code for some compressor applications. I would like write a code which involves less repetition. For example here are some of my thoughts......

I want to take a basic I/O list probablly in the form of excel sheet
Create the tags from this excel sheet of type lets say generic data type (a user defined datatype which will have all the members i need to execute)


Problem i am facing in my head is as follows: Lets say i create two tags called "Oil Pressure" and "Speed" of type generic datatype. Although they both will have access to all the members of datatype generic but when it comes on shutdown logic then i have to write shutdown for each point or tag indivdually which involves a lot of repitition. I want to avoid this by writing say a generic shutdown logic and somehow mapped this points to that logic......Is there any other way of doing it.....your help will highly be appreciated....thanks in advance

How "generic" you can make PLC code depends on the brand and model of the processor and the capabilities of the programming software. Some newer PLC software, such as Rockwell Contrologix and Processlogix, make it easier to reuse pieces of code routine. For most of the older packages, you are limited to using indirect addressing and indexed addressing.

All of these code-reusing routines can save programming time and make the program smaller, but in many cases when problems occur they cause the machine maintenance personnel many headaches and lost time trying to figure out how the program works.

How generic the code can be depends also on your goals and the goals of the person who is paying for the work.

Lancie1 said:

How "generic" you can make PLC code depends on the brand and model of the processor and the capabilities of the programming software. Some newer PLC software, such as Rockwell Contrologix and Processlogix, make it easier to reuse pieces of code routine. For most of the older packages, you are limited to using indirect addressing and indexed addressing.

All of these code-reusing routines can save programming time and make the program smaller, but in many cases when problems occur they cause the machine maintenance personnel many headaches and lost time trying to figure out how the program works.

How generic the code can be depends also on your goals and the goals of the person who is paying for the work.

Click to expand...

If its Siemens it is, Control Logix can give you a headache in the scantime overhead if you use a routine as a sub routine.

PeterW said:

If its Siemens it is, Control Logix can give you a headache in the scantime overhead if you use a routine as a sub routine.

Click to expand...

I've replaced all of my older (Pre-Vers. 16) subroutines with AOI's in Logix, and have noticed a slight decrease in scan time, but nothing worth really worrying about. Even with one or two hundred parameterized JSR's, going to AOI's has cut a few milliseconds off of the scan.

But... I LOVE the AOI's in Logix over standard subs for the simple fact that you can acutally open up the logic online for a particular instance of the AOI call, and see the data only as it pertains to that instance... woot... now THAT is sweet.

OK, I like to learn, what's an AOI?

"AOI" = "Add On Instruction".

Rockwell finally put in some very good support in Release 16 of Logix 5000 to create your very own instructions, built up on parameters (data passed in/out), local (hidden) tags, and whatever logic you care to write.

AOI's are similar to subroutines, but not exactly, and can be versioned, have help associated with them (F1 type help), incorporate into the language toolbar, and can be source-protected (so end users cannot see the underlying code).

or as everyone else calls them 'user defined function blocks'.
(Only a few years overdue)

It sounds like you need reflection in your PLC program Be careful with how "generic" you're going for. Don't overcomplicate simple tasks by generalizing when it's not necessary. As Lancie pointed out, this will cause more headache than it's worth. Your well written program will be at least partially reusable. Don't over-engineer it before you know what you're going for. If you have to ask it may be too complicated. Remember KISS! To quote my own footer - "Design Simplicity cures engineered complexity".