Share this

Logical error analysis of a set of PLC programs

2026-04-06 07:22:28 · · #1

1 Introduction

A Programmable Logic Controller (PLC) is a computing device used in industrial automation. It is widely used in various industries, including steel, petroleum, chemical, power, building materials, machinery manufacturing, automotive, textiles, transportation, aerospace, environmental protection, and cultural entertainment. From small household appliances to large aerospace equipment, PLCs are applied in many fields.

A typical PLC consists of a dedicated CPU, a memory, and a set of input/output ports, as shown in Figure 1. It receives signals from sensors through the input ports and sends control signals to drive connected external devices through the output ports. The control program is stored in the memory, and the system's activities are driven by the control program.

A PLC system reads signals from the input port at regular time intervals (e.g., 5 milliseconds), performs calculations, and then sends an output signal to the output port. Each "input-calculation-output" cycle is called a scan cycle. The PLC program is executed repeatedly once in each scan cycle. Simple applications of PLCs include washing machine control and elevator control. Complex applications include automatic machine tool control and automation engineering control.

PLC programming presents an unusual software programming paradigm. The design requires consideration of multiple parallel threads, their interactions, and their behavior in the time domain. Among the five main PLC programming languages, ladder logic, derived from relay control systems, cleverly handles parallel programming problems in a simple way. However, due to the inherent complexity of PLC programming and the lack of testing methods, many PLC programs still contain a large number of errors.

To address this issue, Lingxin Labs is developing a PLC testing system to provide a solution for debugging PLC programs. During the trial of this system, at least eight errors were found in four out of six simple program examples from two introductory PLC textbooks.

● A buzzer program will only trigger an alarm for one of the contestants when both contestants press their buzzer buttons simultaneously.

● In a fountain program, the water jets fail to stop spraying water as required at several designated times;

● In a traffic light control program, the green light flashing control is not working properly; when the system starts up, the green light is on in one direction, but the red light is off in the other direction; after the forced passage ends, the traffic light does not immediately return to normal operation.

● In another traffic light sequence, after the stop button is pressed, all the lights go out, but the pedestrian lights in both directions remain red.

We believe this finding is unusual. While every programmer and teacher makes programming mistakes, we have never seen such a high percentage of errors in any programming textbook. This phenomenon initially confirms the widespread and serious nature of PLC programming errors.

This article will analyze the errors in each of the above programs one by one, pointing out the causes of the errors. For most of the programs, we will provide corrected versions. We hope this analysis will help PLC programmers and teachers improve the correctness of their PLC programming. The execution principle of PLC programs and the semantics of ladder diagrams will be explained in the examples. We believe that learning by analyzing errors is a good way to master loop iteration techniques.

2. Answer-grabbing program

Title: Answer-grabbing program

Source: PLC Application Technology Development and Practice

Programming platform: Siemens S7-200

Problem description:

(1) The host controls the start button;

(2) Each of the three contestants controls their own buzzer button;

(3) All alarms will be powered off after the start button is pressed;

(4) After that, each time a buzzer button is pressed, it will power up its own alarm and lock the validity of the input signals of other buzzers.

Variable assignment:

i0.0 Host button;

i0.1, i0.2, and i0.3 are the three buttons for the first responder;

q0.0, q0.1, and q0.2 are the alarm outputs corresponding to the participants who answered the questions first;

The ladder diagram program for the quiz buzzer provided in the original book is shown in Figure 2.

Figure 2. Ladder diagram program for the quiz buzzer system.

PLC program semantics:

The semantics of the ladder diagram program described above can be expressed in a relatively concise way:

q0.0:=(i0.1orq0.0)and~i0.0and~q0.1and~q0.2;

q0.1:=(i0.2orq0.1)and~i0.0and~q0.0and~q0.2;

q0.2:=(i0.3orq0.2)and~i0.0and~q0.0and~q0.1;

Where ~i0.0 represents the logical NOT of i0.0.

The PLC program executes periodically, with each cycle lasting a very short time. In one cycle, the PLC reads in input values ​​(here, i0.1, i0.2, and i0.3), performs calculations according to the program, and then sends the values ​​of the output variables (here, q0.0, q0.1, and q0.2) to the outside. Note that the program executes repeatedly in each cycle. Within each cycle, the program executes from top to bottom and from left to right.

When a buzzer button is pressed (e.g., i0.1=1), the corresponding output (q0.0) immediately becomes 1. In the next cycle, even if the button is closed (i0.1=0), the program's output will remain 0 because the program relies on self-feedback (orq0.0). Meanwhile, because the other two program segments contain ~q0.1, their outputs cannot become 1 until the host's button i0.0 resets q0.0 to 0.

