Resolving SINAUT TIM 3V Restart Loop from Phantom PROFIBUS Slaves

Resolving SINAUT TIM 3V Restart Loop Caused by Phantom PROFIBUS DP Slave Entries

The SINAUT TIM 3V communications module (Siemens order number 6NH7800-3AA00) is widely used as a protocol converter between SIMATIC S7-300 stations and IEC 60870-5-101 / IEC 60870-5-104 telecontrol masters, including VICOS RTU and ABB HMI gateways. Although the module is mechanically and electrically robust, it is sensitive to mismatches between the STEP 7 hardware configuration loaded into its internal database and the actual physical PROFIBUS DP topology. A common field symptom — a continuously flashing K-Bus LED followed by a spontaneous module restart and a complete loss of communication to the destination node — is almost always traceable to one of three causes:

1. PROFIBUS DP slave objects configured in HW Config that are not physically present on the DP segment.
2. DP slave station addresses that duplicate addresses actually used by other nodes.
3. DP configuration data that was downloaded to the TIM but the module was not hardware-reset, leaving stale mirror tables.

This reference documents the exact root cause, the resolution procedure used in the field, and the supporting commissioning / firmware / security context that every controls engineer working with the TIM 3V must understand before going on-site.

1. Problem Description

1.1 Reported Symptom Set

Engineer field notes from the originating case (CPU 315-2DP, VICOS RTU master, ABB HMI on the serial side):

• TIM 3V module parameterised offline with the Siemens ParaM tool for VICOS RTU.
• .par file exported, .awl STL source generated, imported into the STEP 7 project as an external source container.
• Source compiled without errors, blocks downloaded to CPU 315-2DP.
• On the first STOP → RUN transition the TIM performs a self-test (K-Bus LED flashes for several seconds).
• Instead of settling into the steady-state run mode, the TIM restarts spontaneously. K-Bus LED again begins flashing, and the cycle repeats indefinitely.
• No data exchange is established with the destination node (ABB HMI / VICOS RTU master). Process image is static at the last known good value.

1.2 Why the Symptom Is Misleading

The K-Bus LED flash is a normal part of the TIM's boot sequence; engineers who have only seen bench-top commissioning often interpret it as a healthy self-test. The diagnostic trap is that the LED pattern looks identical for both normal boot and fault-triggered reboot. The discriminator is the time interval: a healthy module settles within roughly 30 – 60 seconds and transitions to a steady ON or a slow activity blink. A module caught in the restart loop never settles — the LED pulse repeats every 20 – 90 seconds for as long as power is applied.

2. Root Cause Analysis

2.1 STEP 7 HW Config Mirrored into the TIM

Although the TIM 3V is logically a "telemetry" module rather than a "DP master", it still uses the STEP 7 HW Config image of the local rack for two purposes:

1. To resolve S7 partner station numbers in its routing table.
2. To build an internal PROFIBUS DP slave enumeration that it cross-checks against its own RS-485 / MPI port activity.

When HW Config contains PROFIBUS DP slave objects (ET 200S, ET 200M, DP/AS-I links, third-party DP slaves, frequency inverters on PROFIBUS, etc.) that are not physically connected to the DP segment, the TIM's bootstrap routine attempts to perform an initial DP diagnostic poll on each configured station address. Any missing slave that does not respond within the DP time-out window raises a fatal diagnostic event inside the TIM, which the module's watchdog treats as an unrecoverable bus fault and triggers a controlled restart. The restart re-enters the same code path and therefore the same fault, producing the observed loop.

2.2 Why Hardware Reset Is Mandatory After Re-Download

The TIM retains two persistent structures across STOP / RUN transitions:

• The compiled configuration image (refreshed on every download).
• The dynamic partner discovery table (built up the first time the module sees a healthy bus, and only cleared by a hardware reset or by a "Reset to factory defaults" service action).

If a download replaces the configuration image but the dynamic table still references slave addresses from a previous, now-removed configuration, the TIM runs two contradictory pictures against the same physical bus. The only safe way to reconcile the two is to issue a hardware reset on the module — STEP 7 online → "Operating Mode" → "Hardware Reset", or the equivalent toggle of the mode selector on the front of the TIM.

3. Resolution Procedure

Step 1 — Audit the HW Config

Open the STEP 7 project containing the S7-300 station in which the TIM is mounted. In HW Config, list every PROFIBUS DP slave attached to the same PROFIBUS subnet as the CPU 315-2DP. Cross-reference the list against the physical bus using the DP station addresses you can read with a PROFIBUS diagnostic tool (e.g., Amprolyzer, Softing PROFINET Diagnostics, or the Siemens PRONETA utility).

Step 2 — Remove Phantom Slaves

Delete every DP slave object whose address does not respond on the physical segment. Pay particular attention to:

• Slaves that were decommissioned but left in the configuration for documentation.
• Slaves used only during factory acceptance test (FAT) and not part of the operational plant.
• Slaves on a DP segment that was rerouted or replaced with PROFINET during a modernisation.
• Slaves from a copy/paste of a sister station's HW Config.

Step 3 — Compile and Download

