Programmable Logic Controllers and Industrial Control: Process-Control Design and Troubleshooting

Home | Forum | DAQ Fundamentals | DAQ Hardware | DAQ Software

Input Devices
| Data Loggers + Recorders | Books | Links + Resources

This Section covers PLC process-control design and troubleshooting. The system presented here is formed of three layers: process-control overview, process control implementation, and process-control checkout and startup.


  1. - Document process description, components, and control.
  2. - Implement process logic diagrams/function blocks.
  3. - Be able to perform process-control checkout/startup.
  4. - Understand safety standards.

This Section covers the fundamentals of process-control/automation design techniques and industry-accepted standards. As with other established and successful computer systems, such as computer operating systems and computer network protocols, a layered hierarchal system is used. The simplified system presented here is made up of three layers: process-control overview (layer 1), process-control implementation (layer 2), and process-control checkout and startup (layer 3). The general guidelines for the three layers will be discussed in the first three sections of this Section . Design reviews and approvals are required for each layer before proceeding to the next level and committing requested resources. Special attention in this Section is paid to standard checkout techniques (layer 3) because design and implementation issues (layers 1 and 2) were covered in previous Section s' examples and in the comprehensive case study included in Section 8.

1 Process-Control Overview, Layer 1

Layer 1 provides a process-control/automation overview for a project, including a comprehensive definition of the level of automation and what will be controlled. It’s used as the basis of preliminary costs, resources needs, and overall project schedule estimates. Specific issues to be covered in this layer include

  • • Control-system requirements
  • • Start and stop procedures
  • • Disturbance/alarm-handling strategies
  • • Process constraints
  • • Regulatory and safety requirements

The documentation in layer 1 will serve as the basis for later development of the detailed process-control strategy, layer 2. Layer 1 describes the intended scope and purpose of the project. It includes relevant information on the current process if the project is an enhancement, replacement, or revision of an existing system.

Specialized or abbreviated terms should be avoided unless fully defined because this document is intended for use by professionals who are stakeholder in the overall system operation and well-being but not necessarily versed in process control/automation.

Reference sources for the information supplied and used in this document should be provided whenever possible. Required details of layer 1 include process descriptions, level of control/automation, and control-system components, and all will be discussed in the next three subsections.

1.1 Process Descriptions

This subsection conveys in a very general way the functionality and details of the particular automation system or process control. It should clearly identify all components/processes of the system and list the important attributes of each process.

Significant concerns must be documented, such as quality issues, safety concerns, energy consumption, and possible disturbances. Relevant information that may enhance the general understanding of the process must be included or referenced.

The information in this section is typically the result of collaborations between the process-control lead and other process/operation experts. It also can include references to already-existing documents.

Describe the specific process control/automation objectives for the project.

The following are typical objectives:

• Minimize manual interactions. A standard objective of automation is to eliminate or minimize manual operations. This includes the automation of container loading or unloading, the use of computerized data acquisition, automating actuation control, adding safety functions, and other quality-enhancement functions.

• Protection of equipment. This includes operational restrictions for key equipment, safeguards during startup and shutdown, and other standard operation and maintenance procedures.

• Quality control. This includes ensuring correct raw materials handling, control ling recipe implementation, instrumentation adequacy for measurements, meeting product specifications, and providing adequate monitoring for continuous quality-control improvements.

• Safety and the environment. This includes handling of hazardous and toxic materials, operations at high pressure or temperature, leakage and spill avoidance, risk minimization, and safety procedures.

• Energy use and recycling. This includes energy-use reduction, improved reuse/ recycling yield, elimination or reduction of waste, and wastewater/material treatment and recycling.

• Asset utilization. This includes increased capacity, reduced process cycle time, added flexible production capabilities, improved process performance, and reduced system down time.

• New technology. This includes implementation of new technologies safely and effectively to enhance process performance and product quality.

1.2 Level of Control/Automation

This subsection explicitly defines the recommended level of automation for the control system. It includes process start, run, stop, and potential upsets/disturbances.

Recommendations must take into account the complexity, integration level, safety requirements, hazards, and quality needs of the required process flexibility/restrictions during the whole cycle of operation. Recommended level of control must add value to the existing system, and its associated cost benefit must be justified.

This section must define the startup philosophy, which can be either human driven, totally automated, or a mixture of both. The following are examples of issues to be considered:

• Process-control utilities and associated functionality

• Subsystems coordination needs and sequencing

• Alarm and interlocking mechanisms and associated procedures

• Process control basic constraints and override procedures

• Emergency shutdown and power-failure restarting and recovery functions

This document can include additional details of both the functionality and primary objectives for the "run" and "shutdown" states of the process-control system. It also might include some specific constraints or limitations that need to be applied for successful and safe system operation. The level of control/automation also should identify any governmental requirements or professional standards that apply to the control and operation of the system. Standards include applicable internal organization practices and guidelines as well as specific contractual agreements. Social implications of the automation project and its impact on all stakeholders must be documented.

A wide variety of national and international standards apply to the design and implementation of automation and process-control projects. This include U.S. Food and Drug Administration (FDA) regulations, the Toxic Substances Control Act (TSCA), the International Standard for Developing an Automated Interface between Enterprise and Control Systems (ISA-95), Good Automated Manufacturing Practice (GAMP-4), the Code of Federal Regulations (CFR), and the American National Standards Institute (ANSI) and other specialized regulations.

1.3 Control-System Components

