Function Calls That Are Blocking
Most functions in the WMX3 library are non-blocking, meaning that they will finish execution and return processing to the calling thread within a few microseconds or less.
However, some functions or conditions will cause functions to block for a length of time up to one communication cycle or more. The causes of these delays and potential workarounds are discussed in this page.
Function Calls During Interrupt Processing
The WMX3 engine processes the interrupt (see Function Calls Affected by Interrupts) every cyclic period (Cycle Time Milliseconds) to communicate with the servo network. If a WMX3 library function is called while the engine is processing the interrupt, or if the interrupt occurs before the function completes, the execution of the function will be delayed until the interrupt finishes.
The time taken to process the interrupt is affected by the speed of the CPU, the number of axes in the network, and the function that is currently executed by the axes.
Certain functions do not need to communicate with the engine, and will execute with no delay even if the function is called while the WMX3 engine is processing the interrupt. These functions include:
ErrorToString (of every module)
GetLibVersion (of every module)
“Wait Until Motion Start” Parameter
If the Wait Until Motion Start parameter is set to TRUE, most motion functions will block and not return until the end of the next interrupt. This allows the user to not check if the motion has started before executing an override motion function from the same thread.
If this parameter is set to FALSE, or if the override motion command will be called from a different thread, the Command Ready status must be checked before calling the override motion function. If the override motion function is called before the first interrupt after the motion starts, the StartingPreviousCommand error will be returned. For example, if Cycle Time Milliseconds is 1ms, then calling StartPos and then calling StartPos again before 1ms elapses can cause this error to be returned.
The Wait Until Motion Start parameter is set to TRUE by default, but can be changed using SetParam or any other function that sets this parameter.
The following functions are affected by this parameter.
Sync::SetSyncGearRatio (when starting a new sync control)
Functions That Block Until the End of the Next Interrupt
The following functions will block and not return until the end of the next interrupt.
Wait Functions
The Wait functions in the CoreMotion module will intentionally block and not return until the specified condition is satisfied. The thread executing the function will be suspended until the condition is satisfied.
Path Interpolation with Look Ahead
Path interpolation with look ahead will require heavy processing time, especially if the number of points is very large. The AddPathIntplWithRotationCommand function may block for a long time (potentially hundreds of milliseconds or multiple seconds depending on the number of points) before returning.
RemoveEvent and ClearAllEvent
The RemoveEvent and ClearAllEvent functions will block execution until the next interrupt finishes. The specified events are removed during the interrupt. If communication is stopped and events are not being processed, these functions are non-blocking and will remove the specified events immediately.
ApiBuffer Mode Change Functions
The following mode change functions from the ApiBuffer module will block until the mode change completes (typically 1ms) or the mode change request times out (50ms).