Re-compile HW Config, generate the system data (SDB), and download to the CPU 315-2DP. Then re-generate the TIM parameter file with ParaM and import the resulting .awl source, compile, and download to the CPU. The TIM will receive the new image during the next STOP / RUN transition of the CPU, but will not yet be in a consistent state because the dynamic partner table still references the old slave addresses.

Step 4 — Hardware-Reset the TIM

Issue a hardware reset on the TIM. From STEP 7, the sequence is:

1. Right-click the TIM in HW Config or in the online station view.
2. Select Target System → Operating Mode → Hardware Reset.
3. Confirm the prompt. The TIM will briefly drop off the backplane and reappear.
4. Watch the K-Bus LED. The first flash is the self-test; the LED should then transition to a steady state within 30 – 60 seconds.

If you do not have an MPI / Ethernet online connection to the TIM, perform the same reset by toggling the mode selector on the front of the module: MRES → STOP → RUN, holding MRES for roughly 3 seconds until all status LEDs extinguish briefly.

Step 5 — Verify Communication

From the VICOS RTU master or the ABB HMI diagnostic page, force a class-1 interrogation and confirm process values are updating on both sides of the IEC 60870-5-101 link. On the TIM, the SF (group fault) LED must be OFF, the BF (bus fault) LED must be OFF, and the K-Bus LED must show the steady-state activity pattern.

4. Verification Checklist

5. SINAUT TIM 3V Module Reference

5.1 Family Overview

The TIM (Telecontrol Interface Module) family is part of the SINAUT spectrum and is engineered for star, line, and mesh topologies over classical WAN media as well as Ethernet / IP. The relevant variants for legacy S7-300 stations are:

5.2 Front-Panel LEDs and Their Meaning

6. IEC 60870-5-101 and -104 Protocol Support

The TIM 3V was designed primarily as a serial IEC 60870-5-101 gateway. Subsequent TIM 3V-IE / -IE Advanced variants added native IEC 60870-5-104 support over Ethernet. Engineers integrating ABB HMI panels with a VICOS RTU master through a TIM should be aware of the following parameterisation facts:

• The IEC 60870-5-101 link layer must be configured for either balanced (full-duplex, point-to-point) or unbalanced (multi-drop, polled) mode. The TIM supports both, but unbalanced mode requires explicit poll/response timeouts in the ParaM tool — defaults are 5 s for class-1 and 10 s for class-2.
• The common address (CA) of the TIM must match the slave address expected by the VICOS RTU master. Mismatched CAs are the second most common cause of "no communication" symptoms after the HW Config mismatch described above.
• For IEC 60870-5-104 on a TIM 3V-IE, ensure the TCP port (default 2404) is not blocked by an intermediate firewall. The TIM uses one TCP connection per partner; if NAT is in play, the partner must be reachable on the public IP and the TIM must be configured with the master's public IP.
• Clock synchronisation in IEC 60870-5-101 uses the C_CS_NA_1 (command 0x67) and M_CS_NA_1 (command 0x65) ASDUs. The TIM propagates these to the S7 station time. In Master WAN role, clock synchronisation is now correctly repeated in TIM firmware V1.2 — see the official release note from Siemens linked below.

Reference: Siemens Support Entry 24173192 — Sales and delivery release SINAUT TIM 3V-IE Advanced V1.2.

7. HW Config Discipline: Avoiding Phantom Slaves

The phantom-slave class of fault is a process problem, not a product bug. The fix is administrative as much as technical. Treat the HW Config as a live document that must always mirror the physical rack — anything else is debt that will eventually manifest as a field fault.

7.1 Recommended Commissioning Discipline

1. After any topology change (added, removed, or relocated slave), open HW Config immediately and reflect the change before the next cold start.
2. Run a Compare Offline / Online in HW Config at every planned shutdown. Resolve every difference before powering back up.
3. Keep a printed PROFIBUS station list with each cabinet — physical evidence beats database memory.
4. After every download, perform a hardware reset of the TIM rather than relying on STOP / RUN transitions to refresh the dynamic table.
5. Reserve station addresses 0, 126, and 127 in the project documentation even when they are unused.

7.2 Diagnostic Buffer Interpretation

The TIM's diagnostic buffer uses the same encoding as any other S7-300 module. Entries that point at a phantom-slave fault typically look like:

Event 1 of  10:  Station failure
Event ID    :  0x0E08
Description :  Distributed I/O: station failure
Address     :  DP slave, station address 14
Mode        :  Coming / Going

If you see repeated 0x0E08 events that "Coming" and never "Going", the slave at that address is not on the bus. Cross-reference with the PROFIBUS diagnostic tool. If the diagnostic tool shows no device at that address, you have a phantom-slave situation.

8. Firmware Update Procedure for TIM 3V

Firmware updates for the TIM 3V (and the closely related TIM 4R for S7-400) are executed from STEP 7's online interface. The procedure and the file-naming discipline are documented by Siemens.

8.1 STEP 7 Update Workflow