This subsection includes a high-level scope description of the process-control project and supporting systems. The type of control system and vendor should be identified with its specific components, if decided; otherwise, general requirements of the system must be given. Include any special requirements such as interfaces to vendor or customer systems, operator panels, remote input-output (I/O), field stations, control-room displays, and communication with other control systems. Define the basic system architecture, identifying and explaining any deviations from standard models.

The following is a sample of typical control-system components:

• Complete listing of control-system inputs and associated sensors

• Complete listing of control-system outputs and associated final control elements/actuators

• Basic system control structure and alarming parts

• Safety control-system requirements

• Human-machine interface (HMI) display and control interface

• Process information system and data acquisition

• Procedural control recipes, coordination, and sequencing

• Communication and networking interfaces

This subsection also identifies known software requirements with the versions selected for the control system, for the operator interface, for HMIs, for process modeling or advanced control, for data acquisition, and for simulation activities.

The protection of the process from inadvertent operator actions needs to be addressed. Specific consideration needs to be employed in applying protection to the control system, including manual intervention procedures.

2 Process-Control Implementation, Layer 2

This document includes all the information associated with implementation of the process-control system, including software design, hardware configuration, and communication protocols used. It’s intended to provide explicit documentation of all implemented tasks and to provide collaboration/communication avenues to all project stakeholders. This collaboration is essential and often produces changes and enhancements in the implementation. Stakeholders often include domain experts (e.g., electric, mechanical, chemical, civil, environmental, and industrial engineers/technicians), operations and maintenance personnel, and the owner.

Assumptions made during the implementation of this section (layer 2) that require clarification, confirmation, or additional information in the latter stages of the project in layer 3 must be fully documented. Outstanding issues that require follow-up or consultation must be clearly highlighted. These issues must be resolved and removed from the layer 2 section prior to start of the final checkout and startup, layer 3. The remainder of this section will detail the steps carried out during the process-control implementation, which include I/O detailed listings, data-acquisition tasks, closed-loop control, project logic diagrams/ flowcharts, specification of ladder-program function blocks, and overall system documentation.

2.1 I/O Listing

All inputs and outputs associated with the process-control system must be listed in the I/O worksheet/action table along with the associated instrumentation.

Required accuracy and resolution of relevant I/O are also documented in this table. The process-control designer identifies any special issues associated with the instrumentation in the I/O listing, including safe-fail position for outputs, calibration requirements for inputs, and redundancy considerations. The I/O action table captures most details necessary for the coding of all inputs and outputs, both digital and analog, as briefly described as follows:

• Digital outputs. Identify the position of each digital output in all process phases and against all possible interlock actions. Fail-position disconnect actions must be documented. Show the template used to create the code and program the output. The purpose and action for each digital output need to be understood and communicated.

• Digital inputs. Identify the position of each digital input in all process phases and against all possible interlock actions. Fail-position disconnect actions must be documented. Show the template used to create the code and program the input. The purpose and action for each digital input need to be understood and communicated.

• Analog outputs. Analog outputs are listed in the I/O action table, which captures most details necessary for coding. Identify the control action of each analog output in all process phases and against all possible interlock actions. The analog-output action table is also used to identify fail-position disconnect actions, the template used to create the code, and other additional logic required to program the output.

• Analog inputs. Analog inputs are listed in the I/O action table, which captures most details necessary for coding. Identify the control action of each analog input in all process phases and against all possible interlock actions. The analog input action table is also used to identify fail-position disconnect actions, the template used to create the code, and other additional logic required to program the input.

Special types of I/O are common in some process-control systems. This includes a high-speed pulse counter for measuring flow rate and digital stepper motor output count. All special I/O must be clearly configured and documented.

Also, associated interfaces and specification must be listed, and any deviations from default standards must be highlighted. Scaling must take into consideration instrument mis-calibrations and potential signal deviations from the pre specified range.

2.2 Data-Acquisition and Closed-Loop-Control Tasks

Data acquisition is the process of sampling analog input signals that measure real world physical conditions and convert the resulting samples into digital numeric values that can be manipulated by the programmable logic controller (PLC) or, most commonly, by a computer system more situated for modeling, simulation, and database tasks. Most analog inputs are part of the data-acquisition task, with smaller number used in closed-loop control. Every closed loop has at least two analog variables assigned: the controlled and controlling values. The components of data-acquisition and closed-loop-control-system tasks include

• Sensors that constitute a simple data-acquisition task must be documented in both the functionality and the detailed programming implementation. This includes details of the method used, as in redundant sensory data validation or complementary sensory data fusion techniques.

• Data-acquisition tasks associated with HMIs must be detailed with the associated communication and graphics tasks. Linkage between the ladder program and the HMIs is very critical for system operation, future enhancements, and overall system maintenance.

• Some data-acquisition applications/tasks are often developed using various general-purpose programming languages or software tools, such as Visual Basic, Java, C++, and LabVIEW. These tasks need to be documented as part of the overall control-system design.

• Closed-loop-control tasks should clearly identify the controlled variable, the controlling variable, digital count format, engineering units, type of control, and the algorithms used to achieve control. ON/OFF and proportional-integral derivative (PID) control are the most common process-control techniques in use today, with an increasing trend toward fuzzy-logic control in recent years.

Detailed coverage of process-control techniques and instrumentation is provided in Section 7. A case study in Section 8 will demonstrate the design and implementation of basic data-acquisition and process-control tasks for a real-time industrial project.

2.3 Project Logic Diagrams and Ladder-Function Blocks