●Programming issues

If two contestants press their buttons at the same time, the alarm of the contestant who presses first will function normally, while the alarm of the other contestant will not function.

●Program Analysis

This problem is divided into three program segments, which should ideally be executed in parallel to achieve a fair result. However, the PLC's CPU can only execute programs sequentially. Therefore, once the output of the first responder is generated, the output of subsequent programs is immediately blocked. Consequently, when both buttons are pressed simultaneously, only one of them receives a response.

The programming model of PLCs originates from relay circuit control systems, in which the three program segments mentioned above correspond to three parallel-running circuits. However, after being transferred to the CPU, these programs must be executed sequentially. The conflict between the parallel model and sequential execution is the cause of many program errors. This problem was analyzed in the author's previous paper [1].

Implementing PLC parallel semantics on a machine with sequential execution is possible. However, various pitfalls still need to be considered. The first attempt below contained an error, which was corrected in a subsequent program, allowing it to pass the program tests.

●Program Fix Attempt

A natural idea to overcome the above problem is to use intermediate variables to store the output of each program segment. This idea leads to the following program implementation (see Figure 3):

Figure 3 shows the implementation diagram of the program correction attempt.

When using this program, if two participants press their buttons simultaneously, both corresponding alarms will sound at the same time. However, in the next cycle, the outputs of both alarms will simultaneously return to 0. This is because each response invalidates the other's response, and both responses will simultaneously invalidate the other's response.

●Final Procedure

The following procedure overcomes the above problems and passes basic test checks (see Figure 4).

The difference between this program and the previous one is that it broadens the scope of variables such as q0.0. Therefore, once q0.0 is 1, its value will continue to be maintained as long as the host button is not pressed.

Figure 4. Basic test results

3 Fountain Program

Title: Application of PLC in Fountains

Source: PLC Application Technology Development and Practice

Programming platform: Mitsubishi FX2N series

Problem Description

(1) The fountain has three sets of nozzles: a, b, and c.

(2) After pressing the start button, group a sprays first, stops after 10 seconds, and then groups b and c spray simultaneously;

(3) After spraying b and c for 10 seconds, b stops, and after another 10 seconds, c stops;

(4) a and b spray again, and after 5 seconds, c also sprays. After 10 seconds, they all stop.

(5) After another 5 seconds, return to steps (2) to (4) above;

(6) After pressing the stop button, all three groups of nozzles (a, b, and c) will stop.

Input/output variable assignment:

x0001: Start button

x0002: End button

y0001: Group A nozzles

y0002: Group B nozzles

y0003: Group C nozzles

Internal relays: m0-m5

Timer allocation (see Figure 5):

t0: Group A sprays for 10 seconds; 0-10

t1: Groups B and C spray for 10 seconds; 10-20

t2: Group C sprays for 10 seconds; 20-30

t3: Groups A and B spray for 5 seconds; 30-35 seconds

t4: Groups a, b, and c spray for 10 seconds; 35-45

t5: Groups A, B, and C stop spraying for 5 seconds; 45-50

Compared to the previous program, this program adds timers such as t0 and t1. The timers are identified by 't', with the timer variable name above it and the predetermined timing delay below. This example uses a ton type timer. This type of timer starts counting as soon as the input changes from 0 to 1. During the counting process, the input must remain at 1. Once the timer expires, its corresponding variable immediately changes from 0 to 1. If the input changes to 0 during the counting process, the counting stops. After the timer expires, as long as the input remains at 1, the timer variable also remains at 1. Once the input changes to 0, the timer variable also changes to 0. In this example, the timer counts in tenths of a second increments.

This program contains three errors: some of its nozzles fail to stop at the scheduled stop time and fail to start at the scheduled start time.

Program error (1): As required, the eruption of group C should stop 20 seconds after the program starts, but the program does not stop the eruption of group C.

Cause Analysis

The eruption of group c is controlled by m1, m2, and m3, which control the first, second, and third eruptions of group c, respectively. After the second eruption, m2 is 0, and the eruption should stop. However, during debugging, it was found that the output of group c (y0002) continues to be 1. Single-step debugging revealed that m1 is 1 at this time, causing the output of group c to continue. Analysis showed that the ladder diagram generating m1 was incorrect. m1 should be used to generate feedback, but the program used the output variable y0001 of group b. This variable was reset to 1 exactly after the second eruption of group c, thus causing group c to continue erupting. Changing this to m1 eliminates this error.

Program error (2): Group A eruption should restart 50 seconds after the program starts, but it did not start in actual operation.

Cause analysis:

This is a simple error where the timer was set incorrectly. The timer t4 should be set to 5 seconds (50), but it is incorrectly written as 100 in the ladder diagram (the instruction list program in the book also writes 50, so this is an error in the ladder diagram).

Program error (3): After correcting the above two errors, the program still failed the test. Group C should not have started erupting after 50 seconds, but it did erupt during actual operation.

Cause analysis:

After 50 seconds, the program enters the next cycle. How the program should run at this point is not clearly described in the original book, which constitutes an incomplete description. Based on the program's implementation, it's clear the author's intention is to replay the entire eruption process after 50 seconds. Based on this understanding, the program should start the eruption of group A after 50 seconds, but the program's execution result is that not only group A erupts, but group C also erupts, the latter behavior not conforming to the rules.

The reason for this phenomenon is that y000 is used to implement feedback in the ladder diagram of m0. This error is similar to the first error, except that this method works fine in one cycle but causes problems in the second cycle. Replacing y000 with m0 in the diagram will eliminate this error.

After eliminating the above problems, the resulting trapezoidal diagram is shown in Figure 6.

4. Traffic light control procedures at intersections

Title: Traffic Light Control Program

Source: PLC Application Technology Development and Practice

Programming platform: Omron CQM1 series

●Task Description

Operating sequence: Start button, north-south green light, east-west red light, east-west green light, north-south red light. This sequence repeats in a loop.

Timing control: (90-second cycle)

●Main Road

North-South left turn signal: Green for 10 seconds, Yellow for 2 seconds, Red for 78 seconds;

North-South Straight Traffic Lights: Red for 10 seconds, Green for 30 seconds, Flashing Green for 3 seconds, Yellow for 2 seconds, Red for 45 seconds;

The left-turn and straight-ahead lights for east and west directions operate similarly, but with a 45-second delay. Pedestrian lights function the same as the straight-ahead lights on main roads.

●Forced access control

When the power switch is turned on, the green light for the power direction will illuminate. When the power switch is turned off, the green light will flash for 3 seconds, and normal control will resume.

Flashing control: 0.5 seconds on, 0.5 seconds off, for a total of 3 seconds;

This program is quite long, so it's inconvenient to copy it all here. Only a few errors in the program are pointed out here, along with the relevant code segments.

Figure 7 shows the implementation of the program.

Program error (1): Blinking control error. The blinking process is controlled by a dedicated program segment. The program should output 1 every 0.5 seconds, then 0 every 0.5 seconds, continuously looping. Figure 7 shows the implementation of this program in the book:

Only one timer, the TIMM050, is used, with a timing unit of one-tenth of a second. The Omron TIMM timer operates similarly to the Siemens TN timer: timing starts when the input is 1, and immediately stops when the input changes to 0, resetting the timer variable output to 0.

The initial value of tim050 is 0. This value is inverted and fed into Timer 1 to start the timer. After 5 units, the timer generates a signal of 1. This signal is then fed back to the timer, returning a value of 0. This input immediately resets the timer output to 0. Therefore, this program can only generate a very brief 1, instead of a sustained 0.5 seconds of 1. When this signal is used to drive a green light, it cannot produce a normal, uniform flashing effect.

Program correction (see Figure 8)

Figure 8. Program Correction Diagram

Two timers are used here. When the first timer, tim050, expires, its output signal 1 is sent to the second timer, tim051, to start the latter's timing. However, tim051 needs 5 units to expire. During this time, the input of tim050 is still 1, so it can continue to hold the 1 for 0.5 seconds, thereby generating a pulse that changes uniformly every 0.5 seconds.

Program error (2): During the initial startup phase of the system, the green light for north-south directions is on, but the red lights for left turns and straight ahead for east-west directions are not on simultaneously.

Cause Analysis: Due to the length of the relevant program, it is inconvenient to display it here. We will only analyze the cause of the error and the solution. The original program uses a method of sequentially activating each color light. That is, after 10 seconds of left-turn green light, the straight-ahead green light is activated, followed by a flashing green light after 30 seconds, a yellow light after 2 seconds, and then a red light after 55 seconds. However, when running in this order, the initial 10 seconds of north-south straight-ahead red light is missing, the 45 seconds of east-west left-turn red light is missed, and finally, the 55 seconds of east-west straight-ahead red light is also missed. To change this, the latter part of the program needs to be modified, and two timers need to be introduced to divide the red light control into two segments.

People might think the previous problem wasn't serious because the original program returned to normal after one minute of startup. However, the error in the forced-pass control below is quite serious. Forced-pass refers to the manual pressing of a forced-pass switch in the corresponding direction when an emergency vehicle arrives at an intersection, causing the green light for that direction to illuminate and the red light for the other direction to illuminate. After the emergency vehicle passes, the forced-pass switch is pressed, the green light for the forced-pass direction flashes three times, and then the system returns to its original operation.

