ToddM said:
What are some other ways to structure a program?
The use of the term 'structure' in software design has become increasingly loose over the years. Nowadays I think people just use it to mean the general shape or feel of a program. Originally, 'structured software' tended to imply a definite process undertaken at the design stage, not the coding.
Usually it would start with some form of structured analysis. Several companies did CASE/CADE tools to help with this but most of these were too large and expensive to justify on a PLC application. The general approach would follow a 'tops-down design, bottom-up implementation' route. This can be done with a pencil and paper, or an expensive flowcharting and design software package. The key thing is the thinking and mental input applied to the problem.
If faced with the task of automating a petrochemical complex you would reasonably have to break it down in to smaller areas simply in order to understand the problem, never mind come up with the solution(s). The same can be applied to virtually any level of task. One key thing to bear in mind is that the sub-division should always be done in terms of the process to be controlled, not because of limits in the device which will be controlling it. It makes absolutely no sense to tear a single process apart just to get it to fit in to the size of files or data blocks your PLC happens to use. If you're doing this, you've jumped way ahead of the structured design phase and are starting to come up with answers before you've fixed the size of the problem. When you are doing the division and re-division of the problem, keep looking for repeating patterns of data or operations that may appear as you define what is required at each stage. These are going to form the building blocks for your program later on. Data items that may crop up again and again can be pumps, valves, motors etc. They will represent the 'objects' in your code. Operations may be error checking routines, alarm limit testing, interlocks etc. Only once you're certain you've fully analysed the structure of the problem should you begin to assemble the solution. You've done the 'tops-down' bit, now let's start on the 'bottoms-up'. First start coding the operation of your objects - create the logic pattern for a standard valve, pump, motor etc. Test it and prove it. Now create the interlock logic to say how these devices will interact - this pump always stops if the valve fails to open etc. Test it and prove it. Layer on top your functional and process requirements which request the devices to perform when you want them to, providing the lower level interlocks don't prohibit the action. And so on for communications tasks etc. etc.
For many experienced PLC programmers, they will have performed this type of work (perhaps unconsciously) some time ago, and will already have prepared a library of objects, routines, operations which they trust and use regularly over many projects. Each time they encounter a new problem they will tend to analyse it in terms of these existing routines and apply them accordingly. Normally this can produce great savings in coding, testing, commissioning etc. Occasionally it can however lead to issues in itself - "why won't this damned problem fit my solution!?!?". You always have to be prepared and willing to examine things from first principles and not just assume that the last project's code will work perfectly on the current one.
So if were to say what is 'structure', I would look for sub-division of the problem and solution in terms of the process; and I'd look for re-use of standard units of code within programs and between programs.
Ken