Historically, flowcharts were often used to document logic flow prior to actual programming implementation. With the advancement of PLCs and distributed digital process control, pseudocodes and logic diagrams are becoming the tool of choice. Logic diagrams are used in this guide and were introduced in Section 2. A structured approach must be enforced when a given task is divided into a number of smaller interconnected subtasks. Logic diagrams are effective visual documentation that directly maps into the ladder program and can be used with any PLC/ control-system platform. Pseudocode tools are platform-dependent but can automatically generate the ladder or executable control code.

Although ladder programming may be the most widespread language for the implementation of PLC control, function-block diagrams/logic diagrams are probably the second most used language. This graphic language resembles a wiring diagram, with the blocks wired together into a sequence that is easy to follow.

It uses the same notations/instructions of ladder diagrams but is visually more understandable to a viewer who is not versed in relay logic. Logic diagrams are not ideal for very large programming tasks, which include the use of special functions and I/Os. Implementing a process-control program using ladder diagrams requires more preparation up front to ensure full understanding of the program structure and the control flow before any code is committed.

Siemens' ladder-program structure is based on function blocks, as was described in Section 5. Typically, a process-control application uses a varying number of blocks, including an initialization block, a data-acquisition block, an HMI block, an alarms block, a communication block, a diagnostic block, or other major processing blocks.

Section 8 will cover these concepts in a comprehensive industrial process-control case study. A small example will be used here to illustrate the concept.

2.4 Control-System Preliminary Documentation

The purpose of the system preliminary document is to communicate the process control implementation details to all stakeholders before the final checkout and startup. The document essentially serves as the base for critical design reviews and potential revisions/enhancements. It also can be used by a wide range of audiences, including facilities, partners, customers, process leaders, or anyone who is involved in any of the processes outlined in the document. Always be aware of potential liabilities by documenting and seeking validation or clarification on all safety/hazard-related issues.

The following are some of the basic tasks involved in creating process-control preliminary documentation:

  • • Process scope and goal statement
  • • Inputs and outputs map
  • • Hardware configuration
  • • Communication protocol and configuration
  • • Ladder-program function blocks
  • • Process logic diagrams
  • • Safety and operational hazard issues
  • • Process- control management-system procedures
  • • Exception-management process
  • • Ladder and HMI listing

Each of these tasks will be a section within your document, which you can create in Microsoft Office Word or other word-processing program. We recommend using a program that automatically generates a table of contents based on the use of heading styles. Also, it's important to assign a clear numbering system within the document. For instance, the process scope and goal statement might be 1, whereas items included with that statement might be 1.1, 1.2, 1.3, and so on. The inputs and out puts map might be 2. A numbering system accomplishes two goals in that it makes information easy for readers to find and allows easy tracking of changes to the document by different individuals. Changes will be documented by date, person, and the revisions made. This is particularly critical for effective collaboration among a team of participants and stakeholders in the design and implementation process.

2.5 Program Documentation Using Cross Reference

There are several ways of displaying cross-references depending on whether you are in the Portal view or the Project view and which object you have selected in the project tree. In the Portal view, you can only display cross-references for the entire CPU; in the Project view, you can, For example, display cross-references for the following objects:

• PLC tags folder

• PLC data-types folder

• Program blocks folder

• Tags and connections folder

• Individual tags

• Individual PLC data types

• Individual blocks

• Technological objects

We will use an example (La1_Comb_Logic) to illustrate the subject of program documentation. The program has four logic functions (AND, OR, XOR, and XNOR). We will illustrate how to display the cross-reference information for an AND logic. Use the following steps to display the cross-reference:

• From Portal view, click Show cross-reference ( Fig. 1).

• From Project view, you can monitor AND_LOGIC (address, date created, and date last modified) ( Fig. 2).

3 Process-Control Checkout and Startup, Layer 3

The final step in the design is the checkout and startup of the process-control system, layer 3. Preliminary testing of hardware, software, communications, and user interfaces is a major part of the system implementation, Layer 2. This layer is concerned with final system troubleshooting and commissioning. Technology transfer to the owner/customer is a key issue in completed automation projects. It must be planned and budgeted in the early stages of the project, layer 1. All check out activities are performed in the field using the system physical resources in real time. Stakeholders, including operations and maintenance personal, are all critical parts of this step, which is led by the process-control/automation lead who designed and implemented the system. The process includes standard procedures and steps that are detailed in this section. Also, standard safety procedures will follow the checkout discussions.

The S7-1200 PLC provides three different methods for the testing of the user program: testing using program status, testing using the watch table, and testing using the force table. Each of the three techniques is briefly discussed as follows:

• Testing with the program status and system diagnostics. The program status allows users to monitor the running of the program. You can display the values of operands and the results of logic operations (RLOs), which allow for the detection and fixing of logical errors in the program. The PLC system diagnostic tools allow for the use of a wide variety of information during checkout.

FIG. 1 Portal view.

FIG. 2 Project view.

• Testing with the watch table. With the watch table, current values of individual tags in the user program or on a CPU can be monitored and modified. Values can be assigned to individual tags for testing and program runs in a variety of different situations. Fixed values can be assigned to the I/O tags of a CPU in the STOP mode, which is typically used during the system static checkout of wiring.

• Testing with the force table. With the force table, current values of individual tags in the user program or on a CPU can be monitored and forced. Forcing an individual tag will overwrite that tag with the specified value. This allows pro gram testing and run under various situations and scenarios.

3.1 Checkout Using Forcing Functions

Great care and precautions must be taken during the use of PLC forcing functions.

Because a forcing function allows a user to intervene permanently in the process by assigning an arbitrary status/value to a control variable, observance of the following notices is essential:

• Prevent potential personal injury and material damage. An incorrect action while executing the Force function can harm people or pose a health hazard. It also can produce damage to machinery or the entire plant.

• Before starting the Force function, you should ensure that no one else is currently executing this function on the same CPU.

• Forcing can only be stopped by clicking the Stop Forcing icon or using the Online ? Force ? Stop forcing command. Closing the active force table does not stop the forcing.

• Forcing cannot be undone through the program logic execution.

Force tables can be used to monitor and force the current values of selected I/O in the program. When you force an input or an output, you overwrite the status of the selected I/O. This allows the logic designer to test the program while the system is running. The following safety precautions must be taken when forcing tags:

• Before starting the Force function, the user should ensure that no one else is currently executing this function on the same CPU.

• Forcing can only be stopped by clicking the Stop Forcing icon on the force table tool bar. Closing the active force table does not stop the forcing.

• Forcing is not affected by previous rung logic.

• Modifying tags are different from forcing tags. The modifications can be changed by the program logic or through the updated I/O memory image, whereas forcing is permanent. Users should check the Siemens technical manuals before using the Force function.

Forcing Outputs ON/OFF

The first step in the checkout process includes testing of all input and output device wiring to the PLC modules. This section covers output forcing in the Siemens S7-1200 system. As shown in Fig. 3, from the Project Tree menu under Watch and Force Table, click Force Table, and then enter the address you need to force and then enter Force value (TRUE or FALSE).

In Fig. 4, the physical switch SS2 is open, and output coil Q0.1 with tag name PL2 is forced ON. Physical pilot light (PL2) in the Network 1 illuminates as indicated. The normally open contact Q0.1 in Network 3 is not affected by the force ON applied to the output Q0.1 in Network 1, and thus pilot light PL4 is not turned ON. The figure also shows PL3 in Network 3 OFF because SS2 is OFF. FIG. 5 illustrates the preceding output forcing example in relation to the actual physical inputs and outputs used. The figure shows the status of the pilot lights (PL2, PL3, and PL4) in relation to input switch SS2 and the ladder program, as described earlier. The forcing function is intentionally designed to affect only the selected output, but none of the remaining logic in the program will be affected.

This function is used primarily during static checkout of all outputs wiring.

Notice the status of the normally open contact SS2 with address I0.1, which is OPEN. Output coil Q0.1 is physically connected to PL2, and this output coil is being forced ON/TRUE. PL2 turns ON as a result of the forcing of coil Q0.1 to TRUE status. The normally open contact associated with PL2 stays OFF. Only the forced output Q0.1 is ON; thus PL4 stays OFF. PL3 is OFF because SS2 is also OFF, which does not allow power to propagate to the coil associated with PL3 with address Q0.2. Of course, switching SS2 ON will cause all lights to go ON regardless of the forcing action.

FIG. 3 Force table.

FIG. 4 Forcing a PLC output.

FIG. 5 Forcing output in relation to physical inputs and outputs.

FIG. 6 Forcing PLC inputs.

Forcing Inputs ON/OFF

FIG. 6 shows the physical switch SS1 in the open position, and the normally open input I0.0 instruction with tag name SS1 is forced ON. Output Q0.0 with tag name PL1 is physically ON when 0 to 1 is detected by RLO (rung logic output). Output coil Q0.1 with tag name PL2 is OFF because normally closed instruction I0.0 with tag name SS1 is forced ON. In the last rung, the normally open instruction Q0.0 with tag name PL1 is not affected by the forced ON, and a 0 to 1 is not detected by RLO, causing output coil Q0.2 with tag name PL3 to turn OFF, which physically turns PL3 OFF.

As stated earlier in our coverage of output forcing functions, the same rules apply to the input forcing functions. A forced input turns that input to the selected force value. Associated networks with the forced input will behave according to the forced value. This function is used to verify all input wiring and associated sensor operations. This static checkout process is performed entirely from the PLC programming terminal with assistance from a technician or an operator in the field where the actual sensors and actuators are located. Communication between the person in the field and the PLC operator is essential to the checkout process using the I/O forcing functions. It’s important to execute the forcing in sequential order and remove the forcing of the completed item before moving on to the next I/O in the checkout list. There is no sense in checking the implemented control program logic before completing a successful static checkout.

FIG. 7 shows the status of the pilot lights in relation to input SS1 and the ladder program, as described earlier.

FIG. 8 Unexpected results due to repeated use of an output.

FIG. 7 Forcing inputs in relation to physical inputs and outputs.

FIG. 9 Repeated use of an output and its consequences.

3.2 Checkout Using Watch Tables

Using output coils in more than one location in a program can be a source of trouble during checkout. In this section we will demonstrate checkout using watch tables in conjunction with this problem. Output coil addresses can't be repeated due to the way the processor scans the program (left, up, down, right), as shown in the ladder diagram and watch table in Fig. 8; PL1 will be OFF when SW1 is ON, SW2 is ON, and SW3 is OFF.

Unpredicted results can be reached because of the repeated coil address in the same program. As shown in Fig. 9, another combination can produce the same confusing results. The ladder logic in the figure demonstrates this situation. As shown, PL1 will be OFF when SW1 is OFF, SW2 is OFF, and SW3 is ON in the ladder diagram and the Watch table.

3.3 Checkout Using Cross-Reference, Program Status, and System Diagnostics

