Fixing FBLDPV1GetDriveObjectAlarmsAndFaults 16#411A in SIMOTION

Problem Statement

The SIMOTION LDPV1 function block FBLDPV1GetDriveObjectAlarmsAndFaults is the standard utility for dumping the active alarm and fault buffer of a SINAMICS drive object over a PROFIdrive acyclic channel. Field installations built on SIMOTION D425-2 PN/DP controllers running SCOUT TIA 5.3.1.0 against a SINAMICS S120 with integrated CU exhibit a deterministic intermittent fault: the first call returns the expected fault code with done = TRUE, the second call returns error = TRUE with errorID = 16#411A, and the third call succeeds again. The pattern then repeats indefinitely. Odd-numbered invocations complete cleanly, even-numbered invocations raise the technology error.

The defect is reproducible with a single drive object on the integrated Control Unit and with multi-axis configurations alike. A 10-second pause between operator-triggered calls excludes a communication-overload hypothesis: PROFINET IRT bandwidth, acyclic-channel timeouts, and PN watchdog trips are all comfortably out of range. The signature is instead that of a job-state machine conflict inside the LDPV1 instance DB, and the fix is to relocate the call from the SIMOTION background task to a motion task.

Affected Environment

The fault has been confirmed on the following combination. Other combinations on the same firmware line are likely affected in the same way.

Reference: Siemens Support Entry 109479553 – SIMATIC S7-1200/S7-1500 and SIMOTION: Acyclic Data Exchange (LDPV1 SIMOTION V4.2.12 manual). Cross-references: SIMOTION D4xx Function Manual and the SCOUT TIA Configuration Manual for the execution-system editor.

Observed Symptom Pattern

The behaviour is highly reproducible in a SCOUT TIA trace. The bit commandBusy, done, error, and errorId of the LDPV1 instance DB all follow the same alternating pattern:

1. Call N = 1 (odd): the function reads the alarm/fault buffer of the configured drive object, sets done = TRUE, the requested fault code appears in the alarmBufferReadOut / faultBufferReadOut output structures, and errorID stays at 16#0000.
2. Call N = 2 (even): the function returns with error = TRUE, done = FALSE, and errorID = 16#411A. The application code must reset the FB instance, which consumes at least one IPO / motion-task cycle.
3. Call N = 3 (odd): the cycle restarts cleanly, as in step 1.
4. The pattern persists for the entire runtime of the controller, with no decay in the error rate.

It occurs with a single drive object as well as with several, and the integrated CU is used (no separate CX). Engineers who have re-triggered the call at sub-100 ms rates have observed the same 1:1 alternation, ruling out any thermal, watch-dog, or PN-load explanation. The number of drive objects on the same CU does not change the pattern.

Root Cause Analysis

The LDPV1 library implements PROFIdrive V1 acyclic parameter access (DPV1 services READ / WRITE) on top of the standard SIMOTION acyclic channel. The FBLDPV1GetDriveObjectAlarmsAndFaults block encapsulates a request that issues a DPV1 READ for the SINAMICS fault-buffer parameters r947/r948, waits for the asynchronous response, and resets its internal state. The job is owned by an instance DB with a four-state machine: idle, request-active, response-received, and error.

When the block is launched from the background task on a D425-2, the following race condition can occur:

1. The first call (call 1) issues a DPV1 READ on the acyclic channel, sets request-active, and returns control to the OB. The DPV1 request is dispatched onto the lower-layer acyclic queue.
2. The acyclic response is delivered asynchronously. Because the background task does not block on the response, the next scan of the background task re-evaluates the FB before the response has been fully drained by the system tick that services the acyclic channel.
3. On call 2, the application sees done = TRUE from call 1, but the lower-level acyclic job buffer is still occupied by the previous request. The block issues a second READ while the previous DPV1 channel is still in response-received but not yet acknowledged. The PROFIdrive stack rejects the second request with a job-state error, surfacing as 16#411A on the technology-error interface.
4. After the rejection, the state machine resets to idle on the next scan. Call 3 starts from a clean state, succeeds, and the alternation repeats for the entire controller uptime.

The motion task (MCTO / motion task of the IPO) executes synchronously with the IPO and IPO_2 cycle and with the system tick that drains the acyclic communication buffer. By moving the call out of the background task into a motion task, the call is paced by the IPO tick, which provides the deterministic window required for the DPV1 service to complete. The race condition disappears, and consecutive calls succeed.

Solution: Move the LDPV1 Read into a Motion Task

Launch the FBLDPV1GetDriveObjectAlarmsAndFaults instance from a SIMOTION motion task rather than from the background task. The motion task runs synchronously with the IPO and provides the deterministic timing window required for the acyclic job to complete before the next request is issued.

