PROFIBUS DP I-Slave Communication Between SIMOTION Scout Projects: Resolving Slot and Consistency Mismatches

When a SIMOTION automation system is split across two engineering projects — one programmed in Classic SIMOTION Scout and the other in Scout TIA (TIA Portal) — engineers frequently need to exchange cyclic I/O data between the controllers over PROFIBUS DP. The most common implementation is the I-Slave (intelligent slave) topology, where one SIMOTION acts as a PROFIBUS DP master and a second SIMOTION acts as an I-Slave. This article documents the field-proven configuration path, the underlying slot and consistency model, and the diagnostic procedure used to resolve the most common failure mode: a slot-count, slot-length, or consistency-class mismatch between the two projects.

Problem Overview

The reported fault pattern is straightforward: the master project (Scout TIA) has been configured with one set of slots, while the slave project (Classic Scout) is configured with a different number of slots, or the two projects disagree on whether the configured data is accessed as a complete slot (Length consistency) or as a single byte/word (Unit consistency). Even when the total payload length happens to be identical, the PROFIBUS DP connection does not enter data exchange because PROFIBUS matches DP slaves by slot index, slot length, and consistency class — not by the sum of the configured bytes.

The two operating modes that work across projects are:

1. I-Slave coupling with a GSD file — the master project imports a GSD file describing the slave's I/O layout.
2. Direct slot mirroring with the runtime API — both projects use the SIMOTION system functions _xSend and _xReceive to publish and consume data on a shared PROFIBUS slot, with the slot configuration mirrored on both sides.

Prerequisites

• SIMOTION controller acting as DP slave with integrated PROFIBUS interface (e.g., SIMOTION D4x5-2 DP/PN) or with a PROFIBUS communications module.
• SIMOTION controller acting as DP master with integrated PROFIBUS interface or PROFIBUS CP.
• SIMOTION Scout (Classic) V4.4 SPx or V5.x with the matching SINAMICS support package.
• Scout TIA (TIA Portal V17 or higher with the SIMOTION Scout TIA option package) on the master project side.
• GSD file generated from the I-Slave project (Classic Scout > Project > Export I-Slave GSD).
• PROFIBUS DP cable with termination resistors enabled at both physical ends of the segment, and a PROFIBUS diagnostics tool such as Softing PROFIBUS Diagnostics or an Amprolyzer.
• Online access to both projects to verify slot configuration at runtime.

PROFIBUS DP I-Slave Fundamentals

An I-Slave is a PROFIBUS DP slave whose I/O image is not generated by a distributed I/O module but by a controller program. The SIMOTION runtime exposes a configurable region of its process image as PROFIBUS I/O to a DP master. The master sees the SIMOTION exactly as it would see a regular DP-V0 / DP-V1 slave — through a GSD file.

Four configuration objects must match on both sides:

PROFIBUS DP Versions and Capability

SIMOTION I-Slaves are typically DP-V0 / DP-V1 capable. The PROFIBUS profile, baud rate, and feature set used must be supported by both controllers. The GSD file generated by Classic Scout declares the supported DP version, and the master must use a profile that does not request features beyond what the GSD declares. Mixing a DP-V1 master against a DP-V0 GSD is permitted; the master will negotiate down. Mixing a DP-V2 master against a DP-V0 GSD is not permitted.

For most SIMOTION-to-SIMOTION couplings, the recommended profile is DP-V1 with a baud rate of 1.5 Mbps when cable length allows, or 500 kbps for longer segments. The configured baud rate must be identical on the master and the slave.

Configuring the SIMOTION I-Slave in Classic Scout

The I-Slave side is configured first because the master needs the GSD file generated from this configuration.

1. Open the SIMOTION project in Scout (Classic).
2. Right-click the SIMOTION device and select Properties > PROFIBUS Interface > I-Slave.
3. Enable Operate as I-Slave.
4. Assign the PROFIBUS address for the slave (e.g., 3). Verify the address is unique on the segment.
5. Add the required number of slots. Each slot corresponds to a contiguous region of the I-Slave's process image that the master will read or write.
6. For each slot, configure:
   • Direction: Inputs (master reads from slave), Outputs (master writes to slave), or Inputs/Outputs.
   • Length: byte count. Typical values are 1, 2, 4, 8, 16, 32.
   • Consistency: Unit (byte/word-level) or Length (entire slot consistent).
7. Note the I/O address assigned to each slot in the I-Slave's process image. These are the addresses the SIMOTION user program reads with _xReceive or writes with _xSend.
8. Generate the GSD file: Project > GSD File > Export I-Slave GSD. The resulting .gsd file is imported into the master project.
9. Compile and download to the I-Slave.

Configuring the SIMOTION DP Master in Scout TIA

The official Siemens TIA Portal documentation for direct data exchange via PROFIBUS DP applies to the closely related cross-device configuration and is referenced as the canonical reference: Direct data exchange via PROFIBUS DP — SIMOTION Scout TIA Device Configuration.