The Siemens software performs diagnostic tasks every ladder program scan and updates the hardware status. It also provides a log for all important and relevant events. This information is available, and users need to be aware of the best way to make use of such information during program checkout. Program status and cross-reference information is also available and must be accessed and used during program, hardware, communication, and graphical user interface (GUI) debugging. This section introduces these tools, but more details are available in the technical manuals or, more conveniently, online using the Help menus. The Appendix covers some of the key diagnostic tasks and screens.

As shown in Fig. 10, use the following tools to maneuver around the project:

1. Device configuration shows the hardware configured in your system.

2. Arrow up shows a device overview.

3. Arrow down gets you back to device configuration view.

Debugging Using Cross-Reference

FIG. 10 Navigating the device configuration tools.

There are several ways of displaying cross-references depending on whether you are in the Portal view or the Project view and which object you have selected in the Project Tree. In the Portal view, only cross-references for the entire CPU can be displayed.

In the Project view, cross-references for the following objects can be displayed:

• PLC tags folder

• PLC data types folder

• Program blocks folder

• Tags and connections folder

• Individual tags

• Individual PLC data types

• Individual blocks

• Technological objects

FIG. 11 Cross references.

A program titled Lab1_Comb_Logic, as shown in Fig. 11, is used to illustrate the subject of program documentation using cross references. The program implements four logic operations (AND, OR, XOR, and XNOR). AND logic is used below to illustrate the use of cross-reference information. The following steps can be used to display the program cross-reference:

1. From the Portal view, click Show cross-references.

2. From the Project view, you can monitor the AND_LOGIC (address, date created, and date last modified), as shown in Fig. 12.

Debugging Using Program Status and Diagnostic Information

FIG. 12 AND_LOGIC cross references.

FIG. 13 Combination logic AND and OR program.

A small program is shown in Fig. 13 that which has two networks implementing combinational logic AND and OR operations. This program will be used to demonstrate debugging using program status and diagnostics tools. Two switches, SW1 and SW2, are used to provide the input to the logic operation. Two coils with tag names AND_LOGIC and OR_LOGIC are used to output the results of the two logic operations. This program is extremely small and simple but is used here to illustrate the checkout and troubleshooting techniques. Close SW1, and monitor the normally open contact energizes.

The CPU supports a diagnostic buffer that contains an entry for each diagnostic event. Each entry includes the date and time the event occurred, an event category, and an event description. The entries are displayed in chronological order, with the most recent event at the top. While the CPU maintains power, up to 50 most recent events are available in this log. When the log is full, a new event replaces the oldest event in the log. When power is lost, the 10 most recent events are saved.

The following types of events are recorded in the diagnostics buffer:

• Each system diagnostic event, For example, CPU errors and module errors

• Each state change of the CPU, For example, power up, transition to STOP, and transition to RUN

• Each change to a configured object except changes issued by the CPU and the user program

To access the diagnostic buffer, you must be online. Locate the log under Online & Diagnostics ? Diagnostics ? Diagnostics buffer ( Fig. 14).

FIG. 14 Diagnostic buffer.

FIG. 15 Open existing project.

The following are the diagnostic functions for the Sematic-1200:

1. From the Portal view, open the project LAB6_AIRPORT_CONVEYOR (? Open existing project ? LAB6_AIRPORT_CONVEYOR ? Open) ( Fig. 15).

2. Go online (? LAB6_AIRPORT_CONVEYOR ? Go online) ( Fig. 16).

3. Next, select PG/PC interface for online access (? PG/PC interface for online access ? Go online) ( Fig. 17).

4. As you go online, you can START or STOP the PLC, as shown in Fig. 18.

5. On the bottom to the right, the Diagnosis symbols can be combined with smaller supplementary symbols that indicate the result of the online/offline comparison ( Fig. 19).

FIG. 16 Go online.

Combined Diagnosis and Comparison Symbols See Fig. 20.

Diagnosis Symbols for Modules and Devices See Fig. 21.

FIG. 22 shows a system configuration with two I/O modules added but that don’t exist.

Error is detected because of the wrong configuration, online and offline differences, or hardware problems. Error is shown as a flashing red square on the PLC error tag, in the Project Tree, and also under Diagnostic in the software diagnostic buffer. Refer to the symbol tables for error details (Figs. 23 through 25).

Open Device configuration under Diagnosis, and check the status of the individual components, such as memory usage, cycle time, and communication (? Device configuration ? Diagnosis) ( Fig. 26).

FIG. 17 Selecting and configuring online access device.

4 System Checkout and Troubleshooting

System checkout and troubleshooting are critical tasks before the final deployment and commissioning of any process-control/automation system. These tasks must be performed according to well-established rules and documented procedures. These rules/procedures are designed carefully to prevent any potential problems that might cause personnel injuries or damage to resources or compromise any of the predefined process/end-product qualities. Simulation and emulation techniques are used throughout the implementation phases of the project prior to the final checkout. Simulation tools allow designers to examine system-performance situations under varying scenarios before or aside from the actual implementation. These steps also can be used to efficiently verify design concepts prior to the commitment of resources. Emulation phases are accommodated in PLC software-development tools that allow the user to emulate I/O hard ware, HMIs, control logic, and communication facilities. The initial phase of emulation checks only the control logic, whereas the second phase includes actual and simulated hardware/interfaces. The final emulation phase uses actual system hardware, interfaces, and communication resources.

FIG. 18 Start/stop the PLC.

FIG. 19 Online/offline comparison and associated symbols.


FIG. 20 Folder contains objects whose online and offline versions differ Comparison results are not known Online and offline versions of the object are identical Online and offline versions of the object are different Object only exists offline Object only exists online Symbol Description


The connection with a CPU is currently being established.

