Resolving SIMOCODE Pro V PROFIBUS Trip Drop with DP-V0 Master

When a SIMOCODE Pro V motor protection and management device is connected to a PROFIBUS DP-V0-only master (such as the Yokogawa ALP111), it can vanish from the bus segment the instant a trip event is generated. The fault is not noise, not grounding, not a bad GSD, and not a defective slave. It is the SIMOCODE firmware auto-activating DP-V1 services that the DP-V0 master cannot service, combined with enabled event-triggered diagnosis that posts alarms the master cannot acknowledge. This article documents the exact telegram that triggers the fault, the parameter changes inside SIMOCODE ES that recover the link, and the commissioning procedure that prevents the problem from reappearing on a plant-wide rollout of several hundred devices.

Problem Description and Field Symptoms

The fault was first observed on a 300-device PROFIBUS segment test bench used to validate a SIMOCODE Pro V (order code 3UF7010-1AU00-0) deployment. The hardware release in the test bench was E08. The GSD file was the latest revision available from the Siemens Product Support portal and was independently confirmed as the correct file by Siemens technical support. STEP 7 / SIMOCODE ES parameterization of the slave was performed normally, and the slave came online cleanly.

The symptom appears only when a trip condition is forced on the SIMOCODE:

• Overload, thermistor, phase failure, earth fault, or any other configurable trip source is triggered through simulation or a real process event.
• Within milliseconds of the trip bit being set inside the SIMOCODE, the device disappears from the PROFIBUS slave list of the DP master.
• The slave is not visible until the next power cycle of either the SIMOCODE basic unit or a manual bus reset from the master.
• The same GSD and the same project, but with SIMOCODE hardware release E06 (3UF7010-1AU00-0 older revision), works without any drop-off.

The fault has been independently reproduced at three different plants. Profitrace captures taken at those plants show the same signature, so the issue is not noise, shield termination, or grounding in any of the three installations. PROFIBUS retry counters and sync counters remain within healthy ranges; the increment in retries is observed only at DP master startup, not before or after the trip. The plant staff that took a "shotgun" approach reported that the problem was eventually masked by changes to the slave configuration, although no one change could be positively identified as the cure.

Affected Hardware, Firmware, and GSD Versions

Table 1 summarizes the components confirmed to exhibit the fault and the components that operate correctly. Always re-validate the order codes against the latest Siemens Product Support data before ordering replacement units.

The fact that hardware E06 does not exhibit the symptom while E08 does strongly suggests a firmware-side change in E08 that pushes DP-V1 services more aggressively than the E06 generation. SIMOCODE ES will display the firmware version inside the device's online diagnostics so that field engineers can confirm the build that is in front of them.

PROFIBUS DP-V0 vs DP-V1: Architectural Background

To understand the root cause, the engineer must separate the two PROFIBUS DP services that are present in modern SIMOCODE firmware:

• DP-V0 — cyclic I/O data exchange only. The master writes outputs and reads inputs on a fixed, repeating cycle. No acyclic services are available.
• DP-V1 — adds acyclic read / write services (MSAC1, MSAC2) used for parameterization and diagnosis of individual slots, plus the ability to raise diagnostic alarms and process alarms from the slave to the master.

The SIMOCODE Pro V GSD file ships with DP-V1 enabled by default because STEP 7 / TIA Portal masters and most modern PLC masters (S7-300/400/1200/1500, Allen-Bradley ControlLogix with PROFIBUS scanner) understand both protocols. When the master parameterizes the slave, it can either remain on DP-V0 or promote the slave to DP-V1 in the Set_Parameters telegram.

The Yokogawa ALP111 is certified by Yokogawa Electric Corporation for PROFIBUS DP-V0 only. It does not implement MSAC1 / MSAC2 services, and it cannot consume a slave-originated diagnostic alarm or process alarm in the way a DP-V1 master expects. In Sycon, the ALP111 configuration tool does not expose a DP-V0 / DP-V1 selector per slave; the mode is fixed by the master's class.

The mismatch that produces the fault is therefore not a Sycon bug. It is the SIMOCODE firmware deciding to use DP-V1 services even though the master is only DP-V0 capable, and then triggering those services on every trip event.

Root Cause Analysis: The DP-V1 Auto-Activation Mechanism

The Profitrace capture recorded at one of the plants shows the Set_Parameters telegram issued by the ALP111 at startup. The relevant byte sequence, parsed per the PROFIBUS DP specification, is:

B8 14 01 0B 80 FD 00 80 60 00

Decoded against the PROFIBUS DP-V1 status byte definition:

The 0x80 byte (DPV1_status[0]) instructs the SIMOCODE to operate in DP-V1 mode. The 0x60 byte (DPV1_status[1]) enables the diagnostic alarm and process alarm channels. Because the ALP111 is DP-V0 only, these alarms are transmitted by the slave but never acknowledged by the master. The slave's internal watchdog treats the unacknowledged alarm as a fault and removes itself from the bus.

When a trip condition is forced, the SIMOCODE raises a process alarm that carries the trip cause (overload, thermistor, earth fault, etc.) on the diagnostic interrupt channel. The DP-V0 master cannot service that interrupt and does not send the expected MSAC1 acknowledge. The SIMOCODE firmware interprets the lack of acknowledge as a serious bus fault and disconnects.

Two architectural decisions create the problem:

1. The SIMOCODE GSD declares DP-V1 capability, so any DP master — including a DP-V0-only master — will set the DP-V1 status bits as long as the GSD advertises them.
2. The SIMOCODE firmware raises alarms on every trip / warning event regardless of whether the master has acknowledged the channel as active.

