Custom Device Types
The custom device type refers to its execution mode. The mode defines how the device interacts with the VeriStand Engine.
The VeriStand Engine is the non-visible mechanism that controls system timing and communication between the Target and Host Computer. While deployed to the Target, all custom devices run inside the engine.
The niveristand-custom-device-wizard generates a new LabVIEW Project containing one of five device frameworks. The framework is determined by the Custom Device Execution Mode.
The selected mode determines when the device will run with respect to the other operations performed by the VeriStand Engine. There are five device frameworks available. Three of the frameworks are for custom devices, and the other two are for custom timing and synchronization devices.
Custom timing and synchronization devices are the same as regular custom devices, but they can be configured as the hardware synchronization master to drive RTSI0. For more information, refer to Real-Time System Integration (RTSI) and Configuration Explained.
Custom timing and synchronization devices are not covered in detail in this document. For more information about custom timing and synchronization devices, refer to the VeriStand Help topic Adding and Configuring Timing and Sync Devices. Multi- chassis synchronization may also be accomplished using built-in features. For more information, refer to Creating a Distributed System With NI VeriStand.
Two of the regular custom devices run in-line with the Primary Control Loop (PCL), the other runs in parallel with the PCL. A custom device is not limited to using just one type of framework. Some developers have built both in-line and parallel engines for a single custom device and allow the operator to select which mode to deploy.
Depending on your needs, you can alter the code within the framework. However, you must maintain the connector pane, controls, and indicators provided by the niveristand-custom-device-wizard. VeriStand uses these objects to interface with the custom device. If they are changed, the custom device will experience errors.
Asynchronous
The asynchronous custom device framework provides a simple, single-loop architecture. There are sections for initialization and cleanup before and after the loop.
Note: The asynchronous template provides a While Loop that can be exchanged for a Timed Loop.
The loop runs in parallel to the PCL. If proper real-time development practices are adhered to, it is unlikely to block or slow the PCL. The rest of the VeriStand system will continue to execute as expected even if the asynchronous custom device is latent or stalls.
The loop can be synchronized to the PCL’s timing source, making it pseudo-synchronous. This applies to asynchronous devices that use a Timed Loop. While Loops cannot be used for this purpose.
The benefit of an asynchronous custom device synchronized to the PCL is that it will not cause the PCL to be late if the device is late. VeriStand ticks the device clock for all Timed Loops that have Use Device Clock set to true.
The asynchronous device can run at a different rate than the PCL. You can define the rate using any execution timing method available in LabVIEW. The rate can iterate faster than the PCL or be a decimation of the PCL rate specified using the NI VeriStand - Set Custom Device Decimation VI. This VI can be found in LabVIEW by navigating to NI VeriStand » Custom Device API » Configuration » Item Properties » Device Properties.
The asynchronous template uses RT FIFOs, specifically Device Inputs FIFO and Device Outputs FIFO, to exchange channel data with the rest of VeriStand. Since the asynchronous device runs in parallel to the PCL and passes channel data through RT FIFOs, there is a minimum of one cycle delay from when data travels back and forth from the PCL to the custom device. These FIFOs correspond to those in the VeriStand Engine.
The asynchronous device is not guaranteed to execute at the same time as other components of the system. For example, the first iteration may execute before the PCL processes alarms.
The input controls are specially named controls that the system will use to provide the device loop with data. The controls are not required for the device loop to run. For example, if the device doesn’t produce any output data, then you don’t need the Device Outputs FIFO control. If you do need these controls, they must have these exact names to be functional.
The optional notifier status element is used to notify the engine of the last state of the custom device and to indicate the device has completed execution. If this control is not used, a default No Error value is returned to the system when the device finishes execution. This error state is not checked until the system shuts down. Use an output channel to send more immediate status values to the system.
The asynchronous framework includes VIs from the VeriStand Asynchronous Device Properties VIs subpalette.
Inline Hardware Interface
The inline hardware interface template is similar to a state machine architecture.
Note: Some developers will recognize it as an action-engine. For a discussion on action engines, refer to the NI Discussion Forums post Community Nugget 4/08/2007 Action Engines.
The PCL specifies the case to execute. An uninitialized Feedback Node is used for iterative data transfer.
There are five cases defined by the Operation enumerated control.
Initialize
Start
Read Data from Hardware
Write Data to Hardware
Close
This custom device runs in-line with the PCL, which calls each case at a specific time with respect to the other components in the VeriStand Engine. The PCL will not proceed until the custom device case has completed.
Initialize Case
The Initialize case executes before the PCL starts. Inside the case, you can use a device reference to extract configuration information from device properties. Initialize data and buffers are used internally in the device.
The framework compiles the list of data references for the custom device Inputs and Outputs. This is done in advance using VeriStand Data References VIs, specifically the NI VeriStand - Get Channel Data Reference VI.
Note: Because the PCL has not started, channel values cannot be read or written in the Initialize case.
Start Case
The Start case executes after initialization but before the PCL runs. There is no difference between what code you can place in the Initialize and Start states.
Note: Because the PCL has not started, channel values cannot be read or written in the Start case.
Read Data from HW Case
The Read Data from HW case executes at the beginning of the PCL, before other components, such as alarms, and procedures, execute.
After processing system mappings, the data obtained in this case is available to the other components of the system for the remainder of the PCL iteration. For a detailed timing diagram, refer to Outline of PCL Iteration.
The template contains a Flat Sequence frame named Read Hardware Channels. You can replace the code inside the frame with the API calls necessary to obtain data from a hardware API.
Write Data to HW Case
The Write Data to HW case executes at the end of the PCL, after the other components have executed.
The case contains a Flat Sequence frame named Write Input Data to Hardware Channels. You can replace the code inside the frame with the API calls necessary to send data to a hardware device.
Close Case
The Close case executes after the PCL has finished executing. You should close references and release resources in this state.
Note: Because the PCL has terminated, channel values cannot be read or written in the Close case.
Inline-Async Hardware Interface
You can generate an inline-async custom device template from the niveristand-custom-device-wizard. When creating a project, set the execution mode to Inline HW Interface and enable Use Inline-Async API.
By using the Inline-Async-API, the inline-async template framework can perform the following actions.
Initializing asynchronous VIs.
Launching asynchronous VIs.
Cleaning up asynchronous VIs.
Handling and reporting errors.
Transferring data between inline and asynchronous VIs.
The RT Driver VI of an inline custom device can communicate channel data with VeriStand. While doing so, the VI can also launch an asynchronous loop(s) to handle nondeterministic operations.
One example of a nondeterministic operation is log file data writing. The RT Driver VI of the inline custom device communicates with the asynchronous loop(s) using RT FIFOs.
Note: While the RT Driver VI is using RT FIFOs, data may be lost if elements are not read at a fast enough rate.
Inline Model Interface
The Inline Model Interface custom device template also has a state machine/action engine architecture. The template uses an uninitialized Feedback Node for iterative data transfer.
There are four cases defined by the Operation enumerated control.
Initialize – Same configuration as the Inline HW Interface.
Start – Same configuration as the Inline HW Interface.
Execute Model
Close – Same configuration as the Inline HW Interface.
This custom device is run in-line with the PCL. The device calls each case at a specific time with respect to the other components in the system. The PCL will not proceed until the custom device case has completed.
Execute Model Case
The Execute Model case is called and runs in the middle of the PCL.
This state takes the following steps.
Reads input data.
Performs a calculation.
Writes output data to VeriStand.
Using the Inline Model Interface mode enables you to process data acquired from hardware inputs and send the processed values to hardware outputs with no latency.
Inline Timing and Sync
The inline timing and sync custom device is similar to the inline hardware interface custom device. The major difference between the two custom device types is that the inline timing and sync custom device can also function as a hardware synchronization master device to drive the RTSI 0 line.
Asynchronous Timing and Sync
The asynchronous timing and sync custom device is similar to the asynchronous custom device. The major difference between the two custom device types is that the asynchronous timing and sync custom device can also function as a hardware synchronization master device to drive the RTSI 0 line.
Outline of PCL Iteration
The order of operations in the Primary Control Loop varies with respect to the execution mode of the controller.
Note: You can adjust the settings in System Explorer by navigating to Targets » Controller » Other Settings » Execution Mode.
The Data Processing Loop is responsible for executing procedures, alarms, and calculated channels. For more information on hardware timing in VeriStand, refer to the KnowledgeBase topic Hardware I/O Latency Times in NI VeriStand.
The following diagram displays the operation of the VeriStand Engine.
Parallel Mode
In Parallel mode, the PCL initiates execution of models and continues to its next iteration without waiting for models to finish executing. This causes a one-cycle delay between when a model executes and when the data it produces is available to the system.
The following are the steps that the PCL takes while in parallel mode.
Gets inputs from hardware devices in the system definition.
Note: If the system includes an inline hardware interface custom device, the PCL reads DAQ digital lines and counters after the Read Data from HW case of the custom device executes in step 3.Reads asynchronous custom device FIFOs from the previous iteration.
Runs the Read Data From HW case of inline hardware interface custom devices.
Note: If you configured hardware scaling, VeriStand applies the scaling after acquiring all hardware inputs.Reads previous iteration data from models in the system definition.
Note: This step executes on the second and subsequent iterations.Reads data from the previous iteration of the Data Processing Loop.
Processes system mappings.
Note: VeriStand components and custom devices cannot read data from a previous step until the PCL processes system mappings. This is true even if the previous step acquired the data the component needs.Runs the Execute Model case of inline model interface custom devices.
Executes steps of running real-time sequences.
Notes:VeriStand executes real-time sequences after input operations but before output operations. VeriStand continues to run every step of the real-time sequence until the sequence is complete, reaches a Yield step, or completes an iteration of a loop with Auto Yield set to
TRUE. If a sequence takes longer than the given time for an iteration of the PCL, the PCL runs late.To avoid errors, break up the timing of the steps by placing Yield steps throughout the sequence and enabling the Auto Yield property for any loops in the sequence.
Processes system mappings.
Writes data to models.
Initiates asynchronous execution of models.
Writes data to the Data Processing Loop.
Writes output data to hardware devices.
(Optional) For inline hardware interface custom devices, runs the Write Data to HW case.
Writes data to asynchronous custom device FIFOs.
Low Latency Mode
In Low Latency mode, the PCL waits for the Model Execution Loop(s) to finish writing data to models before it reads and publishes model values to the system. This occurs during every iteration of the system.
When the model completes execution, the PCL provides data from the model to other loops during the same iteration that the model generated the data.
The following are the steps that the PCL takes while in low latency mode.
Gets inputs from hardware devices in the system definition.
Note: If the system includes an inline hardware interface custom device, the PCL reads DAQ digital lines and counters after the Read Data from HW case of the custom device executes in step 3.Reads asynchronous custom device FIFOs from the previous iteration.
Runs the Read Data from HW case of inline hardware interface custom devices.
Note: If you configured hardware scaling, VeriStand applies the scaling after acquiring all hardware inputs.Reads data from the previous iteration of the Data Processing Loop.
Processes system mappings.
Note: VeriStand components (including custom devices) cannot read data from a previous step until the PCL processes system mappings, even if the previous step acquired the data the component needs.Runs the Execute Model case of inline model interface custom devices.
Executes steps of running real-time sequences.
Notes:VeriStand executes real-time sequences after input operations but before output operations. VeriStand continues to run every step of the real-time sequence until the sequence is complete, reaches a Yield step, or completes an iteration of a loop with Auto Yield set to
TRUE. If a sequence takes longer than the given time for an iteration of the PCL, the PCL runs late.To avoid errors, break up the timing of the steps by placing Yield steps throughout the sequence and enabling the Auto Yield property for any loops in the sequence.
Processes system mappings.
Writes data to models.
Initiates execution of models and waits for them to complete execution.
Reads data from models.
Processes system mappings.
Writes data to the Data Processing Loop.
Writes output data to hardware devices.
(Optional) For inline hardware interface custom devices, runs the Write Data to HW case.
Writes data to asynchronous custom device FIFOs.