Error -2147138448 Occurs When Using Softmotion SDI Framework

Updated Jun 6, 2018

Reported In


  • LabVIEW SoftMotion Module

Issue Details

Error -2147138448 occurs in the SDI Framework VI when creating a plugin for motors. The VI forces the scan engine into Configuration mode and will not force the scan engine back into active mode.


The actual error message for -2147138448 (which is an EtherCAT API error) is “The process data is not available, because another user is accessing the data or changing the memory mapping. Wait a few seconds and try again”. The point is that a piece of code is trying to write data to the Process Data Objects (PDO) memory manager when it is not allowed.

The problem is that the Timed While Loop inside the Process VI is executing so late that this code executes after the next Scan Engine cycle begins executing. When this happens, the EtherCAT PDO data is locked and any attempts to write it encounter this error.

There are two possible workarounds:

1. Ignore the error entirely 

It is possible to modify the Process VI and essentially ‘fix’ the framework VI if you are not happy with the reaction to errors. It would be very simple to create a new case in that case structure to ignore all errors or only error -2147138448.

2. Increase the Scan Engine period 
One way to help ensure the Process VI executes before the next Scan Engine execution is to increase the Scan Engine period, as it will at least double the amount of execution time allowed.

Additional Information

This is one of very few errors you could ever get from the Process VI, which is the core component of the SDI Framework. It does 6 things every Scan Engine period:

  1. Reads PDO data from the EtherCAT API for all slaves
  2. Reads SoftMotion data for each axis
  3. Handles Service Data Objects (SDO) operations for each axis
  4. Calls the Execute VI for each axis
  5. Writes SoftMotion data for each axis
  6. Writes PDO data to the EtherCAT API for all slaves 

The reason that the reaction to errors in the Process VI is setting the Scan Engine mode to Configuration mode is that new data is not written to the drive during that cycle. If this happens repeatedly, the overall motion control will be very poor, as position set points will not be updated to the drive’s position loop. However, if this is only happening after long periods, then it is likely being caused by a source of jitter in the plug-in, plug-in framework, or a priority inversion in LabVIEW RT. Essentially, the code runs on time 99.9999% of the time, but it fails to execute once in a long period.


Not Helpful