The CPU is not reachable at the set address.

The configured CPU and the CPU actually present are of incompatible types.

On establishment of the online connection to a protected CPU, the password dialog was terminated without specification of the correct password.

No fault.

Maintenance required.

Maintenance demanded.


The module or device is deactivated.

The module or the device cannot be reached from the CPU (valid for modules and devices below a CPU).

Diagnostics data are not available because the current online configuration data differ from the offline configuration data.

Meaning Icon

The configured module or device and the module or device actually present are incompatible (valid for modules or devices under a CPU).

The configured module does not support display of the diagnostics status (valid for modules under a CPU).

The connection is established, but the state of the module has not yet been determined.

The configured module does not support display of the diagnostics status.

Error in subordinate component: An error is present in at least one subordinate hardware component.

FIG. 21 Diagnosis symbols for modules and devices.


FIG. 22 Configuration with two non-existing I/O modules.

FIG. 23 PLC diagnostics screen.

FIG. 24 PLC project diagnostics symbols.

FIG. 25 Diagnostics buffer recorded online events.

FIG. 26 PLC memory and CPU cycle time diagnostics.

4.1 Static Checkout

FIG. 27 Typical industrial-type MCR.

Static checkout is a process used to verify that I/O wiring is implemented correctly. It also verifies the continuity of current to and from the PLC/instrumentation. This process must incorporate the following steps:

• Provide proper grounding and electrical noise protection.

• Implement safeguards that are independent of the S7-1200 system to protect against possible personal injury or equipment damage.

• Maintain safe status of the S7-1200 low-voltage circuits, external connections to communication ports, analog circuits, all 24-V nominal power supplies, and I/O circuits. All must be powered from approved sources that meet all safety requirements.

• Provide overcurrent protection, such as a fuses or circuit breakers, to limit fault currents from damaging supply wiring.

• Inductive loads should be equipped with suppression circuits to limit voltage rise due to inductive reactions.

• Identify any equipment that might require hardwired logic for safety.

• Ensure fail-safe conditions for devices to prevent unsafe failure, which can pro duce unexpected startup or damage to equipment.

• Provide the appropriate status information to the PLC, including detailed alarms and fault information to ensure safeguards as implemented in the control-logic software.

• Provide the appropriate system-status information to the assigned HMIs to enforce implemented operator-safeguard interactions.

Static checkout of all instrumentation must be conducted before any program logic debugging. It’s a time-consuming operation and requires collaboration between the instrumentation technician and the PLC operator. PLC software tools greatly reduce the effort needed to accomplish this task. The following are typical steps used to checkout I/O connections:

• Turn each discrete input ON/OFF, and observe the associated light-emitting diode (LED) indicators on the input-module switch panel.

• Check the assigned discrete input addresses in the PLC, and confirm that input changes between 0 and 1 as the input signal changes from OFF to ON.

• Outputs should be tested while the system is in manual MODE. Using push button switches as an example for motor START/STOP, the motor should be checked using normally open/normally closed momentary switches and by verifying that the motor responds correctly.

• Outputs should be tested by using the PLC forcing function. As the bit is forced from the PLC from 0 to1, output should turn OFF to ON. Safety precautions should be taken before forcing I/O.

• Check all analog input signals, and make the needed adjustments in the sensor offset and span values. This analog signal calibration requires coordination and is time-consuming but essential to achieving accurate data acquisition and overall process control.

4.2 Safety Standards and Precautions

FIG. 28 Master control relay circuit.

Master control relays are used as a standard hardware safety technique to protect the system under emergency conditions. A master control relay is operated by START and STOP push-button switches. FIG. 27 shows a typical industrial-type MCR. Pressing the START push button energizes the master control relay and provides power to the I/O modules. Pressing the ESD or E-stops push button, as shown in the figure, will disconnect the power to the I/O modules, but the processor will continue to operate, allowing operator access to the PLC programs and software tools with complete isolation from all I/Os. MCR is a hardwired relay that is used to provide a controlled safe stop. The master control relay deenergizes the supply power to the outputs and the machine power to the controlled devices. An industrial-type master control relay is also shown in Fig. 28 along with the wiring circuit diagram.

The following are a few examples of safety-standard routine practices used in implementing process-control systems. As stated, these are universal standards, not optional actions or choices, and they must be followed:

• A step-down transformer provides isolation from high main power to the 120 Vac going to the PLC power supply (L1, L2).

• A normally closed contact Emergency Stop push button is wired in series with the MCR coil to deenergize the coil in case of an emergency and disconnects the power to all I/O modules (CPU still receives power, and its LEDs provide status information).

• Normally open/normally closed momentary push-button contacts are used for motor START/STOP operation in order to protect against accidental restart of motors after a power outage is restored.

• Two START push buttons are used simultaneously to start a machine to protect the operator's hand during startup.

• An interlocking switching mechanism is used for motors running in forward/ reverse directions. This system requires motor stopping before the reversal of running direction and must have the highest possible reliability.

• The use of an emergency shutdown (ESD) switch with all power connection to PLC modules conducted through its contacts is necessary. Activation of the ESD stops all outputs in case of any emergency situation.

• Fault-detection hardware is deployed in critical areas, such as in a hazardous chemical possibly overflowing a reactor tank, to provide backup in case of sensor or control-logic failure. Redundant PLCs are often used in critical control systems with automatic switchover for uninterrupted operation.

• PLCs have hardware and online impeded diagnostic tools, including a combination of both software and hardware. LEDs are used to indicate the status of the PLC, CPU, and I/O modules.