1. Open the master project in TIA Portal with the SIMOTION Scout TIA option installed.
2. Insert the SIMOTION master device. Create a DP master system on the master's PROFIBUS interface.
3. Install the I-Slave GSD: Options > Manage general station description files (GSD). Select the .gsd exported from the slave project.
4. Drag the I-Slave from the hardware catalog onto the DP master system. Assign the same PROFIBUS address used on the slave (e.g., 3).
5. From the I-Slave's slot list, insert the same number of modules as configured on the slave. The slot count, byte length, and consistency are inherited from the GSD and cannot be freely changed; attempting to insert a different module will produce a configuration mismatch error during compile.
6. Assign I/O addresses for the master-side process image. These are the addresses the master program uses to access the data.
7. Compile and download the master configuration.

Slot Configuration: Unit vs. Length Consistency

This is the single most common source of failed I-Slave communication. The two consistency classes behave as follows:

For Length consistency, the entire slot is guaranteed to belong to the same PROFIBUS cycle. A typical use case is transferring 8 bytes of axis data: configuring 2 slots of 4 bytes Length is operationally different from configuring 1 slot of 8 bytes Length — the master must mirror the exact slot boundaries, not just the total bytes.

_xSend and _xReceive Programming Interface

When the application is configured to use the SIMOTION system functions, the user program does not directly access the I/O addresses. Instead, it calls the runtime API:

• _xSend(slot, offset, length) — publishes a region of the I-Slave's process image to the master.
• _xReceive(slot, offset, length) — accepts a region written by the master into the I-Slave's process image.

These functions are typically used together with mirroring. The I-Slave calls _xSend for inputs (master reads) and _xReceive for outputs (master writes); the master calls the same functions with the roles reversed. The functions indicate completion once the master has acknowledged the full slot in the same PROFIBUS cycle when Length consistency is configured.

// I-Slave: send 8 bytes from slot 0 to the master
// and receive 4 bytes from the master into slot 1
xSend(0, 0, 8);     // publish inputs (master reads)
xReceive(1, 0, 4);  // accept outputs (master writes)

GSD Export/Import Workflow

For purely cyclic exchange with a SIMOTION user program reading/writing the process image directly (no _xSend/_xReceive), the GSD file alone defines the slot structure. The procedure is:

1. Export the I-Slave GSD from the slave project (Classic Scout).
2. Import into the master (Scout TIA / TIA Portal).
3. Configure the I-Slave in the master exactly as the GSD describes — no free editing of slot lengths.
4. Compile and download to the master.
5. The master program accesses the configured I/O addresses; the SIMOTION runtime on the slave reads/writes the same addresses on its side.

If the I-Slave's slot configuration is changed after the GSD has been generated, the GSD must be re-exported and re-imported on the master. A stale GSD is a common cause of intermittent or permanent configuration errors after a slave-side change.

Diagnostic Procedure

When the communication does not enter data exchange, walk through the following matrix:

PROFIBUS Diagnostics Counters to Monitor

Once the link is up, monitor the following counters in the master's online diagnostics to confirm healthy operation:

• Retry counter — number of PROFIBUS frames the master has retried. Should be zero in steady state.
• Lost-token counter — should be zero. A non-zero value indicates bus topology or termination problems.
• Diagnostic interrupts — should be zero from the I-Slave. A non-zero count indicates the I-Slave has signaled a diagnostic event (channel fault, module swap, hot-plug).
• Cycle time jitter — measured at the master, should be within the configured cycle time. Excessive jitter typically points to a bus that is overloaded or running near the retry threshold.

Verification and Commissioning

Use this sequence to verify the link end-to-end:

1. In Scout TIA, compile the master hardware configuration. The compiler must report No configuration errors.
2. Download the master configuration. The slave's I/O slots should appear in the master's device view with the expected address ranges.
3. Go online with the master. Open the master's watch table and force a value into the slave's input address (output from master's perspective). Verify the value appears at the corresponding address in the slave's online watch table.
4. Force a value into the slave's output address (input from master's perspective). Verify the master sees the value.
5. For Length consistency, observe that the value updates atomically: place the master under breakpoint, change the slave, single-step the master, and confirm the full slot is updated in a single cycle.
6. Check the PROFIBUS diagnostics counters (retry, error, lost-tokens). All should be zero or near-zero under steady-state operation.
7. Disconnect the slave to confirm the master reports a diagnostic event, then reconnect and verify the link auto-recovers.

Common Engineering Pitfalls

• Slot aggregation mistake: an engineer with 8 bytes of data configures 1 slot of 8 bytes on one side and 2 slots of 4 bytes on the other. The total matches but the slot index table does not.
• Direction confusion: on the master, an input is what the master reads from the slave; on the slave, that same data is an output (the slave publishes it). The terminology flips between sides.
• Mixed consistency within a slot: a single slot is either Unit or Length, never both. Splitting a payload across two slots with different consistency classes is permitted but must be mirrored.
• GSD version mismatch: the GSD generated by a newer Scout version may declare DP-V1 features that the master does not support. Pin both projects to compatible versions or re-generate the GSD from the older toolchain.
• Terminator at the wrong end: a terminator is required at each physical end of the segment, and only at the ends. A terminator in the middle of a long run reflects signals and produces intermittent faults that look like configuration errors.

FAQ