Automating Manufacturing Systems - Process Control and ...

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.
below.
Some of the common pitfalls encountered by designers on large projects are listed
• 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 trialand-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