12.05.2014 Views

Automating Manufacturing Systems - Process Control and ...

Automating Manufacturing Systems - Process Control and ...

Automating Manufacturing Systems - Process Control and ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

plc software - 32.11<br />

amounts of time, <strong>and</strong> often lead to major design changes.<br />

• The designers use unprofessional approaches. They tend to follow poor designs,<br />

against the advice of their colleagues. This is often because the design is their<br />

child<br />

• Designers get a good dose of the not invented here syndrome. Basically, if we<br />

didn’t develop it, it must not be any good.<br />

• Limited knowledge will cause problems. The saying goes “If the only tool you<br />

know how to use is a hammer every problem looks like a nail.”<br />

• Biting off more than you can chew. some projects are overly ambitious. Avoid<br />

adding wild extras, <strong>and</strong> just meet the needs of the project. Sometimes an unnecessary<br />

extra can take more time than the rest of the project.<br />

32.4.2 Program Verification <strong>and</strong> Simulation<br />

After a program has been written it is important to verify that it works as intended,<br />

before it is used in production. In a simple application this might involve running the program<br />

on the machine, <strong>and</strong> looking for improper operation. In a complex application this<br />

approach is not suitable. A good approach to software development involves the following<br />

steps in approximate order:<br />

1. Structured design - design <strong>and</strong> write the software to meet a clear set of objectives.<br />

2. Modular testing - small segments of the program can be written, <strong>and</strong> then tested<br />

individually. It is much easier to debug <strong>and</strong> verify the operation of a small program.<br />

3. Code review - review the code modules for compliance to the design. This<br />

should be done by others, but at least you should review your own code.<br />

4. Modular building - the software modules can then be added one at a time, <strong>and</strong><br />

the system tested again. Any problems that arise can then be attributed to interactions<br />

with the new module.<br />

5. Design confirmation - verify that the system works as the design requires.<br />

6. Error proofing - the system can be tested by trying expected <strong>and</strong> unexpected<br />

failures. When doing this testing, irrational things should also be considered.<br />

This might include unplugging sensors, jamming actuators, operator errors, etc.<br />

7. Burn-in - a test that last a long period of time. Some errors won’t appear until a<br />

machine has run for a few thous<strong>and</strong> cycles, or over a period of days.<br />

Program testing can be done on machines, but this is not always possible or desireable.<br />

In these cases simulators allow the programs to be tested without the actual machine.<br />

The use of a simulator typically follows the basic steps below.<br />

1. The machine inputs <strong>and</strong> outputs are identified.<br />

www.PA<strong>Control</strong>.com

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!