30. Designing Large Systems

30.1 Programming

• Some concepts to observe,

break a large program into smaller parts, and separate out operations as much as possible. Questions to ask are,

do things need to happen at the same time?

does a process occur all the time?

develop lists of the data needed before starting

find a way to keep programs compact, and more usable.

plan on paper before starting

• Write programs to have an executive subroutine

• Use flags to pass messages between separated programs

• put each separate program in a separate program file, and give it its own section of memory to avoid conflicts

• If possible use subroutines to reduce redundancy

• Build with testing in mind

• write comments and documents as you go. It even helps to write documents before implementing: this gives more clarity, and exposes mistakes before they occur.

• Typical problems in large projects include,

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 fixed through planning.

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

the design is not frozen, and small refinements and add-ons take significant 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 uncessary extra can take more time than the rest of the project.

30.2 Documentation

• These forms are used to prepare ladder logic programs.

• Documentation should be done as a running record of work done and decisions made.

• With industrial control, the traditional approach of trial and error debugging of programs should not be used. Programs should be developed to work right the first time.

30.3 PLC Program Design Forms

 

 

 

 

 

 

 

30.4 Problems

Problem 30.1 Documentation of a PLC Ladder Logic program requires:

a) A copy of the uncommented Ladder Logic Program

b) A copy of the commented Ladder Logic program

c) A copy of the commented Ladder Logic program and a listing of the inputs/outputs and their addresses

d) None of the above

Answer 30.1 c

Problem 30.2 TRUE / FALSE -- When planning Ladder Logic, the inputs/outputs should be chosen before anything else.

Answer 30.2 true

Problem 30.3 3. List 5 advantages of using structured design and documentation techniques.

Answer 30.3 - more reliable programs

- less debugging time

- more routine

- others can pick up where you left off

- reduces confusion

 

[an error occurred while processing this directive]