• Diagnostic PLC software is an essential part of every program scan cycle. The CPU provides the following diagnostic status indicators:


• Solid orange indicates the STOP mode.

• Solid green indicates the RUN mode.

• Flashing (alternating green and orange) indicates that the CPU is starting up.


• Flashing red indicates an error, such as an internal error in the CPU, an error with the memory card, or a configuration error (mismatched modules).

• Solid red indicates defective hardware.

5 Safeguard Implementation


This section presents a small sample of examples showing safety implementations in Siemens S7-1200 PLC systems. All principles included in these examples are practical situations independent of the PLC platform used for the process-control implementation. A few minor syntax modifications may be needed for other vendors' PLC environments.


Ex. 1:

A given machine-tool process requires an operator to start the conveyor system by pushing two START push-button switches at the same time in order to restrict the location/position of the operator's hands and thus guarantee maximum human protection during the startup process. The network in Fig. 29 assumes two normally open START1 and START2 push buttons, one normally closed STOP push button and one output coil for Motor 1 start.

Once the START1 and START2 push buttons are pressed, I3.0 and I3.1 become TRUE, which, in turn, makes Q3.4 TRUE, and Motor 1 runs. In the next scan, Q3.4 will latch the START1 and START2 push buttons and maintain the network TRUE status, which keeps Motor 1 running. Once the STOP push button is pressed, Motor 1 loses power and goes OFF.

FIG. 29 Two simultaneous motor's start push buttons.


Ex. 2:

FIG. 30 Forward/reverse interlocking.

FIG. 30 illustrates a line diagram of a magnetic reversing starter that uses an interlock to control the motor in forward and reverse directions.

Circuit operation: Pressing the Forward push button completes the forward coil circuit from L1 to L2, causing coil F to be energized. Energizing coil F, in turn, energizes two auxiliary contacts, F-1 and F-2. The normally open contact F-1 provides a latch around the Forward push button, maintaining coil F energized. The normally closed contact F-2 will prevent the motor from running in the reverse direction if the Reverse push button is pressed while the motor is running in the forward direction. The following is a summary of the operation of this system:

1. When the Forward push button is pressed, the normally open contact I6.0 (FWD) becomes TRUE, the normally open contact I6.2 (STOP) is still TRUE, the normally closed contact Q4.2 is TRUE, and output coil Q5.1 (F) is set. In the next scan, Q5.1 will latch the Forward push button and maintain Network 1 TRUE status. This will keep the motor running in the forward direction.

2. To stop the motor, the operator presses the STOP push button. This causes the normally open contact I6.2 (STOP) to go FALSE momentarily, which drops the sealing around the normally open contact I6.0 (FWD), causing the output Q5.1 coil (F) to deenergize.

3. When the Reverse push button is pressed, the normally open contact I6.1 (REV) becomes TRUE, the normally open contact I6.2 (STOP) turns TRUE, the normally closed contact Q5.1 becomes TRUE, and the output coil Q4.2 (R) is set. In the next scan, Q4.2 will latch the Reverse push button and maintain Network 2 TRUE status. This will keep the motor running in the reverse direction.

4. To run the motor in the reverse direction while it’s running forward, the operator must press the STOP push button before pressing the Reverse push button.

5. The F and R coils are automatically interlocked with the normally closed contact Q5.1 (F) and the normally closed contact Q4.2 (R).


Ex. 3 The network shown in Fig. 31 was discussed in Section 5. Readers can refer to that Section for further description. It shows the use of an emergency-shutdown selector switch (ESD) for protection against unusual conditions. Note the distinction from the MCR ESD contacts that are wired in series with the output and input modules. Once ESD is activated, it interrupts the power to the motor regardless of the action of the PLC scanned logic. Two networks are designed, one for starting the East Well pump E_PUMP and the other for starting the West Well pump W_ PUMP. The two pumps require similar conditions for each to be selected to run.

Common conditions for both require the system to be in AUTO mode, ESD not to be activated, and the pump motor not to fail to start. Notice that ESD has to stay inactive for either pump to run, even with all other conditions satisfied.

FIG. 31 Emergency-shutdown selector switch.


Ex. 4 The network shown in Fig. 32 was discussed in Section 5. Readers can refer to that Section for further description. It shows the use of a limit switch that is placed in the upper position of vertical Gate 1. This limit switch, VG1_FULLY_ RAISE_LS, ensures that power will disconnect (VG1_NEXT_UP is the input to the VG1_RAISE) when vertical Gate 1 does reach the upper position to protect both the motor and the structure from overload. Similar protection exists inside the motor, such as overload and temperature protection. Similar networks exist for the vertical Gate 1 next to go down.

FIG. 32 Redundant motor protection using limit switches.


Quiz and Lab Projects


1 List three issues covered in process-control layer 1, and explain what process constraints means.

2 Explain briefly what are the main tasks included in process-control layer 2.

3 What is the most standard analog I/O signal? Give a few examples for typical analog input and output process-control variables.

4 Is the PLC placed in run mode during static checkout?

5 List at least four of the basic tasks involved in creating the process-control preliminary documentation.

6 Explain briefly what are the main tasks included in process-control layer 3.

7 What are the basic three modes used in testing the S7-1200 user program?

8 A program malfunctioned, and the force output method was used to check out and debug its operation. The problem was fixed, but later during another run, the program malfunctioned again. What do you think might have caused this failure?

9 Is it possible to account for all possible future process scenarios during system checkout? How do HMIs contribute to overall system continuous enhancement?

