SINAMICS S120 Parameter Write from SIMOTION D via LDPV1 Library

1. Overview

When a SIMOTION D controller (D4x5, D4x5-2, D410) drives a SINAMICS S120 drive object, every non-cyclic parameter access travels over the internal PROFIdrive (DP-V1) channel. Two functionally similar, but architecturally very different, function-block families can perform that access from the SIMOTION application:

• The Command Library with _writeDriveParameter / _readDriveParameter – the classic, blocking-oriented blocks shipped with every SIMOTION SCOUT installation.
• The LDPV1 library (Logical Drive PROFIdrive V1) with FBLDPV1WriteOneParameter / FBLDPV1ReadOneParameter and the surrounding FBLDPV1Buffer manager – the buffered, async, multi-job-capable alternative that the SIMOTION Project Generator wires into Message Handling for HMI and trace services.

This reference covers the runtime semantics of both paths, the buffer and identifier rules that prevent cross-talk between the two, and the field-proven configuration patterns that let a SIMOTION D project use both a SIMOTION Message Handling instance and a custom FBLDPV1WriteOneParameter loop without losing jobs.

2. The Two Parameter-Write Paths at a Glance

3. Command Library: _writeDriveParameter

_writeDriveParameter is a SIMOTION system function declared in the _DriveParameter namespace. It is the simplest path: hand it a logical drive address, a parameter number, the value, and an execution flag; the block initiates a DP-V1 single-parameter write and returns when the drive object has answered.

// ST snippet (SIMOTION) – Command Library
VAR
    rRetVal  : DINT;        // 0 = OK, 0x8001 = BUSY, 0x8002 = TIMEOUT, ...
    dValue   : DINT := 1500;
END_VAR

rRetVal := _writeDriveParameter(
    ioObjectHandle   := Axis1,            // TO / axis handle
    iParameterNumber := 1150,             // p1150 = ramp-function generator ramp-up time
    iParameterIndex  := 0,
    iValue           := dValue,           // DWORD but cast from DINT
    iValueLength     := 4,                // bytes
    iExecute         := TRUE,
    iTimeout         := 2.0,              // seconds
    oDone            => ,
    oBusy            => ,
    oError           => );

Because the call is blocking, the surrounding task is held for the round-trip time of a DP-V1 write (typically 1–4 servo cycles on a SIMOTION D4x5 at 1 ms). A loop that issues 10 parameter writes in one MotionTask cycle stalls the entire cycle for the sum of all round-trips. This is the root cause of the common complaint that "writeDriveParameter and readDriveParameter take much time". When many commands target the same drive object they pile up at the DP-V1 interface; the drive has a finite acyclic-channel queue and returns 0xF2 (sequence error / channel busy) for any request that arrives while a previous one is still being processed.

4. LDPV1 Library: Architecture and Components

The LDPV1 library is a layered set of function blocks that ship with SIMOTION SCOUT and are also distributed as part of the "SIMOTION Utilities & Applications" package. Its purpose is to multiplex many non-cyclic requests onto a single logical DP-V1 channel per drive object, with deterministic order, completion detection and centralised error handling.

Each drive object on a SIMOTION D controller that participates in LDPV1 traffic must have exactly one FBLDPV1Buffer instance, and every FBLDPV1WriteOneParameter call must target that buffer through a unique buffer identifier slot.

5. FBLDPV1WriteOneParameter Deep Dive

The signature below is reproduced from the LDPV1 V4.x library header (SIMOTION SCOUT V5.x, library version 4.5.0):

FUNCTION_BLOCK FBLDPV1WriteOneParameter
VAR_INPUT
    i_jobId         : DINT;          // 0 = ignore tracking, >0 = application tag
    i_bufferId      : DINT;          // buffer slot, MUST be unique per buffer FB
    i_driveHandle   : DRIVE_HANDLE;  // handle of the drive object (TO or logical address)
    i_paramNumber   : DINT;
    i_paramIndex    : DINT;
    i_valuePtr      : PVOID;         // ANY pointer to the value to write
    i_valueLength   : DINT;          // bytes (1, 2, 4, 8)
    i_execute       : BOOL;
