The CPU Not Responding message means the TD200 is not completing communication with the S7-200 CPU. Because the PLC program can still be uploaded, first separate TD200 communication from CPU operation: inspect the TD200 configuration in the uploaded data block, identify the configured M bits for its function buttons, and trace those bits through the STL program. Wiring physical Start, Stop, and Reset buttons to spare inputs can bypass the TD200 commands and test the machine control path, but it does not by itself prove that the TD200 or its communication link is healthy.
What the CPU Not Responding Message Means
The message identifies a failure in the communication path between the TD200 and the S7-200. That path includes the display, its connection, the configured communication settings, and the CPU interface used by the display. A successful program upload establishes that the CPU responds through the programming connection; it does not establish that the TD200 is using a working connection or compatible configuration.
| Observation | What it establishes | What remains to test |
|---|---|---|
| The S7-200 program uploads successfully | The CPU can respond through the programming path. | TD200 wiring, configuration, and communication path. |
| The TD200 shows CPU Not Responding | The display is powered and executing far enough to report a communication failure. | Connection integrity and matching communication configuration. |
| Some STL networks convert to Ladder | Those networks use instructions and structures representable in Ladder. | Nonconvertible STL must be reviewed directly. |
| Start, Stop, and Reset locations are unknown | The visible functions have not yet been mapped to program operands. | TD200 configuration data and M-bit cross-references. |
Do not begin by rewriting the STL program. Establish whether the problem is communication, command mapping, or application logic. These are separate fault domains and require different tests.
Locate the TD200 Start, Stop, and Reset Bits
The TD200 configuration is stored in the program data block. That configuration specifies which M bits represent the TD200 function buttons. Start with those configured M-bit operands rather than searching the STL source for the words “Start,” “Stop,” or “Reset.” Comments and symbols may be missing from an uploaded program, while the actual operands remain visible.
- Open the uploaded project’s data block.
- Find the TD200 configuration area and record every M bit assigned to a display function button.
- Use the programming software’s cross-reference or operand search for each recorded M bit.
- Inspect every read, write, set, reset, and transfer involving those operands.
- Follow any intermediate M bits until the logic reaches the machine run request, stop path, or reset logic.
A function-button bit may not drive an output directly. It can set a latched run request, clear another memory bit, enter a sequence transition, or participate in permissive logic. Reset may similarly acknowledge several conditions instead of acting as one direct command. Trace both the immediate use and downstream state logic before replacing any operand.
Run the Diagnostic Sequence
Diagnose the TD200 message before changing control logic. Otherwise, a program modification can make the machine run while leaving the original display fault unresolved.
- Record the baseline. Note whether CPU Not Responding appears continuously, only during startup, or intermittently. Observe whether any TD200 screens or values update.
- Confirm CPU state. Check the CPU indicators and programming-software diagnostics. A successful upload confirms access but does not prove that the application is executing normally.
- Inspect the physical path. Check the TD200 connection for loose conductors, damaged connectors, incorrect termination, shield or grounding problems, and electrical noise. Compare the installed wiring with the equipment documentation.
- Compare communication configuration. Read the TD200 configuration from the project and compare it with the installed device and CPU port configuration. Verify every displayed setting rather than substituting assumed defaults.
- Check port ownership. Determine whether application code or another device reconfigures or occupies the CPU communication interface. Review startup and communication instructions in the STL source.
- Test button operands online. If communication becomes active, monitor the configured M bits while pressing each TD200 function key. Each key should affect its assigned operand according to the configuration.
If the message persists while the programming connection works, concentrate on the components unique to the TD200 path. If both interfaces fail, expand the investigation to CPU power, CPU operating state, and the shared electrical environment.
Replace TD200 Commands with Physical Inputs
Physical buttons can provide an independent command source for Start, Stop, and Reset. Use spare PLC inputs, but preserve the original machine-state logic, permissives, and shutdown behavior. The cleanest change maps each physical input into the same internal request consumed by the existing application rather than forcing outputs or bypassing sequence logic.
- Identify the configured TD200 M bits and trace them to the internal command requests.
- Select spare inputs and verify their electrical suitability from the CPU or expansion-module documentation.
- Wire the pushbuttons according to the existing control-voltage design and site electrical requirements.
- Document which input replaces each TD200 command.
- Modify the logic at the command-request layer. Keep safety functions and hardwired protective circuits independent of ordinary display or PLC commands.
- Disable or isolate the original TD200 contribution so a stuck or stale M bit cannot create a second command source.
- Download the controlled change and test each command separately.
Start is normally treated as a momentary request that enters existing seal-in or sequence logic. Stop must return the process to its intended stopped state even if the Start request remains active. Reset should acknowledge only the conditions already handled by the original reset path; it must not conceal an active fault or defeat a permissive.
Verify the Repair and the Bypass
Verification must distinguish three outcomes: restored TD200 communication, successful physical-button control, and correct machine behavior. Passing one test does not imply that the others passed.
| Test | Expected result | Failure implication |
|---|---|---|
| TD200 communication test | The message clears and displayed data updates. | The display communication path remains faulty. |
| TD200 key monitoring | Each configured M bit changes only for its assigned function. | The configuration, key assignment, or communication is incorrect. |
| Physical Start test | The input creates the normal run request only when permissives allow it. | The mapping bypasses or fails to reach the original control path. |
| Physical Stop test | The run request clears and the process reaches its designed stopped state. | Stop logic, latching, or sequence handling requires correction. |
| Reset test | Eligible latched conditions clear; active conditions remain indicated. | The reset path is incomplete or overly broad. |
| Power-cycle test | No unintended Start, Reset, or retained command occurs. | A stale or retentive state is influencing startup. |
Monitor the physical inputs, TD200 M bits, internal requests, and final control states together. This reveals whether a command is lost at the input layer, blocked by a permissive, or consumed by sequence logic.
Recurring Pitfalls
- Treating successful upload as proof of TD200 communication: it verifies only the programming path used for that upload.
- Searching only converted Ladder: the required M-bit logic may remain in STL because its instruction pattern cannot be represented faithfully in Ladder.
- Searching only for labels: an uploaded project may lack meaningful symbols. Search the configured operands from the data block.
- Replacing outputs instead of commands: forcing an actuator path can bypass interlocks and sequence control. Map physical buttons into the existing request layer.
- Leaving two command sources active: TD200 bits and physical inputs can conflict or create an unexpected restart. Define their relationship explicitly.
- Calling the bypass a TD200 proof test: successful physical buttons prove the PLC application path and field inputs. They do not prove the TD200 hardware, configuration, or connection.
FAQ
Where are TD200 function button bits configured in an S7-200?
Find the TD200 configuration in the program data block. It specifies the M bits assigned to the display’s function buttons; cross-reference those operands to locate the Start, Stop, and Reset logic.
Why does a TD200 say CPU Not Responding when I can upload the PLC program?
The upload proves that the CPU responds through the programming connection. The TD200 can still have a separate wiring, port-configuration, or communication-path problem.
Why will some S7-200 STL code not convert to Ladder?
Some STL instruction sequences do not have an equivalent Ladder representation. Review those sections in STL and search directly for the M-bit operands assigned in the TD200 data-block configuration.
Can physical Start, Stop, and Reset buttons replace a TD200?
Yes, if spare inputs are electrically suitable and the program maps them into the existing internal command paths. Preserve permissives, latches, sequence handling, and independent safety functions.
Does a working physical-button bypass prove the TD200 is good?
No. It proves the PLC input and application-control path can operate without the display. Clear the CPU Not Responding message and monitor the configured TD200 M bits to verify the display path.