XNET Create Timing Source (FlexRay Cycle) VI

Inputs/Outputs

Description

Use this VI to synchronize your LabVIEW Real-Time application to the deterministic FlexRay cycle. Because the FlexRay cycle repeats every few milliseconds, real-time execution is required, and therefore this VI is not supported on Windows.

You can create only one FlexRay Cycle timing source for each FlexRay interface. You can wire a single timing source to multiple Timed Loops.

The following sections include more detailed information about using this VI:

Using the Timed Loop

Session Start and Stop

Macrotick Offset

Using the Timed Loop

This section includes guidelines for using the LabVIEW Timed Loop with the NI-XNET FlexRay Cycle timing source. For complete information, refer to the LabVIEW help topics for the Timed Loop.

The Timed Loop contains the nodes described below.

Input Node

Source Name: Wire the timing source name output of this VI to this terminal on the Timed Loop input node. This specifies the XNET timing source and overrides the default built-in timing source (1 kHz).

Period: For most applications, you wire the constant 1 to this terminal, which overrides the default of 1000. The Period specifies the number of timing source ticks that must occur for the loop to iterate. A value of 1 iterates the Timed Loop on every FlexRay cycle. Higher values skip FlexRay cycles (for example, 2 iterates the loop every other FlexRay cycle).

Timeout: For most applications, you wire the constant 300 to this terminal, which overrides the default of –1. The Timeout specifies the maximum number of milliseconds to wait for a tick. For this FlexRay cycle timing source, this timeout primarily applies to the first loop iteration. According to the FlexRay specification, the process of fully synchronizing the distributed network clocks can take as long as 200 ms. This network clock synchronization is required for the NI-XNET interface to detect the first FlexRay cycle and send a tick to the Timed Loop. If network communication problems occur (for example, noise on the cable), the first tick does not occur. Using a value of 300 for this terminal ensures that if problems occur on the FlexRay network, the Timed Loop can recover (refer to Wake-Up Reason in Left Data Node).

Error: Use this terminal to propagate errors through the Timed Loop. The Timed Loop does not execute if this terminal receives an error condition. You typically wire the error out from this XNET Create Timing Source (FlexRay Cycle) VI to this terminal. This avoids the need for alternate error propagation techniques, such as a shift register.

Left Data Node

Error: Propagates errors through the structure. Wire this terminal to error in of the first VI within the subdiagram.

Wake-Up Reason: If the first Timed Loop iteration encounters a Timeout due to problems on the FlexRay network, this terminal returns a value of 5 (Timeout). When the timeout occurs, the Timed Loop does not return an error condition from Error. The timeout causes the iteration to execute untimed, then try again on the next iteration. If the FlexRay tick occurs as expected, Wake-Up Reason returns a value of 0 (Normal).

Right Data Node

Error: Propagates errors from the subdiagram out of the Timed Loop. If Error receives an error condition, the Timed Loop finishes executing the current iteration untimed, exits the loop, and returns the error condition on the Output Node. If you want the Timed Loop to exit on error, wire error out from the last VI in the subdiagram to this terminal.

Output Node

Error: Propagates errors the Timed Loop receives and returns errors from the subdiagram.

Session Start and Stop

When the Timed Loop input node executes, the XNET session for the timing source is started automatically. This auto-start is equivalent to calling the XNET Start VI (Normal). This auto-start is performed even if the session's Auto Start? property is false. Because the Timed Loop uses an execution priority that typically is higher than the VIs that precede it, starting FlexRay communication within the Timed Loop ensures that you do not miss the first FlexRay cycle. Due to these factors, do not call the XNET Start VI prior to the Timed Loop (use the Timed Loop auto-start instead).

After the initial session and interface auto-start, the Timed Loop Timeout is used to wait for communication to begin.

When the Timed Loop exits to its output node, the XNET session remains in its current state. The Timed Loop does not stop or clear the session, so you can continue to use the session in VIs that follow.

Macrotick Offset

To set the macrotick offset, it helps to understand some NI-XNET implementation aspects. When the FlexRay Communication Controller (CC) receives a frame, the NI-XNET hardware immediately transfers that frame to LabVIEW Real-Time (RT). This transfer is performed using DMA (Direct Memory Access) on the PXI backplane, so that it occurs quickly and with negligible jitter to your LabVIEW RT execution.

Figure 1 shows the effects of this implementation. In this example, the macrotick offset is set to occur at the end of slot 1. The subdiagram in the Timed Loop calls the XNET Read VI to read the value received from slot 1.

For better visibility in Figures 1, 2, and 3, the NI-XNET blocks (Read/Write, DMA I/O, an dCC I/O) are longer than actual performance. When using a PXI controller for LabVIEW Real-Time, your results typically will be faster. This is especially true if your application does not transfer data on the PXI backplane continuously (for example, streaming analog, vision, or TCP/IP data), as this sort of transfer can adversely impact the NI-XNET DMA latencies.