END_VAR
VAR_OUTPUT
    o_done          : BOOL;
    o_busy          : BOOL;
    o_error         : BOOL;
    o_errorId       : DINT;          // 0x0000 = OK, see section 11
    o_jobId         : DINT;          // echoes the i_jobId of the completed slot
END_VAR

Calling pattern – the FB is a classic two-step rising-edge model:

// ST pattern for one parameter
IF bStartWrite AND NOT fbWrite.o_busy THEN
    fbWrite(i_execute := FALSE);                  // reset edge
END_IF;

IF bStartWrite THEN
    fbWrite(
        i_jobId       := 4711,
        i_bufferId    := 0,                       // see section 7
        i_driveHandle := Axis1.HwDriveHandle,
        i_paramNumber := 1150,
        i_paramIndex  := 0,
        i_valuePtr    := ADR(dValue),
        i_valueLength := 4,
        i_execute     := TRUE);
END_IF;

IF fbWrite.o_done THEN
    // re-arm
    fbWrite(i_execute := FALSE);
END_IF;

IF fbWrite.o_error THEN
    // see section 11 for o_errorId decoding
    bStartWrite := FALSE;
END_IF;

6. Buffer Manager (FBLDPV1Buffer) Operations

The buffer manager runs as a long-running FB in the background. It is the only entity that actually owns the DP-V1 channel. It performs three duties in a single sweep:

1. Dispatch – scans its slot list, picks the next slot in FIFO order, and issues the DP-V1 request through the SIMOTION IO layer.
2. Poll – waits for the response from the drive object; updates the slot's state (RUNNING → DONE / ERROR).
3. Complete – raises the slot's o_done/o_error, releases the slot, and moves to the next pending job.

Because the buffer is a single FB instance per DO, every queued write is serialised on the wire – exactly what the S120 acyclic channel requires. Application code can fire ten FBLDPV1WriteOneParameter calls inside a 1 ms MotionTask and the buffer will simply queue them; the writes are processed in subsequent servo cycles without blocking the caller.

7. Job Identifiers, Buffer Identifiers, and Data Set Numbers

Three identifier fields appear on the LDPV1 FBs and they are often confused. The rules below are taken from the SIMOTION SCOUT LDPV1 library manual (entry ID 109751626 in the Siemens Industry Online Support) and verified against a D435-2 / S120 firmware V5.2 SP3 stack.

7.1 Buffer Identifier Rules

The buffer identifier is the single most common source of jobs that go missing. The library's hard rule is: two outstanding FBs must not share a buffer identifier in the same FBLDPV1Buffer instance. If they do, the second call overwrites the first's slot and the first call's o_done/o_error will never be raised.

7.2 Job Identifier Rules

Job identifiers are purely application-level tags. They do not need to be globally unique – the LDPV1 library never inspects the value. The only constraint is that the tag you set in i_jobId is the value you compare against o_jobId when o_done rises. A common pattern is to embed a counter, a state number, or a pointer to the source structure into i_jobId.

7.3 Data Set Numbers

The Data Set Number is an attribute of the drive, not the SIMOTION FB. For SINAMICS S120 the S120 parameter list (LH1) documents the DS used by each parameter; most user-visible parameters (p, r, c) sit in DS0. FBLDPV1WriteOneParameter selects DS0 by default – there is no need to specify a DS unless you are accessing the fault buffer (DS47) or the identification & maintenance data (DS16). The FB does not expose a DS input.

8. SIMOTION Message Handling Integration

SIMOTION's Project Generator creates a block called Message Handling the moment you enable HMI communication, web-server diagnostics, the SIMOTION trace viewer, or STARTER routing through a D4x5. The block is implemented as an LDPV1 client: a private FBLDPV1Buffer with a single consumer that calls FBLDPV1ReadOneParameter / FBLDPV1WriteOneParameter on behalf of the higher-level requestor.

Concretely, Message Handling:

• Allocates its own buffer instance on every drive object that is exposed to the HMI / web server.
• Uses i_bufferId = 0 for all of its requests.
• Polls the buffer from a background task (typically the BackgroundTask).

Because of the buffer-identifier uniqueness rule, any application FB that targets the same drive object must avoid i_bufferId = 0. If application code uses 0 and the HMI happens to issue a parameter read at the same time, one of the two completions will be lost; the symptom is an HMI that "freezes" a parameter value or a SIMOTION trace that stops refreshing.

9. Performance and Concurrency

The two paths behave very differently under load. The numbers below are typical for a SIMOTION D435-2 (firmware V5.2 SP3) controlling one S120 CU320-2 PN with active STARTER online routing through the same D4x5. They are intended as an order-of-magnitude indication, not a contract.

10. Implementing a Custom Buffer Identifier Scheme

The simplest robust scheme is a single static range. For each drive object that the application writes to, declare a constant block:

// constants block (ST)
CONST
    // Message Handling owns 0 on every DO. App uses 1..15.
    BUFID_RAMP_TIME     : DINT := 1;
    BUFID_P_GAIN        : DINT := 2;
    BUFID_FILTER_TIME   : DINT := 3;
    // etc.
END_CONST

For a more dynamic scheme, allocate a small pool and check out a free identifier on demand. The "free-list" pattern is implemented by an LDPV1-aware function block called FBLDPV1AllocBufferId that some projects ship internally; it is not part of the standard library. A typical implementation returns the lowest free slot in 0..7 and marks it used until the corresponding o_done or o_error fires.

11. Error Codes and Diagnostics

The error codes raised on o_errorId span both LDPV1-internal failures and DP-V1 responses from the drive. The most useful set for a SIMOTION D + S120 combination is reproduced below. Always cross-check against the S120 parameter list (LH1) and the SIMOTION LDPV1 manual for the firmware version you run on the D controller.

12. SIMOTION D Hardware Considerations

On SIMOTION D4x5 / D4x5-2 / D410, the DP-V1 channel used by both libraries is the internal PROFIdrive channel between the SIMOTION runtime and the integrated (or attached) SINAMICS. There is no PROFINET or PROFIBUS in the picture – the drive objects sit on the SIMOTION-internal drive bus. This has three practical consequences:

1. No bus cycle time – the DP-V1 round-trip is bounded by the servo cycle, not by PROFINET send-clock. The worst-case round-trip is 1–2 servo cycles plus drive processing time.
2. The LDPV1 buffer is per-DO, not per-bus – each drive object (CU, TM, Active Line Module, Motor Module) requires its own FBLDPV1Buffer.
3. Message Handling traffic shares the same internal channel – if you starve Message Handling, the HMI will lag and the web-server diagnostics will time out, even though there is no external network involved.

13. Best-Practices Checklist

• Use the LDPV1 library (not the Command Library) for any write that is issued more than once during a single SIMOTION task cycle.
• Allocate the buffer identifier range per drive object. Keep 0 reserved for Message Handling.
• Choose job identifiers from a single counter (e.g. an UDINT that wraps at 2^31) so completion correlation is unambiguous.
• Size the buffer at FBLDPV1Init for the peak outstanding jobs, not the average. A buffer of 8 is typical; 16 is a good default for projects that mix HMI + trace + application writes.
• Always re-arm the FB by calling it with i_execute := FALSE when o_done or o_error fires; the FB is edge-triggered and will not accept a second command while it still shows o_busy = TRUE.
• Do not mix _writeDriveParameter and LDPV1 on the same DO without an external mutex – the Command Library bypasses the buffer and will race against any LDPV1 call in flight.
• Document the buffer-identifier scheme inside the project documentation, not only in the source code.

14. Troubleshooting Matrix

15. Reference Documents

The LDPV1 library manual, the SIMOTION D programming manual, and the SINAMICS S120 parameter list are the primary references for this material. When troubleshooting, always match the version of the LDPV1 library to the SIMOTION SCOUT version installed – library V3.x, V4.x and V5.x have slightly different error-code sets.