Automating Manufacturing Systems - Process Control and ...

plc software - 32.11
amounts of time, and often lead to major design changes.
• The designers use unprofessional approaches. They tend to follow poor designs,
against the advice of their colleagues. This is often because the design is their
child
• Designers get a good dose of the not invented here syndrome. Basically, if we
didn’t develop it, it must not be any good.
• Limited knowledge will cause problems. The saying goes “If the only tool you
know how to use is a hammer every problem looks like a nail.”
• Biting off more than you can chew. some projects are overly ambitious. Avoid
adding wild extras, and just meet the needs of the project. Sometimes an unnecessary
extra can take more time than the rest of the project.
32.4.2 Program Verification and Simulation
After a program has been written it is important to verify that it works as intended,
before it is used in production. In a simple application this might involve running the program
on the machine, and looking for improper operation. In a complex application this
approach is not suitable. A good approach to software development involves the following
steps in approximate order:
1. Structured design - design and write the software to meet a clear set of objectives.
2. Modular testing - small segments of the program can be written, and then tested
individually. It is much easier to debug and verify the operation of a small program.
3. Code review - review the code modules for compliance to the design. This
should be done by others, but at least you should review your own code.
4. Modular building - the software modules can then be added one at a time, and
the system tested again. Any problems that arise can then be attributed to interactions
with the new module.
5. Design confirmation - verify that the system works as the design requires.
6. Error proofing - the system can be tested by trying expected and unexpected
failures. When doing this testing, irrational things should also be considered.
This might include unplugging sensors, jamming actuators, operator errors, etc.
7. Burn-in - a test that last a long period of time. Some errors won’t appear until a
machine has run for a few thousand cycles, or over a period of days.
Program testing can be done on machines, but this is not always possible or desireable.
In these cases simulators allow the programs to be tested without the actual machine.
The use of a simulator typically follows the basic steps below.
1. The machine inputs and outputs are identified.