Facebook
Google
GitHub
Linkedin
S7-1200 PLC alternates between RUN and STOP
- Thread starter HBAZERT
- Start date
"Symptoms do not appear in TIA Portal" is itself the most useful clue here, because it tells you the CPU is not staying in STOP long enough for the online view to capture it.
The first thing I would check is whether OB 82 / OB 121 / OB 122 actually exist in your program. This is the most common cause of exactly this behaviour on S7-1200/1500: if those error OBs are missing, the CPU has no handler for a module fault, and its default reaction is to go to STOP. Depending on the fault it can bounce back to RUN, which looks like "alternating".
The sequence I would work through:
1) Read the diagnostic buffer - but not by staring at the online view. The buffer is circular, and if the CPU returns to RUN quickly the entries get overwritten before you can see them. Two ways to catch it:
- Use the CPU's built-in web server. It keeps a retrievable diagnostic buffer, and you can pull it without a TIA online connection.
- Or connect immediately after a STOP event and read the buffer before it rolls over.
Record the event IDs, not just the readable text - the IDs identify which subsystem reported the event.
2) Check for the error OBs (82 / 121 / 122). Missing blocks mean every module fault takes the CPU down. Adding them changes the CPU's reaction from "go to STOP" to "keep running with a diagnostic entry", which by itself often converts an intermittent stop into a visible, debuggable problem.
3) Check the supply voltage and grounding. A dip below the CPU's tolerance causes a restart cycle that looks exactly like alternating RUN/STOP. If you have a scope, watch the 24 V rail during the event.
4) Check the expansion modules: firmware compatibility with the CPU, backplane seating, and whether any module was added or swapped recently. CPU/signal-module firmware mismatches are a classic.
5) Search the program for STOP instructions, and for anything that can trigger a restart. Rare, but it happens.
6) Check the cycle time. If OB1 or a cyclic interrupt OB runs long, you get a cycle-time violation and a stop. Read the measurement while the machine is doing its heaviest work, not while it is idle.
One more signature worth knowing: if the CPU goes to STOP with no buffer entry at all and no error OB is present, that absence is itself consistent with the missing-OB case - the CPU stops before it can log anything meaningful.
If you can post the diagnostic buffer event IDs (a screenshot of the buffer is fine), I can narrow it down further - the IDs are what actually identify the cause.
The first thing I would check is whether OB 82 / OB 121 / OB 122 actually exist in your program. This is the most common cause of exactly this behaviour on S7-1200/1500: if those error OBs are missing, the CPU has no handler for a module fault, and its default reaction is to go to STOP. Depending on the fault it can bounce back to RUN, which looks like "alternating".
The sequence I would work through:
1) Read the diagnostic buffer - but not by staring at the online view. The buffer is circular, and if the CPU returns to RUN quickly the entries get overwritten before you can see them. Two ways to catch it:
- Use the CPU's built-in web server. It keeps a retrievable diagnostic buffer, and you can pull it without a TIA online connection.
- Or connect immediately after a STOP event and read the buffer before it rolls over.
Record the event IDs, not just the readable text - the IDs identify which subsystem reported the event.
2) Check for the error OBs (82 / 121 / 122). Missing blocks mean every module fault takes the CPU down. Adding them changes the CPU's reaction from "go to STOP" to "keep running with a diagnostic entry", which by itself often converts an intermittent stop into a visible, debuggable problem.
3) Check the supply voltage and grounding. A dip below the CPU's tolerance causes a restart cycle that looks exactly like alternating RUN/STOP. If you have a scope, watch the 24 V rail during the event.
4) Check the expansion modules: firmware compatibility with the CPU, backplane seating, and whether any module was added or swapped recently. CPU/signal-module firmware mismatches are a classic.
5) Search the program for STOP instructions, and for anything that can trigger a restart. Rare, but it happens.
6) Check the cycle time. If OB1 or a cyclic interrupt OB runs long, you get a cycle-time violation and a stop. Read the measurement while the machine is doing its heaviest work, not while it is idle.
One more signature worth knowing: if the CPU goes to STOP with no buffer entry at all and no error OB is present, that absence is itself consistent with the missing-OB case - the CPU stops before it can log anything meaningful.
If you can post the diagnostic buffer event IDs (a screenshot of the buffer is fine), I can narrow it down further - the IDs are what actually identify the cause.
