- •24.3 HYDRAULICS
- •24.4 OTHER SYSTEMS
- •24.5 SUMMARY
- •24.6 PRACTICE PROBLEMS
- •24.7 PRACTICE PROBLEM SOLUTIONS
- •24.8 ASSIGNMENT PROBLEMS
- •25. CONTINUOUS CONTROL
- •25.1 INTRODUCTION
- •25.2 CONTROL OF LOGICAL ACTUATOR SYSTEMS
- •25.3 CONTROL OF CONTINUOUS ACTUATOR SYSTEMS
- •25.3.1 Block Diagrams
- •25.3.2 Feedback Control Systems
- •25.3.3 Proportional Controllers
- •25.3.4 PID Control Systems
- •25.4 DESIGN CASES
- •25.4.1 Oven Temperature Control
- •25.4.2 Water Tank Level Control
- •25.5 SUMMARY
- •25.6 PRACTICE PROBLEMS
- •25.7 PRACTICE PROBLEM SOLUTIONS
- •25.8 ASSIGNMENT PROBLEMS
- •26. FUZZY LOGIC
- •26.1 INTRODUCTION
- •26.2 COMMERCIAL CONTROLLERS
- •26.3 REFERENCES
- •26.4 SUMMARY
- •26.5 PRACTICE PROBLEMS
- •26.6 PRACTICE PROBLEM SOLUTIONS
- •26.7 ASSIGNMENT PROBLEMS
- •27. SERIAL COMMUNICATION
- •27.1 INTRODUCTION
- •27.2 SERIAL COMMUNICATIONS
- •27.2.1.1 - ASCII Functions
- •27.3 PARALLEL COMMUNICATIONS
- •27.4 DESIGN CASES
- •27.4.1 PLC Interface To a Robot
- •27.5 SUMMARY
- •27.6 PRACTICE PROBLEMS
- •27.7 PRACTICE PROBLEM SOLUTIONS
- •27.8 ASSIGNMENT PROBLEMS
- •28. NETWORKING
- •28.1 INTRODUCTION
- •28.1.1 Topology
- •28.1.2 OSI Network Model
- •28.1.3 Networking Hardware
- •28.1.4 Control Network Issues
- •28.2 NETWORK STANDARDS
- •28.2.1 Devicenet
- •28.2.2 CANbus
- •28.2.3 Controlnet
- •28.2.4 Ethernet
- •28.2.5 Profibus
- •28.2.6 Sercos
- •28.3 PROPRIETARY NETWORKS
- •28.3.1 Data Highway
- •28.4 NETWORK COMPARISONS
- •28.5 DESIGN CASES
- •28.5.1 Devicenet
- •28.6 SUMMARY
- •28.7 PRACTICE PROBLEMS
- •28.8 PRACTICE PROBLEM SOLUTIONS
- •28.9 ASSIGNMENT PROBLEMS
- •29. INTERNET
- •29.1 INTRODUCTION
- •29.1.1 Computer Addresses
- •29.1.2 Phone Lines
- •29.1.3 Mail Transfer Protocols
- •29.1.4 FTP - File Transfer Protocol
- •29.1.5 HTTP - Hypertext Transfer Protocol
- •29.1.6 Novell
- •29.1.7 Security
- •29.1.7.1 - Firewall
- •29.1.7.2 - IP Masquerading
- •29.1.8 HTML - Hyper Text Markup Language
- •29.1.9 URLs
- •29.1.10 Encryption
- •29.1.11 Compression
- •29.1.12 Clients and Servers
- •29.1.13 Java
- •29.1.14 Javascript
- •29.1.16 ActiveX
- •29.1.17 Graphics
- •29.2 DESIGN CASES
- •29.2.1 Remote Monitoring System
- •29.3 SUMMARY
- •29.4 PRACTICE PROBLEMS
- •29.5 PRACTICE PROBLEM SOLUTIONS
- •29.6 ASSIGNMENT PROBLEMS
- •30. HUMAN MACHINE INTERFACES (HMI)
- •30.1 INTRODUCTION
- •30.2 HMI/MMI DESIGN
- •30.3 DESIGN CASES
- •30.4 SUMMARY
- •30.5 PRACTICE PROBLEMS
- •30.6 PRACTICE PROBLEM SOLUTIONS
- •30.7 ASSIGNMENT PROBLEMS
- •31. ELECTRICAL DESIGN AND CONSTRUCTION
- •31.1 INTRODUCTION
- •31.2 ELECTRICAL WIRING DIAGRAMS
- •31.2.1 Selecting Voltages
- •31.2.2 Grounding
- •31.2.3 Wiring
- •31.2.4 Suppressors
- •31.2.5 PLC Enclosures
- •31.2.6 Wire and Cable Grouping
- •31.3 FAIL-SAFE DESIGN
- •31.4 SAFETY RULES SUMMARY
- •31.5 REFERENCES
- •31.6 SUMMARY
- •31.7 PRACTICE PROBLEMS
- •31.8 PRACTICE PROBLEM SOLUTIONS
- •31.9 ASSIGNMENT PROBLEMS
- •32. SOFTWARE ENGINEERING
- •32.1 INTRODUCTION
- •32.1.1 Fail Safe Design
- •32.2 DEBUGGING
- •32.2.1 Troubleshooting
- •32.2.2 Forcing
- •32.3 PROCESS MODELLING
- •32.4 PROGRAMMING FOR LARGE SYSTEMS
- •32.4.1 Developing a Program Structure
- •32.4.2 Program Verification and Simulation
- •32.5 DOCUMENTATION
- •32.6 COMMISIONING
- •32.7 REFERENCES
- •32.8 SUMMARY
- •32.9 PRACTICE PROBLEMS
- •32.10 PRACTICE PROBLEM SOLUTIONS
- •32.11 ASSIGNMENT PROBLEMS
- •33. SELECTING A PLC
- •33.1 INTRODUCTION
- •33.2 SPECIAL I/O MODULES
- •33.3 SUMMARY
- •33.4 PRACTICE PROBLEMS
- •33.5 PRACTICE PROBLEM SOLUTIONS
- •33.6 ASSIGNMENT PROBLEMS
- •34. FUNCTION REFERENCE
- •34.1 FUNCTION DESCRIPTIONS
- •34.1.1 General Functions
- •34.1.2 Program Control
- •34.1.3 Timers and Counters
- •34.1.4 Compare
- •34.1.5 Calculation and Conversion
- •34.1.6 Logical
- •34.1.7 Move
- •34.1.8 File
- •34.1.10 Program Control
- •34.1.11 Advanced Input/Output
- •34.1.12 String
- •34.2 DATA TYPES
plc software - 32.8
orifice plate |
magnetic |
|
venturi or nozzle
control valve |
rotameter |
|
|
(pneumatic activated) |
|
Figure 32.4 Sensor and Actuator Symbols and Types
32.4 PROGRAMMING FOR LARGE SYSTEMS
Previous chapters have explored design techniques to solve large problems using techniques such as state diagrams and SFCs. Large systems may contain hundreds of those types of problems. This section will attempt to lay a philosophical approach that will help you approach these designs. The most important concepts are clarity and simplicity.
32.4.1 Developing a Program Structure
Understanding the process will simplify the controller design. When the system is only partially understood, or vaguely defined the development process becomes iterative. Programs will be developed, and modified until they are acceptable. When information and events are clearly understood the program design will become obvious. Questions that can help clarify the system include;
"What are the inputs?" "What are the outputs?"
"What are the sequences of inputs and outputs?" "Can a diagram of the system operation be drawn?"
plc software - 32.9
"What information does the system need?" "What information does the system produce?"
When possible a large controls problems should be broken down into smaller problems. This often happens when parts of the system operate independent of each other. This may also happen when operations occur in a fixed sequence. If this is the case the controls problem can be divided into the two smaller (and simpler) portions. The questions to ask are;
"Will these operations ever occur at the same time?"
"Will this operation happen regardless of other operations?" "Is there a clear sequence of operations?"
"Is there a physical division in the process or machine?"
After examining the system the controller should be broken into operations. This can be done with a tree structure as shown in Figure 32.5. This breaks control into smaller tasks that need to be executed. This technique is only used to divide the programming tasks into smaller sections that are distinct.
Press
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conveyor in |
|
|
|
Press |
|
|
|
Pickup bin |
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
part detected |
advance |
bin replaced |
full detect |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adv./retract |
|
|
idle |
|
part detect |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
advancing retracting
Figure 32.5 Functional Diagram for Press Control
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.
Some of the common pitfalls encountered by designers on large projects are listed
below.
•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 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
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.2Program 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.