page 569

33. DESIGNING LARGE SYSTEMS

33.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

page 570

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.

33.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.

page 571

33.3 PLC PROGRAM DESIGN FORMS

PLC Project Sheet

Project ID:

Start Date:

Contact Person:

PLC Model:

Attached Materials/Revisions:
Date	Name	# Sheets	Reason

page 572

				Project Notes
Project ID:						Date:
	System Description					Page		of
	I/O Notes
	Power Notes					Name:
	Other Notes

page 573

			Design Notes
Project ID:						Date:
	State Diagram		Truth Table			Page			of
	Flow Chart		Safety
	Sequential Function Chart		Communications			Name:
	Boolean Equations		Other Notes

page 574

			Application Notes
Project ID:					Date:
Test Plan					Page			of
Electrical I/O					Name:
PLC Modules
Other Notes

page 575

Input/Output Card	Page		of

Project I.D.

Card Type

Notes:

input/output

Vin

00

01

02

03

04

05

06

07

08/10

09/11

10/12

11/13

12/14

13/15

14/16

15/17

com

Name				Date
Rack #			Slot #

JIC symbol			Description

page 576

Internal Locations				Page			of
Project I.D.			Name			Date
Register or Word		Description
Internal Word

page 577

Project I.D.

Program Listing

Page

of

Name

Date

rung#

comments