Configuring SIMOTION D435 X_SEND X_RCV to S7 CPUs over PROFIBUS

Configuring SIMOTION D435 X_SEND X_RCV to S7 CPUs over PROFIBUS

SIMOTION D435 motion controllers expose two PROFIBUS DP interfaces and can act as class-1 masters on the network. S7-CPU stations connected as DP slaves exchange user data with the D435 through the S7 communication services X_SEND / X_RCV (SFC 65 / SFC 66). On the SIMOTION side, the same services are exposed as system functions _xsend and _xreceive, callable from ST, MCC, or LAD/FBD with the same semantics. The payload is carried in a single contiguous buffer; 200 bytes is the typical field-tested size, with the SDU upper bound reaching 240 bytes on current D435 firmware (V4.5 / V5.x).

This guide walks through the complete configuration: HW Config on both sides, the S7 connection definition, the data buffer declaration, the ST programs on SIMOTION, and the SCL/LAD program on the S7 CPU. A worked example maps DB10.DBB0 bit flags from the S7 into individual BOOL variables on the SIMOTION motion program.

Prerequisites

PROFIBUS Network Topology and Addressing

The SIMOTION D435 is assigned the role of DP class-1 master on the segment. Each S7 CPU is a DP slave. Each station must have a unique PROFIBUS address between 1 and 126; the address 0 is reserved for class-2 masters (e.g., programming devices).

The physical bus must be terminated at both ends with the bus terminator switch set to ON. Unterminated or double-terminated segments cause intermittent errors, retries, and elevated bus error counters. Maximum bus load should stay below 70% to leave headroom for retries; sustained bursts above this produce timeouts and STATUS 0019 (network error) responses.

Hardware Configuration in SIMOTION Scout

1. Open the SIMOTION project in SCOUT and switch to HW Config. Right-click the D435 station and choose Open HW Config.
2. Configure the PROFIBUS interface. Double-click the DP master interface (X126 or X136). Set the PROFIBUS address of the D435 to a free value (2 in this example). Set the baud rate to match the segment — 1.5 Mbit/s is a safe default; 12 Mbit/s requires short cable and good shielding.
3. Add S7 CPUs as DP slaves. Drag the appropriate S7-CPU object (e.g., SIMATIC 300 / CPU 315-2 DP) from the hardware catalog into the DP master system. Assign each a unique PROFIBUS address (3, 4, ...).
4. Insert a universal slot if the S7 station is not in the catalog. Use DPV0 Slave and configure slot 0 with the desired number of input/output bytes. Note: this is the direct I/O image, not used by X_SEND/X_RCV. S7 communication is a separate service that runs over the same PROFIBUS connection regardless of the I/O slot configuration.
5. Configure the S7 connection. Switch to NetPro (in classic SCOUT) or use the Connections editor (in SCOUT TIA). Right-click the D435 station, choose Insert New Connection, select the S7-CPU partner, and choose S7 connection with protocol S7 communication. Assign a unique local connection ID — this is the reference SIMOTION passes to _xsend / _xreceive.
6. Download the hardware configuration to the D435 and the S7-CPU stations.

Reference documentation: Direct data exchange via PROFIBUS DP in the SIMOTION SCOUT TIA manual.

S7 CPU Side: Programming SFC65 X_SEND

On the S7 CPU, the X_SEND / X_RCV blocks are part of the standard IEC library — they do not need to be installed, but they require an active PROFIBUS interface. SFC 65 (X_SEND) and SFC 66 (X_RCV) reside in the CPU firmware and are called from any OB, FB, or FC.

SFC 65 X_SEND interface

Typical SCL (S7-300/400) call from OB1 or a cyclic OB:

// SCL — S7-300/400 calling X_SEND to send DB10.DBB0 to SIMOTION D435
IF bStartSend THEN
  X_SEND(REQ    := TRUE,
         CONT   := FALSE,
         DEST_ID:= W#16#0002,        // D435 PROFIBUS address = 2
         REQ_ID := DW#16#1001_0001,  // unique send identifier
         SD     := P#DB10.DBX0.0 BYTE 1,
         LEN    := 1,
         RET_VAL:= iXsendRetVal,
         DONE   := bXsendDone,
         ERROR  := bXsendError,
         STATUS := wXsendStatus);