Why this works

• Motion tasks run at a fixed time offset within the IPO cycle, after the system tick that processes acyclic responses.
• The motion task is single-threaded with respect to the IPO, so the FB can complete the request-response cycle without pre-emption from the same priority class.
• The acyclic job buffer is therefore drained between two consecutive invocations of the FB, and the PROFIdrive stack never sees a second request on a channel that has not yet released the previous job.

The fix is structural: it changes the execution context in which the FB is scheduled, not the FB itself. The same FB instance DB is reused; only the call site is moved.

Implementation Procedure

Prerequisites

• SCOUT TIA V5.3 or newer with the project already open.
• The LDPV1 V4.2.12 library installed (entry 109479553) and the necessary function blocks instantiated in the device.
• At least one configured motion task in the execution system. If none exists, add one (e.g. MotionTask_1) at the same IPO level used by the axes whose faults you intend to read.
• The SIMOTION project must be downloaded to the controller with at least one full STOP/RUN cycle after the change. Hot reload is supported for SCOUT TIA ≥ V4.4 if the new motion task is added without changing the IPO level.

Step-by-step

1. Open the project in SCOUT TIA and navigate to the Execution System tab of the SIMOTION device.
2. Identify the program that currently calls FBLDPV1GetDriveObjectAlarmsAndFaults from the background task. The typical source is _backgroundTask of the unit that owns the LDPV1 instance DB.
3. Add a new MotionTask if none is available: right-click the MotionTasks folder → Insert MotionTask → name it (e.g. mt_LDPV1_Read) → set the priority so that it runs after the servo/IPO tick that services acyclic communication, but before any user motion that depends on the result.
4. Cut the call logic from the background task and paste it into the new motion task. The minimum is:

// Motion task mt_LDPV1_Read
// State variables (unit scope)
iFaultBusy  : BOOL; // TRUE while the LDPV1 instance is processing
iFaultDone  : BOOL; // Latched by the FB on success
iFaultError : BOOL; // Latched by the FB on error
wFaultErrorId : WORD; // LDPV1 error ID (16#411A in the failure case)

IF bTriggerFaultRead AND (NOT iFaultBusy) THEN
    iFaultBusy := TRUE;
    FBLDPV1GetDriveObjectAlarmsAndFaults(
        execute             := TRUE,
        driveObjectNumber   := dwDriveObject,
        alarmBufferReadOut  := ADR(drvAlarmBuffer),
        faultBufferReadOut  := ADR(drvFaultBuffer),
        nextCommand         := FALSE,
        commandBusy         := iFaultBusy,
        done                := iFaultDone,
        error               := iFaultError,
        errorId             := wFaultErrorId
    );
END_IF;

IF iFaultDone OR iFaultError THEN
    // Consume the result, then re-arm
    iFaultDone  := FALSE;
    iFaultError := FALSE;
    iFaultBusy  := FALSE;
END_IF;

5. Make sure the rising edge of execute is generated only when the previous cycle has reached done = TRUE or error = TRUE. The library's own commandBusy output can be used as the latch.
6. For sequential reads of multiple drive objects, add a sequencer in the same motion task. Do not call the same instance DB from two motion tasks in parallel; duplicate the instance DB per drive object if parallel reads are required, or schedule them serially within one task.
7. Compile and download to the target. The download is hot-reloadable for SCOUT TIA ≥ V4.4 if the new motion task is added without changing the IPO level, but a STOP/RUN cycle is recommended during commissioning to validate the trace cleanly.

Verification

1. Open the trace in SCOUT TIA. Record the bits commandBusy, done, error, and errorId of the LDPV1 instance DB. The alternation should disappear: every call sets done = TRUE with errorId = 16#0000, and error stays at FALSE.
2. Force the controller into a real drive fault (for example, by triggering F07900 "Motor blocked" on one axis via a temporary DO write) and confirm that the same call retrieves the alarm code from faultBufferReadOut on the first call without raising errorId = 16#411A.
3. Run a stress test of 10 000 consecutive calls from the motion task at the configured cycle time. All 10 000 should complete with done = TRUE and error = FALSE.
4. Check the internal state of the LDPV1 instance DB to ensure that it returns to idle after every call and that no job is left in the request-active state across cycles. A simple way is to expose the commandBusy bit on the HMI and confirm that it returns to FALSE between two calls.

LDPV1 Library Architecture Reference

The LDPV1 library is Siemens's implementation of PROFIdrive acyclic services for S7-1200, S7-1500, and SIMOTION. It exposes the following key blocks:

Each block encapsulates a state machine that owns one acyclic channel of the underlying PROFINET/PROFIBUS connection. The state machine is implemented inside the instance DB; it tracks the request, awaits the asynchronous response, and only releases the acyclic channel when the response has been fully consumed by the application code.

The library manual warns that a single instance DB must be driven by exactly one execution context. Mixing execution contexts (background + motion task) for the same instance DB is not supported and leads to the state conflicts described in this article. The manual also states that the FB may only be triggered with a positive edge of the execute / REQ input, that the instance DB must be in idle before the trigger, and that the call must be paced so that the lower-layer job completes before the next trigger. None of these constraints is violated by a 10-second gap, which is why the underlying cause is the execution-context race, not the timing.

For the SINAMICS S120 side, the parameters consumed by this block are:

• r947[0..7] – current fault buffer (DO-specific). Each entry encodes the fault number, the SI/CI component, and the time stamp.
• r948[0..7] – current alarm buffer (DO-specific). Each entry encodes the alarm number and time stamp.
• r949[0..31] – fault acknowledgement history. Useful for diagnosis but not consumed by FBLDPV1GetDriveObjectAlarmsAndFaults.

All three are accessible through DPV1 acyclic services; the LDPV1 FB selects the correct subindex range and DO automatically based on the driveObjectNumber input.

Official reference: Siemens Support 109479553 – SIMATIC S7-1200/S7-1500 and SIMOTION: Acyclic Data Exchange (LDPV1 SIMOTION V4.2.12 manual). Cross-reference the SIMOTION D4xx Function Manual for the motion-task model and the SCOUT TIA Configuration Manual for the execution-system editor.

Error Code 16#411A — What Is Known and What Is Not

The hexadecimal code 16#411A falls in the SIMOTION technology-error class. Public Siemens documentation does not publish a single-line definition for this code in the LDPV1 context. Engineers searching the Siemens support site for "16#411A" or "411A" should consider the following:

• The code is returned only when an LDPV1 acyclic request is dispatched while the lower-layer acyclic job is still in the response-received or acknowledged-pending state. The fault reproduces regardless of the drive firmware version (tested on SINAMICS S120 V5.x and V6.x), which localises the cause in the controller-side state machine rather than the drive.
• The same code is reported by S7-1200 / S7-1500 LDPV1 instances when the user triggers a second REQ before the first DONE arrives. The underlying LDPV1 error code table in the library manual is the only authoritative source.
• Siemens Technical Support can map the technology error to a textual description if the firmware version, library version, and drive firmware are quoted. Open a Support Request with the SINAMICS support team and reference entry 109479553 plus the LDPV1 V4.2.12 manual.

The 0x41xx range is shared with other SIMOTION technology objects (TO, axis, cam, etc.). When correlating a captured errorID with documentation, ignore codes from other technology objects and treat 16#411A as a job-state error specific to the LDPV1 instance that raised it.

Best Practices and Common Pitfalls

• One execution context per instance. Allocate each LDPV1 instance DB to a single task (background or motion) and never call it from two tasks. The instance DB is the unit of state; the task is the unit of execution. Crossing the two breaks the state machine.
• Use the commandBusy output as the gate. Do not trigger a new REQ until commandBusy = FALSE. This holds true regardless of the chosen task, and protects against the second-call race even if the task is later changed.
• Prefer motion tasks for time-sensitive diagnostics. When the fault buffer is read by an HMI, a motion task keeps the acyclic channel drained and avoids background-task jitter that exposes the job-state conflict.
• Sequentialise multi-DO reads. Reading the fault buffer of N drive objects at the same time spawns N acyclic jobs; serialise them in one task to keep the channel utilisation predictable and below the PROFIdrive acyclic-channel limit.
• Update the library regularly. LDPV1 has been re-released multiple times in the 4.2.x line. The 4.2.12 release ships with bug fixes related to error reporting; later patches may improve the error code mapping for 16#411A. Check the Siemens support page for entry 109479553 for the latest revision.
• Capture errorID and driveObjectNumber on every error. The errorID is a SIMOTION technology error and must be interpreted with the firmware-specific manual; logging the DO number avoids hours of cross-referencing when multiple axes are involved.
• Avoid retriggering after a non-zero errorID without resetting the instance. The LDPV1 instance DB keeps the internal fault state until the next successful or user-reset cycle; retriggering from the application leaves the FB in an undefined state and amplifies the alternating pattern.
• Do not run the LDPV1 FB on the same IPO level as a servo with a sub-millisecond cycle. The motion task that drives the LDPV1 FB should be assigned to a higher (slower) level than the fast-servo tasks, so the LDPV1 acyclic response is processed before the LDPV1 motion task is scheduled again.

Diagnostic Decision Matrix

Frequently Asked Questions