plc software - 32.8

venturi or nozzle

Figure 32.4 Sensor and Actuator Symbols and Types

32.4 PROGRAMMING FOR LARGE SYSTEMS

Previous chapters have explored design techniques to solve large problems using techniques such as state diagrams and SFCs. Large systems may contain hundreds of those types of problems. This section will attempt to lay a philosophical approach that will help you approach these designs. The most important concepts are clarity and simplicity.

32.4.1 Developing a Program Structure

Understanding the process will simplify the controller design. When the system is only partially understood, or vaguely defined the development process becomes iterative. Programs will be developed, and modified until they are acceptable. When information and events are clearly understood the program design will become obvious. Questions that can help clarify the system include;

"What are the inputs?" "What are the outputs?"

"What are the sequences of inputs and outputs?" "Can a diagram of the system operation be drawn?"

plc software - 32.10

Each block in the functional diagram can be written as a separate subroutine. A higher level executive program will call these subroutines as needed. The executive program can also be broken into smaller parts. This keeps the main program more compact, and reduces the overall execution time. And, because the subroutines only run when they should, the change of unexpected operation is reduced. This is the method promoted by methods such as SFCs and FBDs.

Each functional program should be given its’ own block of memory so that there are no conflicts with shared memory. System wide data or status information can be kept in common areas. Typical examples include a flag to indicate a certain product type, or a recipe oriented system.

Testing should be considered during software planning and writing. The best scenario is that the software is written in small pieces, and then each piece is tested. This is important in a large system. When a system is written as a single large piece of code, it becomes much more difficult to identify the source of errors.

The most disregarded statement involves documentation. All documentation should be written when the software is written. If the documentation can be written first, the software is usually more reliable and easier to write. Comments should be entered when ladder logic is entered. This often helps to clarify thoughts and expose careless errors. Documentation is essential on large projects where others are likely to maintain the system. Even if you maintain it, you are likely to forget what your original design intention was.

Some of the common pitfalls encountered by designers on large projects are listed

below.

•Amateur designers rush through design to start work early, but details they missed take much longer to fix when they are half way implemented.

•Details are not planned out and the project becomes one huge complex task instead of groups of small simple tasks.

•Designers write one huge program, instead of smaller programs. This makes proof reading much harder, and not very enjoyable.

•Programmers sit at the keyboard and debug by trial and error. If a programmer is testing a program and an error occurs, there are two possible scenarios. First, the programmer knows what the problem is, and can fix it immediately. Second, the programmer only has a vague idea, and often makes no progress doing trial- and-error debugging. If trial-and-error programming is going on the program is not understood, and it should be fixed through replanning.

•Small details are left to be completed later. These are sometimes left undone, and lead to failures in operation.

•The design is not frozen, and small refinements and add-ons take significant