END_IF;

For S7-1200/1500, SFC 65 / SFC 66 are available when the access level allows "PUT/GET communication from remote partner." The DB access must use symbolic or absolute P# pointer format. The function block names are X_SEND / X_RCV in the S7-1500 instruction set; the parameter signature is identical.

S7 CPU Side: Programming SFC66 X_RCV

// SCL — S7 CPU receiving the SIMOTION heartbeat / status word
X_RCV(REQ    := TRUE,
      CONT   := TRUE,           // job stays queued
      RET_VAL:= iXrcvRetVal,
      REQ_ID := dwXrcvReqId,
      NDA    := bXrcvNewData,
      RD     := P#DB11.DBX0.0 BYTE 20,
      LEN    := iXrcvLen,
      ERROR  := bXrcvError,
      STATUS := wXrcvStatus);

SIMOTION: Data Buffer Declaration

The data buffer in SIMOTION is declared as an ARRAY [0..199] OF BYTE in the interface or implementation section of the program. The actual size can be tuned down (1, 10, 50) to match the payload of the specific transfer. The buffer is then passed to the system function as an in-out variable.

// ST — variable declaration in a SIMOTION program unit (e.g. POU_Comm)
INTERFACE
  VAR_GLOBAL
    // Per-CPU buffers, one pair per S7 partner
    cpu1_recv_buffer : ARRAY[0..199] OF BYTE;   // data received from CPU 1
    cpu1_send_buffer : ARRAY[0..199] OF BYTE;   // data sent to CPU 1
    cpu1_len         : INT;

    // Bit flags exposed to motion / HMI
    cpu1_error_1     : BOOL;
    cpu1_error_2     : BOOL;
    cpu1_error_3     : BOOL;
    cpu1_error_4     : BOOL;
    cpu1_error_5     : BOOL;
    cpu1_error_6     : BOOL;
    cpu1_error_7     : BOOL;
    cpu1_error_8     : BOOL;

    // Diagnostics
    wCommStatus      : WORD;       // status of last _xsend/_xreceive
    bCommError       : BOOL;       // sticky error flag
  END_VAR
END_INTERFACE

An AT view can be used to map bytes to booleans without manual bit-slicing, but the most common field approach is direct bit-slice extraction on the named booleans:

// In the program (ST):
cpu1_error_1 := cpu1_recv_buffer[0].%X0;
cpu1_error_2 := cpu1_recv_buffer[0].%X1;
cpu1_error_3 := cpu1_recv_buffer[0].%X2;
cpu1_error_4 := cpu1_recv_buffer[0].%X3;
cpu1_error_5 := cpu1_recv_buffer[0].%X4;
cpu1_error_6 := cpu1_recv_buffer[0].%X5;
cpu1_error_7 := cpu1_recv_buffer[0].%X6;
cpu1_error_8 := cpu1_recv_buffer[0].%X7;

SIMOTION: _xsend and _xreceive System Functions

The _xsend and _xreceive system functions are part of the SIMOTION runtime. They are configured in the SCOUT project (Connections) and invoked in the user program. The system functions are documented in the SCOUT online help under System functions / Communication / S7 communication.

Command structure

Each command has the structure:

// ST — _xsend invocation (documented signature)
_xsend(
    EXECUTE     : BOOL,                  // start a new job
    COMPLETION  : BOOL,                  // job completed (one-cycle)
    ERROR       : BOOL,                  // job completed with error
    ERRORID     : WORD,                  // return code (see status table)
    CONNECTION_ID : INT,                 // matches the connection ID in NetPro
    REQ_ID      : DWORD,                 // unique job identifier (sender-defined)
    DATA        : ARRAY[0..n] OF BYTE    // in-out buffer (bytes to send)
);

// ST — _xreceive invocation
_xreceive(
    EXECUTE     : BOOL,                  // re-queue receive
    COMPLETION  : BOOL,                  // data received (one-cycle pulse)
    ERROR       : BOOL,                  // error
    ERRORID     : WORD,                  // return code
    CONNECTION_ID : INT,                 // connection ID
    REQ_ID      : DWORD,                 // job identifier (filled on receive)
    DATA        : ARRAY[0..n] OF BYTE    // out buffer (received data)
);