Program error (3): After the forced access button is released, the green light in the forced access direction should flash three times and then turn off, but in reality, the green light does not flash and stop as required, but remains on.

Cause analysis:

We will analyze this problem using the east-west straight-ahead green light control program segment as an example.

In this program, 100.12 is the output variable controlling the east-west green light. The forced-pass signal in this direction is controlled by hr0.00. When the forced-pass button is pressed, this variable becomes 1, causing 100.12 to output 1, and the green light illuminates. After the forced-pass button is released, this path is cut off, hr0.01 becomes 0, and hr0.03 becomes 1 (the process is omitted here). The path containing hr0.03 will generate a 3-second flashing pulse. The programmer's intention is to create a green light flashing process after the forced-pass signal ends. However, due to the feedback of variable 100.12, once this variable is 1, it will automatically remain at 1. There are only two ways to reset it to 0: one is when the 30-second timer expires (tim010), and the other is the forced-pass signal hr0.01 in the other direction. After the forced-pass signal in the same direction ends, generally neither of these two signals will turn to 1, so the green light cannot stop immediately. The system does not produce the intended effect.

This is a serious error because the light should have flashed green before turning red, but the system kept it on green. Such a system is unacceptable.

Solving this problem is a bit more complex. Since our main task is to find the error, we will not discuss how to correct it here.

5. Traffic light control procedure at the second intersection

This section discusses an error in a traffic light control program from another book. This program did not handle complex issues such as forced traffic control, but it separated pedestrian control from main road control, resulting in errors in pedestrian control.

Title: Traffic Light Control Program

Source: Practical Subroutines for PLC Application Development

Programming platform: Siemens S7-200

Timing control: (90-second cycle)

For left turns on major north-south roads, green for 10 seconds, green for 30 seconds, flashing green for 3 seconds, yellow for 2 seconds, and red for 45 seconds;

East-west pedestrian crossing: Red for 13 seconds, green for 27 seconds, green flashing for 3 seconds, red for 47 seconds;

East-west main road: Red for 45 seconds, left turn green for 10 seconds, green for 30 seconds, flashing green for 3 seconds, yellow for 2 seconds;

North-South Pedestrian Crosswalk: Red for 58 seconds, Green for 27 seconds, Green flashing for 3 seconds, Red for 2 seconds.

Note:

(1) Green flashing includes turn signal green light and turn signal green light;

(2) East and west sidewalks refer to the sidewalks at the east and west ends.

Tests showed that the program ran correctly in sequence, but a problem occurred when shutting down.

Program error: When the system stop switch is pressed, most of the lights go out, but red lights are on on the pedestrian crossings in both directions.

Program Analysis:

We will take the calculation of variable q1.3, which controls the east-west pedestrian red light, as an example for analysis. The relevant program segment will be extracted and analyzed separately below (see Figure 10).

Figure 10. Analysis diagram of relevant program segments

As shown in the diagram, when m0.4 is 0, q1.3 will output 1. When t7 and t8 are 0, m0.4 must be 0. The system stop switch is i0.2, which, when pressed, will make m0.1 0. This variable is the main variable controlling the system's activity; its 0 will make a series of variables 0, including t7 and t8. However, this does not turn off the red lights at the east and west pedestrian crossings. The red lights at the north and south pedestrian crossings use a similar procedure, so they are also not turned off.

Program correction:

Simply add m0.1 directly to the pedestrian red light control.

6. Conclusion

This article analyzes four program examples from two PLC textbooks, identifying eight errors of varying degrees and analyzing their causes. We hope this analysis will help programmers reduce programming errors.

The purpose of this article is to reveal the prevalence of errors in PLC programs. These errors cannot be simply attributed to the author's mistakes; the main reasons are the complexity of programming patterns and the lack of testing methods.

Mistakes are a universal human behavior. For complex objects like computer programs, errors occur frequently. The programming process itself is a continuous process of trial and error correction. However, in the PLC field, offline debugging tools are relatively weak; the best debugging method to date remains on-site debugging, but this method is extremely time-consuming, and most teachers and students do not have access to such resources. This is the fundamental reason for the high error rate in programs.

Read next

CATDOLL 146CM Vivian TPE

Height: 146cm A-cup Weight: 26kg Shoulder Width: 32cm Bust/Waist/Hip: 64/54/74cm Oral Depth: 3-5cm Vaginal Depth: 3-15c...

Articles 2026-02-22