Using NI SoftMotion with the NI Scan Engine
To use NI SoftMotion function blocks or Axis Interface nodes with your hardware, you must create axes, coordinates, and tables in the LabVIEW project. These items are associated with motion I/O resources and used when creating motion applications using NI SoftMotion function blocks or Axis Interface nodes. Use the Axis Manager dialog box to associate your hardware with an NI SoftMotion axis. An axis consists of a trajectory generator, proportional integral derivative (PID) control loop or stepper output, and supervisory control. You can associate an NI SoftMotion axis with simulated hardware or with actual hardware. Servo axes require an encoder feedback resource. Open-loop stepper axes do not require feedback for operation.
You can create the following axis types based on the hardware you associate with your NI SoftMotion axis:
- NI 951x axis (Scan Interface Mode)
- Simulated axis
- SolidWorks axis
- Unbound axis
Figure 1. The NI SoftMotion Axis Manager Dialog Box
Use the Configure Coordinate Space dialog box to organize axes into coordinates. A coordinate is a logical grouping of axes that you use as an input to NI SoftMotion function blocks that can use coordinate resources. With coordinates, you can command a move using multiple axes and guarantee that the axes both start and stop at the same time. This is in contrast to starting individual axes that are not part of a coordinate at the same time − the axes start the move synchronized but do not stop synchronized.
Figure 2. The NI SoftMotion Configure Coordinate Space Dialog Box
Figure 3. LabVIEW Project with Configured Motion Axis and a Coordinate Space
All motion I/O and execution information is added to the global scan engine memory map and updated each scan cycle. Function blocks that are executed in the same scan cycle start synchronized in the same scan cycle, including Line, Stop, Gearing, and Camming. This means that you can start an axis, coordinate, gearing operation, or camming operation all in the same scan cycle. However, the axes that you start simultaneously in this way do not stop simultaneously. To simultaneously end the moves, you must calculate the move constraints to end motion on all axes at the same time or configure a coordinate so that these values are calculated automatically.
Because function block execution is tied to the scan engine period, there may be a small delay when responding to an external event, when synchronizing different axis types, and so on. Table 1 defines the minimum and maximum delays.
Delay in Scan Periods
|Limit and home switch activation||1 ≤ delay < 2|
|Gearing and camming with encoder master||Slave output lags master output by two scan cycles|
|Position error||1 scan cycle for the axis with position error, up to 2 scan cycles to decelerate the other axes in the coordinate|
|NI 951x and custom axes||1 scan cycle delay for custom axis relative to NI 951x axes|
Table 1. Function Block Execution Delays
Using NI SoftMotion Function Blocks
The LabVIEW NI SoftMotion Module provides function blocks to build deterministic motion control applications using the function block programming paradigm.
LabVIEW features function blocks based on the IEC 61131-3 international standard for programming industrial control systems. These function blocks, which are designed for use in real-time applications, have the ability to publish their parameters as shared variables for human machine interface (HMI) programming and status monitoring. You can take advantage of these familiar industrial function blocks with all of the VIs and functions in LabVIEW to develop simple and complex industrial measurement and control applications.
You can use the LabVIEW function blocks, which install with the LabVIEW Real-Time Module, in LabVIEW Real-Time and LabVIEW for Windows. LabVIEW NI SoftMotion installs additional function blocks that provide motion functions and allow you to use the LabVIEW project to configure and test your motion axis settings and tune your servo motors. LabVIEW NI SoftMotion is included on the LabVIEW Platform DVDs. You can install a 7-day evaluation version of the module or use a free version of the module with limited functionality.
Function blocks are written in LabVIEW and designed for use in real-time applications with nonblocking deterministic execution, making them safe to use in your time-critical code. Each instance of a function block has a unique name and memory space with reentrant execution. Because of this, you can use these function blocks independently throughout your application. For example, you can use each instance of the PID function block to control a separate system.
The function blocks you use in your application are visible in the LabVIEW project with remote access to shared variables that are bound to each terminal. You configure the terminals and variables from the function block Properties page.
By default, terminal variables are configured as single-process real-time FIFO-enabled shared variables, which you can use throughout your real-time application for jitter-free access to parameter values. You can configure each terminal to receive its value from the terminal on the block diagram, remotely from the corresponding shared variable, or as a constant.
You can configure terminal variables as network-publish shared variables to give remote access to parameter values for HMI programming and remote monitoring. For HMI programming, you can use the shared variables in LabVIEW applications on your desktop or industrial touch panel computer. The NI Distributed System Manager provides a central location for monitoring systems on the network and managing published data. From the system manager, you can view function block parameter values without needing the LabVIEW development environment. By configuring a function block terminal to receive its value from the variable, you can also write to parameter values from the system manager, so you can remotely tune PID function blocks, for example.
NI SoftMotion function blocks also contain additional parameters used to monitor and maintain the state of each function block. The function block API for NI SoftMotion is a nonblocking, or asynchronous, API you use to communicate with your motion hardware.
The following table provides a motion function block overview.
|Line||Performs a straight-line move using an axis or coordinate resource. A straight-line move connects two points using one or more axes. The behavior of the move changes based on the Straight-Line Move Mode.|
|Arc||Performs a circular, spherical, or helical arc move. An arc move produces motion in a circular shape using a radius you specify. The type of arc to perform changes based on the Arc Move Mode.|
|Contour||Performs a contour move using an axis or coordinate resource. A contour move is a move expressed as a series of positions that the software uses to extrapolate a smooth curve. These positions are stored in a table. Each point in the move is interpreted as an absolute position using the starting point of the move as a temporary "zero" position. The type of contour move changes based on the Contour Mode.|
|Reference||Performs a reference move, such as locating a home or limit position, on an axis resource. Reference moves are used to initialize the motion system and establish a repeatable reference position. The behavior of the move changes based on the Reference Move Mode.|
|Capture||Records encoder position based on an external input, such as the state of a sensor. You can use the captured position to execute a move relative to a captured position, or simply record the encoder position when the capture event occurs.|
|Compare||Synchronizes the motor with external activities and specified encoder positions. When the specified position is reached, a user-configurable pulse is executed. The behavior of the position compare operation changes based on the Compare Mode.|
|Gearing||Configures the specified axis for gearing operations. Gearing synchronizes the movement of a slave axis to the movement of a master device, which can be an encoder or the trajectory of another axis. The movement of the slave axes may be at a higher or lower gear ratio than the master. For example, every turn of the master axis may cause a slave axis to turn twice. The type of gearing operation to perform changes based on the Gearing Mode.|
|Camming||Configures the specified axis for camming operations. These ratios are handled automatically by NI SoftMotion, allowing precise switching of the gear ratios. Camming is used in applications where the slave axis follows a nonlinear profile from a master device. The type of camming operation changes based on the Camming Mode.|
|Read||Reads status and data information from axes, coordinates, feedback, and other resources. Use the available read methods to obtain information from different resources.|
|Write||Writes status and data information to axes, coordinates, or feedback resources. Use the available write methods to write information to different resources.|
|Reset Position||Resets the position on the specified axis or coordinate.|
|Stop||Stops the current motion on an axis or coordinate. The behavior of the move changes based on the Stop Mode.|
|Power||Enables and disables axes and/or drives on the specified axes or coordinate resources.|
|Clear Faults||Clears NI SoftMotion faults.|
The following tips may help you when programming with NI SoftMotion function blocks in LabVIEW:
- Function blocks must be executed in a VI that is part of a LabVIEW project
- Function blocks must always be run in a loop. Depending on your application requirements, you can use either a while loop timed using a Wait Until Next ms Multiple Function or you can use a timed loop synchronized to the NI Scan Engine if your application requires that the function blocks execute at the scan period.
- Use the function block status outputs − not standard LabVIEW programming methods − to determine the order of function block execution. For example, do not place function blocks inside a case structure.
- You must initialize all array outputs outside the application loop so that the function block does not allocate memory. This reduces drift and jitter in the system.
To determine the order of function block execution, the motion function blocks offer status parameters. The following list provides an overview of function block status parameter behaviors.
The execute, error out, done, aborted, busy, and active parameters behave according to the following guidelines:
|Output status||The done and aborted outputs are reset with the falling edge of execute. However, the falling edge of execute does not stop or influence the execution of the actual function block. It must be guaranteed that the corresponding outputs are set for at least one cycle if either of these statuses occur − even if execute was reset before the function block completed. If an instance of a function block receives a new execute before it finishes (as a series of commands on the same instance), the function block does not return any status outputs such as done or aborted for the previous execution of the function block.|
|Input parameters||The function block input parameters are used with the rising edge of the execute input. To modify any parameter, it is necessary to change the input parameter(s) and execute the function block again.|
|Unwired input parameters||If any function block input is unwired, the value from the previous execution of this function block is used. On the first execution of the function block, the default value is applied.|
|Sign rules||Acceleration, deceleration, acceleration jerk, and deceleration jerk inputs are always positive values. Target positions and distance can be both positive and negative. Velocity is positive in all cases except when performing a straight-line move using the velocity method.|
|Error handling behavior||
All function blocks have an error out cluster that deals with errors that can occur while executing that function block. These outputs are defined as follows:
When an error occurs in a function block, the execution time may be increased.
|Behavior of done output||The done output is set when the commanded action successfully completes. When multiple function blocks operate on the same resource in sequence and movement on a resource is interrupted with another movement on the same resource without having reached the final goal, done of the first function block is not set.|
|Behavior of aborted output||
Aborted is set when a commanded operation is interrupted by another command. The reset behavior of aborted is like that of done. When aborted occurs, the other output signals are reset.
Aborted does not return TRUE when you interrupt execution of a function with another function that uses a different resource type. For example, executing a straight-line move on an axis that is part of a coordinate does not abort the coordinate move that is in progress. Instead, the arc move sets done to TRUE and stops execution.
|Inputs exceeding application limits||If a function block is commanded with parameters that result in a violation of application limits, the instance of the function block generates an error.|
|Behavior of busy output||Every function block has a busy output, indicating that the function block operation is not complete. Busy is set at the rising edge of execute and reset when done, aborted, or error out is set. It is recommended that the application controlling the execution of this function block not be terminated for at least as long as busy is TRUE because the software may be left in an undefined state.|
|Output active||The active output is set to TRUE at the moment the function block takes control of the specified resource, all properties have been committed, and the function block has executed. Once the active output is TRUE, the function block takes effect on the next scan cycle.|