1. Open the STEP 7 project containing the TIM and establish an online connection.
2. Right-click the TIM in HW Config → Target System → Firmware Update.
3. Select the firmware file (.upd) matching the module's hardware variant — TIM 3V, TIM 3V-IE, or TIM 3V-IE Advanced. Do not select a file for a different variant; the loader will refuse mismatched files but the cost of being wrong is described below.
4. Confirm and wait for the update progress to complete. Do not interrupt power.
5. After the update, the module performs an automatic restart.

8.2 Recovery if the Module Becomes Unreachable

1. Power-cycle the S7-300 rack while holding the TIM's MRES button.
2. Release MRES after approximately 5 seconds. The TIM should enter its bootloader mode, indicated by a slow synchronous blink on all LEDs.
3. From STEP 7, retry the firmware update using the correct file.
4. If the bootloader does not engage, the module must be returned to Siemens Repair.

9. Security Considerations

The TIM family has been the subject of multiple security advisories. The most consequential is ICSA-15-335-03, which covers vulnerabilities in CP 343-1, TIM 3V-IE, TIM 4R-IE, and CP 443-1. The relevant Siemens updates are referenced by Siemens Security Advisory CISA ICS Advisory ICSA-15-335-03.

For any operational deployment, apply the latest firmware recommended by Siemens ProductCERT and follow the hardening checklist in the TIM manual:

• Restrict Ethernet access to the TIM via ACL on the switch port. The TIM does not implement role-based authentication on its web interface in legacy firmware; assume that anyone with IP reach can issue administrative commands.
• Disable unused services (FTP, telnet, HTTP) on the TIM 3V-IE / -IE Advanced where the firmware exposes the toggle.
• Treat the IEC 60870-5-104 path as a control-system trust boundary. Place the TIM behind a stateful inspection firewall that allows only the master's source IP on TCP 2404.
• Enable logging on the master side and monitor for unexpected ASDUs. Unauthorised C_RC_NA_1 (command 0x44) or C_SC_NA_1 (command 0x2D) traffic is a strong indicator of an active attack.

10. IEC 60870-5-101 Cause-of-Transmission Quick Reference

When verifying that the IEC 60870-5-101 link is healthy on a TIM 3V, the following cause-of-transmission (Cot) codes are the ones you will see in the VICOS RTU master log or in the ABB HMI event page:

If the log shows only 0x14 from the master and no 0x20 responses from the outstation, the link is open at the data-link layer but the application layer is silent — almost always a configuration issue, not a wiring issue.

11. Diagnostic Flowchart

[K-Bus LED flashing & module restarting]
                │
                ▼
   Does STEP 7 see the TIM online?
    ┌───────────┴───────────┐
   YES                      NO
    │                       │
    ▼                       ▼
Open diagnostic       Check backplane
buffer. Look for      connector, 24 V
0x0E08 / station      supply, slot
failure events.       alignment.
    │
    ▼
List every DP slave in
HW Config. Compare to
physical bus.
    │
    ▼
Delete phantom slaves.
Recompile. Re-download.
Hardware-reset TIM.
    │
    ▼
Verify: SF=OFF, BF=OFF,
K-Bus steady or activity
blink, IEC 101 GI returns
0x20 responses.

12. Related Considerations

12.1 Migration to TIM 3V-IE Advanced

If you are experiencing persistent restart-loop symptoms on a long-deployed TIM 3V, consider migrating to the TIM 3V-IE Advanced (6NH7800-3CA00) with firmware V1.2 or later. The newer firmware corrects the clock-synchronisation repetition issue that affected earlier Master-role WAN drivers. See the Siemens release note linked in Section 6 for the exact fix list.

12.2 Common Address (CA) vs Slave Address

Engineers frequently conflate the IEC 60870-5-101 Common Address (the station identity) with the PROFIBUS DP station address (the bus address). They are independent numbers. The CA is configured inside ParaM under the IEC 60870-5-101 settings; the DP station address is set by the rotary switches on each slave. The TIM's own CA on the IEC side is independent of its slot number on the S7 rack.

12.3 Time Synchronisation

If the master expects SNTP / NTP time rather than IEC 60870-5-101 clock synchronisation, the TIM 3V does not implement SNTP natively — it only accepts the C_CS_NA_1 / M_CS_NA_1 pair. For SNTP time on an S7-300 station, use the SIMATIC Time Synchronisation service provided by a CP 343-1 or the CPU 31x if it supports the integrated PN interface.

13. Glossary

14. Field-Engineer Summary

The TIM 3V's restart-loop symptom is almost always a configuration artefact, not a hardware failure. The minimum field actions are: clean the HW Config of phantom DP slaves, recompile and re-download, then hardware-reset the TIM. From that point, confirm that the SF and BF LEDs are off, the K-Bus LED shows the steady-state pattern, and the IEC 60870-5-101 link responds to a general interrogation with cause-of-transmission 0x20. If the symptom persists after a clean HW Config and a hardware reset, escalate to a firmware update to the latest Siemens-released revision (TIM 3V-IE Advanced V1.2 or later) and apply the security patches tracked under CISA ICS Advisory ICSA-15-335-03.

FAQ