Calling _xsend/_xreceive from a cyclic task

// ST — typical cyclic send/receive block, called every motion task cycle
PROGRAM POU_Comm
  VAR
    fTrigSend     : R_TRIG;        // one-shot start
    bSendTrigger  : BOOL;          // external trigger, e.g. from a motion event
  END_VAR

  // Build outgoing payload (example: a 20-byte status block)
  cpu1_send_buffer[0] := bCam1Active;
  cpu1_send_buffer[1] := bCam2Active;
  cpu1_send_buffer[2] := bCam3Active;
  // ... populate buffer[0..19] ...

  fTrigSend(CLK := bSendTrigger);
  IF fTrigSend.Q THEN
    // _xsend
    _xsend(EXECUTE       := TRUE,
           CONNECTION_ID := 1,           // 1 = connection to S7 CPU at addr 3
           REQ_ID        := 16#1001_0001,
           DATA          := cpu1_send_buffer,
           COMPLETION    := bXsendDone,
           ERROR         := bXsendError,
           ERRORID       := wXsendStatus);
  END_IF;

  // _xreceive — leave running continuously
  _xreceive(EXECUTE       := TRUE,
            CONNECTION_ID := 1,
            REQ_ID        := dwXrcvId,
            DATA          := cpu1_recv_buffer,
            COMPLETION    := bXrcvDone,
            ERROR         := bXrcvError,
            ERRORID       := wXrcvStatus);

  // Map byte 0 to bools
  cpu1_error_1 := cpu1_recv_buffer[0].%X0;
  cpu1_error_2 := cpu1_recv_buffer[0].%X1;
  cpu1_error_3 := cpu1_recv_buffer[0].%X2;
  cpu1_error_4 := cpu1_recv_buffer[0].%X3;
  cpu1_error_5 := cpu1_recv_buffer[0].%X4;
  cpu1_error_6 := cpu1_recv_buffer[0].%X5;
  cpu1_error_7 := cpu1_recv_buffer[0].%X6;
  cpu1_error_8 := cpu1_recv_buffer[0].%X7;

  // Sticky error latching for HMI alarming
  IF bXrcvError OR bXsendError THEN
    bCommError := TRUE;
    wCommStatus := SEL(bXrcvError, wXsendStatus, wXrcvStatus);
  END_IF;
END_PROGRAM

Complete Example: Error Flag Mapping (DB10 Byte 0)

Goal: S7 CPU 1 has DB10.DBB0 containing eight error bits. The S7 sends that byte via X_SEND to the D435; the D435 receives it and exposes each bit as a named BOOL on the motion program.

S7 side (in OB1 or cyclic OB)

// SCL — CPU 1 (address 3) sends DB10.DBB0 to D435 (address 2)
IF bTriggerSend THEN
  X_SEND(REQ    := TRUE,
         CONT   := FALSE,
         DEST_ID:= W#16#0002,        // SIMOTION D435 PROFIBUS address
         REQ_ID := DW#16#A000_0001,  // identifies the job
         SD     := P#DB10.DBX0.0 BYTE 1,
         LEN    := 1,
         RET_VAL:= iRetVal,
         DONE   := bDone,
         ERROR  := bErr,
         STATUS := wStatus);
END_IF;

SIMOTION side

The corresponding D435 has connection ID 1 in the SCOUT Connections editor pointing to the S7 CPU at address 3. The ST program above is the complete example. The receive buffer cpu1_recv_buffer[0] is filled with the byte from DB10.DBB0 on the S7 side, and the bit extractions feed cpu1_error_1 through cpu1_error_8.

To avoid byte-order surprises: X_SEND/X_RCV transmits bytes in raw form, no byte swap. The first byte of the SD ANY pointer on the S7 lands in cpu1_recv_buffer[0]; bit 0 is the least significant bit of that byte. cpu1_recv_buffer[0].%X0 corresponds to S7 bit 0 of DB10.DBB0.

