- •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.2
Sabotage - For various reasons, some individuals may try to damage a system. These problems can be minimized preventing access.
Random failure - Each component is prone to random failure. It is worth considering what would happen if any of these components were to fail.
Some design rules that will help improve the safety of a system are listed below.
Programs
•A fail-safe design - Programs should be designed so that they check for problems, and shut down in safe ways. Most PLC’s also have imminent power failure sensors, use these whenever danger is present to shut down the system safely.
•Proper programming techniques and modular programming will help detect possible problems on paper instead of in operation.
•Modular well designed programs.
•Use predictable, non-configured programs.
•Make the program inaccessible to unauthorized persons.
•Check for system OK at start-up.
•Use PLC built in functions for error and failure detection.
People
•Provide clear and current documentation for maintenance and operators.
•Provide training for new users and engineers to reduce careless and uninformed mistakes.
32.2DEBUGGING
Most engineers have taken a programming course where they learned to write a program and then debug it. Debugging involves running the program, testing it for errors, and then fixing them. Even for an experienced programmer it is common to spend more time debugging than writing software. For PLCs this is not acceptable! If you are running the program and it is operating irrationally it will often damage hardware. Also, if the error is not obvious, you should go back and reexamine the program design. When a program is debugged by trial and error, there are probably errors remaining in the logic, and the program is very hard to trust. Remember, a bug in a PLC program might kill somebody.
Note: when running a program for the first time it can be a good idea to keep one hand on the E-stop button.