Solution 1: Disable DP-V1 Diagnostic Alarms in SIMOCODE ES

The primary fix is to suppress the slave-originated DP-V1 alarms at their source. In SIMOCODE ES 2007 / SIMOCODE ES V15 / TIA Portal, the parameter tree is:

1. Open the SIMOCODE project and connect online to the device.
2. Navigate to Parameters > Device configuration > PROFIBUS interface > DP-V1 settings.
3. Uncheck Diagnostic alarms active (also labelled Enable diagnostic alarm depending on the SIMOCODE ES version).
4. Uncheck Process alarms active.
5. Confirm that the slave's DP-V1 status bytes will be transmitted as 00 00 00 instead of 80 60 00.
6. Write the project back to the SIMOCODE with Device > Download to device.
7. Cycle the SIMOCODE basic unit power to force a clean PROFIBUS restart.

Solution 2: Disable Watchdog, Time Stamping, and Event-Triggered Diagnosis

If the slave must retain a limited form of DP-V1 alarms for an S7-class master elsewhere on the network, but the deployment includes ALP111 segments, the most targeted fix is to disable the events that are most likely to coincide with a trip. Inside SIMOCODE ES navigate to Parameters > Functions > Diagnostics and apply the changes below.

The combination of disabled watchdog, disabled time stamping, and disabled event-triggered diagnosis removes all of the conditions under which the SIMOCODE will fire an alarm that the ALP111 cannot service. The cyclic I/O image continues to publish tripped, warning, running, remote, and the diagnostic word bits, so the control logic in the Yokogawa DCS still receives the same information it would have received via acyclic alarms — only over the cyclic channel instead.

Yokogawa ALP111 Specific Configuration

The Yokogawa ALP111 PROFIBUS master module is a class 1 DP-V0 master. Yokogawa documents this in the CENTUM VP field communication reference and in the ALP111 hardware reference manual. Two implications follow:

• Sycon does not expose a per-slave DP-V0 / DP-V1 mode selector because the master itself does not implement DP-V1.
• The slave GSD is loaded as a DP-V0 slave description, but if the GSD advertises DP-V1, the master will still set the DP-V1 status bits in Set_Parameters — that behaviour is specified by PROFIBUS, not by Sycon.

The plant-side mitigation is therefore entirely inside the SIMOCODE ES project, not in Sycon. Engineers should also verify the following on the ALP111 side:

1. The slave slot is configured with a DP-V0 module rather than a "DP-V1 with alarms" slot, even though Sycon may not label it explicitly.
2. The DP master's "alarm enable" tick box (if present in the Sycon slot properties) is left cleared.
3. The bus parameters in Sycon (Tslot, Tset, Tqui, Ttr, max retry count) match the PROFIBUS values recommended for the baud rate in use. Default PROFIBUS DP values are Tslot = 1000 Tbit, Tset = 11 Tbit, Ttr = 240, retries = 1.

Capturing the Fault and Verifying the Fix with Profitrace

Profitrace is the recommended tool to confirm that the fix has taken effect on the wire. Proceed as follows:

1. Connect the Profitrace tap to a live node on the same PROFIBUS segment that hosts the SIMOCODE. A tapping point on the outgoing side of the DP master repeater gives the cleanest capture.
2. Start a live trace and capture for at least 60 seconds of idle traffic to establish a baseline of cyclic I/O frames.
3. Force a trip event on the SIMOCODE (test mode, simulated overload, or a real process overload).
4. Stop the trace and inspect the telegram log. Before the fix you will observe a slave-originated diagnostic alarm telegram shortly after the trip bit becomes active, followed by the master failing to issue the corresponding MSAC1 read, and the slave entering a "not in cyclic exchange" state.
5. After the fix you should observe only the regular cyclic I/O frames plus a single DIAG0 reply if the master polls it explicitly. No diagnostic alarm telegram should appear at trip.

The Set_Parameters telegram after the fix should show DPV1_status bytes of 00 00 00, confirming that the SIMOCODE no longer requests DP-V1 services from the ALP111.

Set_Parameters (post-fix):
B8 14 01 0B 80 FD 00 00 00 00
                            ^^ ^^ ^^ no DP-V1, no alarms

Plant-Wide Rollout Strategy for ~300 Devices

For a deployment of roughly 300 SIMOCODE Pro V devices on a Yokogawa DCS, apply the following workflow to avoid re-encountering the fault at commissioning time:

1. Build a single canonical SIMOCODE ES template project with all DP-V1 services disabled and all event-triggered diagnosis disabled as per Table 3.
2. Verify the template against one bench unit, capturing a Profitrace trace around a forced trip to prove the slave does not drop.
3. Export the parameter file (.sdp) from the verified template and distribute it to all commissioning engineers.
4. During commissioning, each engineer opens the device online, loads the canonical .sdp, writes it back to the device, and verifies the DP-V1 status bytes via a one-shot Profitrace capture.
5. Maintain a commissioning sheet that records the firmware version, the hardware release, the GSD revision, and the Profitrace snippet showing DPV1_status = 00 00 00.
6. If the plant also uses ET200M IM153-1 / IM153-2 stations on the same ALP111 segment, audit those GSDs to ensure that no DP-V1 alarms are enabled on those slaves either. The same architecture applies to any DP-V1-capable slave on a DP-V0-only master.

Diagnostic and Troubleshooting Matrix

Table 4 maps the observable symptom on the wire to the most likely root cause and the corrective action. Use this when a Profitrace capture is available and the symptoms match the entries below.

Frequently Asked Questions