10 Why do some machines require two START push buttons to start manually, whereas only one is necessary to start the machine?

11 How is the ESD (emergency shutdown) push button wired and included in the PLC system functionality?

12 What is the advantage of 24-Vdc I/O modules over 120-Vac modules?

13 Why does the National Electrical Code require normally open push buttons to start a motor and normally closed push buttons to stop a motor?

14 What are the components of a data-acquisition system? Explain briefly the function of each component.

15 A vertical gate is traveling between two limits, fully raised and fully lowered. One motor is used, which runs in the forward direction for raising the gate and in the reverse direction for lowering the gate. Write a ladder-logic program to protect the motor from moving in either direction if either of the two limits (forward/reverse) is reached. Add sensors as needed.

16 Explain the function of an HMI. How does it enhance the overall automation system operation and maintainability?

17 As shown in Fig. 33, the physical switch SS1 is open and in the ladder logic is forced ON. What is the status of PL1, PL2, and PL3?

FIG. 33 #17.

18 Study the ladder program shown in Fig. 34, and answer the following:

a. Explain the function of each network as programmed and documented.

b. Check each network, and verify that it implements the desired specification as shown in the documentation.

c. Troubleshoot the program, and reprogram the network (S) to work as it should based on shown and correct documentation. Use the three methods of troubleshooting described in the Section.

FIG. #18.

19 In Fig. 35, the physical switch SS2 is open, and output coil Q0.1 with tag name PL2 is forced ON. What is the status of the physical outputs PL2, PL3, and PL4?

FIG. 35 Quiz 19.

20 What is the advantage of an Alarm acknowledge page on the HMI. If the alarm sounds, how would you proceed to solve the problem?

21 What kind of problems arises if the analog input signal is coming to the PLC in a non standard format? Explain how can you solve this problem using scaling?

22 What is the most important tool(s) in a control system to identify a fault? List three such tools.


Lab 1: Basic Logic Functions Program Debugging

This laboratory will focus on the use of debugging and troubleshooting techniques covered previously.

Lab Requirements:

• Program the required networks.

• Download the program to the PLC, and go online.

• Start program debugging using the training unit or the Siemens simulator.

• Configure the Watch and Force tables to record the value of TAG_VALUE1, TAG_VALUE2, and TAG_RESULT shown in the following table.

• Use the Watch and Force tables to enter the values of TAG_VALUE1 and TAG_VALUE2.

• On the same page, configure TAG_RESULT to display the result of the word logic AND, OR, XOR, and XNOR.

Lab 2: Conveyor-System Control

The main objective of this laboratory is to learn about the methods of troubleshooting used in industrial applications. A part is moving on a conveyor line crossing a photoelectric cell.

The photoelectric cell functions primarily to count parts. The conveyor line stops after 100 parts are counted.

Detailed Descriptions:

• The START push button starts the conveyor motor after a 5-second delay. The motor must start only if the AUTO/MANUAL switch is placed in the AUTO position. The photoelectric cell should count only when the motor is running.

• When the count reaches 100, stop the conveyor after a 3-second delay.

• ON pilot light indicates the end of the sequence.

• STOP switch, when activated, takes the system to the initial condition.

• The Operator can restart the same sequence by activating the START switch.

NOTE: Use SS1 for the photoelectric cell input signal, SS2 for the motor running input indication signal, PL1 for the motor starting output signal, and PL2 for the end-of-sequence pilot light output signal.

Testing Inputs and Outputs

The following are typical steps used to check out I/O connections:

• Turn each discrete input ON/OFF, and observe the associated LED indicators on the input-module switch panel.

• Check the assigned discrete input addresses in the PLC, and confirm that input changes between 0 and 1 as the input signal changes from OFF to ON.

• Outputs should be tested while system is in manual MODE. Using push-button switches as an input for motor START/STOP, the motor should be checked using normally open/ normally closed momentary switches and by verifying that the motor responds correctly.

• Outputs also should be tested using the PLC forcing function. As the bit is forced from the PLC from 0 to1, output should turn ON from the OFF state. Safety precautions should be taken before forcing I/O.

Laboratory Requirements:

• Assign the system inputs.

• Assign the system outputs.

• Enter the networks to implement the above requirements.

• Add comments to each network.

• Download the program, and go online.

• Simulate the program operation using the training unit's I/O or the Siemens simulator, and verify that the program is running according to the process description.

Lab 3: Cascaded-Tanks Reactor

Three tanks are cascaded through a series of outlet solenoid valves. Material is discharged from tank 1 to tank 2 during the first 7 hours after the start of the process. At the end of the 7 hours, tank 1's valve closes, and Tank 2's valve opens to allow material to flow into tank 3 for 8 additional hours. In the final stage, tank 2's valve closes, and tank 3 is cleared by keeping its outlet valve open for additional 5 hours. The entire reaction takes 20 hours, after which all valves are closed. Activating the STOP push button will terminate the process and return all valves to the default closed position. The START push button initiates the entire reactor process. Please refer to Example 4.17 for the listing of the four networks used to implement this application.

Lab Requirements:

• Assign the system inputs.

• Assign the system outputs.

• Enter the needed networks (refer to Section 4)

• Download the program, and go online.

• Configure a watch table to monitor the three valves and the timing operation. Use scaled-down times in seconds instead of hours during the simulation.

• Simulate the program operation using the training unit's I/O or the Siemens simulator, and verify that the program is running according to the process description.

NEXT: Instrumentation and Process Control


All related articles   Top of Page   Home

Updated: Monday, March 9, 2015 18:51 PST