Figure 1—FlexRay Frame Timed Read

Figure 1 shows that the DMA input transfer for slot 1 (IN1) occurs at the same time as the XNET Read VI for slot 1 (R1). Depending on which one completes first, the XNET Read VI may return a value from the current cycle (3) or the previous cycle (2).

To prevent this uncertainty, macrotick offset must be large enough to ensure that the frame DMA input is complete. Relative to Figure 1, setting macrotick offset to the end of slot 2 would suffice.

When your LabVIEW RT application calls the XNET Write VI, the frame values are transferred immediately using DMA. The frame values are transferred to the NI-XNET hardware onboard processor memory. For efficiency reasons, this onboard processor waits until the FlexRay cycle Network Idle Time (NIT) to transfer the frame values from its memory to the FlexRay Communication Controller (CC). The FlexRay Communication Controller transmits each frame value according to its slot configuration in the cycle.

Figure 2 shows the effects of this implementation. This example expands on Figure 1 by calling the XNET Write VI with a value for slot 8. The XNET Write VI (W8) is called well in advance of slot 8 in the cycle. The DMA output transfer for the value of slot 8 (D8) occurs immediately after the XNET Write VI. Nevertheless, the value for slot 8 is not placed into the FlexRay Communication Controller until the NIT time, shown as C8. This means that although the XNET Write VI was called before slot 8's occurrence in the current cycle 3, that value does not transmit until the subsequent cycle 4.

This implementation for output means that it is not necessarily urgent to call the XNET Write VI before the relevant slot. You merely need to provide time for the XNET Write VI and the related DMA output to complete prior to the NIT.

Figure 2—FlexRay Frame Timed Write

Taking these implementation considerations into account, the typical macrotick offset goal is a value that executes the Timed Loop after the last cycle input DMA and prior to the NIT. Ideally, the macrotick offset provides sufficient time for input DMA, the XNET Read VI, LabVIEW code within the Timed Loop (for example, a simulation model), the XNET Write VI, and DMA output.

To find a value for macrotick offset, you can use the XNET Cluster property node. The FlexRay:NIT Start property provides the macrotick offset for the start of NIT, which is your upper limit. To determine the lower limit, the FlexRay:Static Slot property provides the number of macroticks for each static slot. Static slot numbers begin at 1. Assuming static slot X is the last slot that you read, the lower limit for macrotick offset is (X x FlexRay:Static Slot).

The following example demonstrates a technique for calculating macrotick offset. The example uses a simple FlexRay cluster configured as follows:

• Baud Rate—5000000 bps (5 Mbps)
• Macrotick—1 (1 µs duration)
• Macro Per Cycle—1000 (1 ms)
• Number of Static Slots—10
• Number of Minislots—80
• Static Slot—58 MT (16 byte payload)
• NIT Start—900 MT offset
• NIT—100 MT (duration)

Within the Timed Loop, the example does the following:

• Reads a Signal Input Single-Point session for frames in static slots 2, 3, and 4.
• Executes a simulation model (passes in inputs and obtains outputs).
• Writes a Signal Output Single-Point session for frames in static slots 8, 9, and 10.

Assume that you test the simulation model performance and determine that it takes 100 µs (including jitter). Using the cluster configuration and the time required for the simulation model, select a macrotick offset that locates the simulation model at the midpoint between the end of slot 4 (the last input frame) and the start of NIT. This provides the maximum time possible for the XNET Read VI/XNET Write VI, DMA input/output, and CC input/output.

Figure 3 shows the Timed Loop timing diagram. Notice that the simulation model is synchronized deterministically with the FlexRay cycle. The Timed Loop code reads inputs from the current cycle, calculates outputs, and then writes the output for the next cycle.

Figure 3—Timing Source Example

Reading from the FlexRay Communication Controller (and performing the corresponding DMA) for frames 2, 3, and 4 is shown as blocks IN2, IN3, and IN4. The XNET Read VI for frames 2, 3, and 4 is shown as block R2,3,4. The simulation model execution is shown as block SIM. The start of SIM is halfway between the end of slot 4 and the start of NIT. XNET Write VI for frames 8, 9, and 10 is shown as block W8,9,10. The corresponding DMA output for these frames is shown as block D8,9,10. The FlexRay Communication Controller update during the NIT is shown as block C8,9,10.

As with any performance-sensitive configuration, you should measure using your own hardware and application to calculate the best macrotick offset value. To determine the current cycle and macrotick within the Timed Loop for measurement purposes, use the XNET Read (State FlexRay Cycle Macrotick) VI.