Return Codes and Diagnostics

The STATUS / RET_VAL / ERRORID parameters of the SIMOTION system functions and the S7 SFCs carry a 16-bit code with the structure shown in the following table. The same families of status codes apply on both sides; the mapping is consistent.

For PROFIBUS physical-layer diagnostics, the S7 FB 125 (DP_DIAG) and the SIMOTION PROFIBUS Diagnostics panel in SCOUT provide station status, bus error counters, and retry counts. A healthy segment shows 0 retries and 0 station failures. In SCOUT, open Target system → PROFIBUS → Diagnostics to inspect counters and per-slave status.

Verification Procedure

1. Compile and download the S7 project. Use STEP 7 or TIA Portal. The S7-1200/1500 requires Permit access with PUT/GET communication from remote partner enabled.
2. Compile and download the SIMOTION project. Select the D435 station in SCOUT and click Download (full project). Confirm Download to target system with Replace all.
3. Switch both sides to RUN. SIMOTION goes through the standard startup sequence; the S7 CPU keyswitch must be in RUN or RUN-P.
4. Open the SCOUT online watch window on the variables cpu1_recv_buffer, cpu1_error_1..8, and the status words wXrcvStatus / wXsendStatus. Set the display format for cpu1_recv_buffer[0] to Bin for direct bit visibility.
5. Force a bit in DB10.DBB0 on the S7 side (or use a VAT). Within one motion cycle, the corresponding cpu1_error_n in SIMOTION must go TRUE.
6. Check NDA and REQ_ID. After a successful receive, bXrcvDone must pulse and dwXrcvId must equal the S7's REQ_ID value (16#A000_0001 in the example).
7. Reverse direction. Force cpu1_send_buffer[0] in SIMOTION, trigger bSendTrigger, and confirm the value appears in the S7 DB11.DBB0 (or wherever the S7's RD buffer points).
8. Verify the PROFIBUS diagnostics panel. Station status of the S7 CPU must be OK; bus error counter must be 0; retry counter must be 0.

Troubleshooting Matrix

PROFIBUS Performance and Bus Load

For a 1.5 Mbit/s PROFIBUS segment, the effective user data throughput is approximately 0.7 Mbit/s. A 200-byte X_SEND/X_RCV PDU requires ~1.3 ms of bus time including token-passing, header, trailer, and acknowledgements. Calling _xsend every 1 ms in a fast motion task saturates the segment; in practice, the call should be triggered from a 10–20 ms cyclic task or a TO event. A guideline for production commissioning:

Direct data exchange (DPV0/DPV1 slave-to-slave) and X_SEND/X_RCV are independent. The S7 communication path uses its own service access points and is unaffected by the slave I/O configuration. For more information, see the Direct data exchange via PROFIBUS DP manual page.

Multi-Partner and Edge Cases

When the D435 communicates with more than one S7 CPU, the SCOUT Connections editor must define a unique S7 connection entry per partner, each with a unique local connection ID. The user program instantiates one set of buffers per partner, e.g., cpu1_recv_buffer, cpu2_recv_buffer, etc., and calls _xreceive once per connection with the corresponding ID. Mixing buffers across partners corrupts data because each _xreceive block is tied to its connection.

Edge cases to consider during commissioning:

• Startup race. The S7 CPU may reach RUN before the D435 has finished downloading connections. Add a startup delay (5–10 s) on the S7 side before the first X_SEND call to avoid STATUS 0005 / 000C in the first cycles.
• REQ_ID lifecycle. The REQ_ID is an arbitrary 32-bit tag. The S7 returns the REQ_ID it received via X_RCV's REQ_ID output. Use this echo to correlate send and receive jobs in logs and HMI screens.
• Buffer length changes. Reducing the buffer size in the SIMOTION POU while the S7 still sends the old size produces STATUS 0003. Re-compile and download both sides to keep the size consistent.
• Hot-swapping S7 CPUs. S7 communication recovers automatically after a partner CPU restart. Expect transient STATUS 0009 / 0012 for a few hundred milliseconds. Latch the error with a debounce filter to avoid flooding the HMI alarm log.

FAQ