Arbitration

CompactRIO Reference and Procedures (FPGA Interface)

Edition Date: June 2010

Part Number: 370984T-01

»View Product Info

Each CAN port uses dedicated resources in LabVIEW FPGA, as well as distinct communication paths between LabVIEW FPGA and the module. Therefore, when you access two different CAN ports in your FPGA VI, the nodes in the LabVIEW FPGA VI block diagram execute independently. For example, if you output a CAN frame to CAN0 and simultaneously output a CAN frame to CAN1, the two CAN Output nodes execute independently. As another example, access to CAN0 on a module in slot 1 occurs independently from access to CAN0 on a module in slot 2.

When two or more nodes in the LabVIEW FPGA VI block diagram access the same CAN port at the same time, arbitration can occur to determine which node executes first. This arbitration may cause delays or jitter in your application. For example, if you want to transmit a specific CAN frame when a digital input trigger is detected in LabVIEW FPGA, arbitration between the CAN Output node and other CAN nodes can cause jitter from the digital input pulse to the start of the CAN frame.

Node Arbitration

For the same CAN port, CAN nodes of the same type must arbitrate. There are four types of CAN nodes:

  • CAN Input
  • CAN Output
  • I/O Method Node
  • I/O Property Node

CAN nodes of different type do not arbitrate at the node level.

For most applications, CAN node arbitration does not occur, and when it does the jitter introduced is small. For example, you would not normally use two CAN Input nodes simultaneously on the same CAN port, because neither node would return the correct sequence of CAN frames.

The most common situation in which CAN node arbitration occurs is use of a Wait I/O Method simultaneously with another I/O Method. For example, if you invoke Wait on Transmit Complete with a Timeout of 10 seconds, then invoke Abort Transmit soon after, node-level arbitration causes the Abort Transmit to execute after the Wait on Transmit Complete (possibly 10 seconds after invocation). When using multiple I/O Methods, you can avoid this behavior by polling for the event using Timeout of 0.

Output Path Arbitration

For each CAN port, two communication paths exist between LabVIEW FPGA and the CAN module. The output path transfers information from LabVIEW FPGA to the CAN port, and the input path transfers information from the CAN port to LabVIEW FPGA.

When two or more nodes in the LabVIEW FPGA VI block diagram access the same CAN port, arbitration can occur for the underlying output path. This arbitration is different than the usual node arbitration in LabVIEW FPGA, which is limited to multiple instances of a node. For example, if you write a frame to CAN0, and read a property on CAN0 at the same time, arbitration occurs for the output path, because the CAN Output Node and the I/O Property Node both send information from LabVIEW FPGA to the CAN port.

The following nodes use the output path to the CAN port:

  • CAN Output
  • I/O Method Node: Abort Transmit
  • I/O Method Node: Reset
  • I/O Method Node: Start
  • I/O Method Node: Stop
  • I/O Property Node: Read any property
  • I/O Property Node: Write any property

When two or more of these nodes execute simultaneously for the same CAN port, arbitration occurs to force sequential execution, and some jitter may result. When arbitration occurs in the same FPGA clock cycle, CAN Output is prioritized first, then the I/O Method Node, then the I/O Property Node. When the nodes are the same, CAN node arbitration occurs.

The output path is implemented as a FIFO. This allows multiple frames to be sent to the CAN module for transmit, thus enabling tests that generate full bus load.

All nodes in the preceding list use the output FIFO with the exception of the Stop and Reset method. Since these methods stop CAN communication, they must execute regardless of pending transmit frames. Once the Stop or Reset method arbitrates successfully for the output path, it bypasses the FIFO and transfers the method to the CAN port for immediate execution.

When the output FIFO is full, a node in the preceding list (except Stop and Reset) must wait for an element to become available. This generally occurs when a frame from a previous CAN Output transmits successfully onto the network. The Output Timeout (ms) in the CAN Advanced Port Configuration dialog box specifies how long to wait for a new element to become available. Therefore, the Output Timeout (ms) applies to any CAN node in the preceding list, not just the CAN Output node.

If you specify Output Timeout (ms) of 0, the node simply checks to see if a new element is available (non-blocking). If an element exists, the node executes and error status of FALSE is returned (success). If no element exists, the node fails to execute, and error status of TRUE is returned (error). Therefore, in order to poll (such as writing frames without waiting), you must enable Error Terminals for the node. When an error is returned, you must attempt to execute the node again at a later time.

Input Path Arbitration

For the input path from the CAN port to LabVIEW FPGA, arbitration does not occur within LabVIEW FPGA. As soon as the CAN module has data for LabVIEW FPGA nodes, the data transfers immediately.

When the CAN port attempts to transfer information for two or more nodes back to LabVIEW FPGA, arbitration for the input path occurs within the CAN module. For example, if a CAN frame is received at the same time that a property is read, the CAN module must decide which node's data to transfer first. Although this input path arbitration can cause jitter, that jitter is minimal compared to the effects you can see from CAN node arbitration or CAN output path arbitration.

Module Configuration

The configuration information in Module Configuration is transferred from LabVIEW FPGA to the CAN module when the FPGA VI runs. Although this transfer occurs automatically as soon as the VI begins to run, all CAN nodes must wait for this one-time configuration to complete. The time required for configuration can be up to 1 second.

If your FPGA VI does not execute a CAN node before the configuration time elapses, you will not notice any delay. If a CAN node is executed before the configuration time elapses, the CAN node will wait for configuration to complete, then execute normally. If you execute CAN nodes in a manner that does not depend on timing, this behavior is not a concern. However, if you require the first CAN Input or CAN Output in your FPGA VI to execute without delay, you can do this by adding one of the following to the beginning of your VI (before the main loop):

  • 1 second delay
  • CAN Property or Method node (for instance, a Start method node)

Summary

When an FPGA VI is limited to CAN Input and CAN Output for each CAN port, the jitter between node execution and CAN frame transfer is very small. This is due to the fact that each CAN port uses a distinct communication path for input data and output data.

When you mix methods or properties along with input/output, you may see increased jitter between node invocation and CAN frame transfer. This jitter is due to the arbitration. The jitter is typically only a few microseconds, so it will generally be well within the limits for your application.

WAS THIS ARTICLE HELPFUL?

Not Helpful