Creates a timing source for a LabVIEW Timed Loop. The timing source is based on the FlexRay communication cycle. The timing source sends a tick to the Timed Loop at a specific offset in time within the FlexRay cycle. The offset within the cycle is specified in FlexRay macroticks.
The timing source name, returned as timing source out if this node succeeds.This input is optional. If you leave timing source name unwired (empty), timing source out uses the session name (session in).
The session to use for creating the timing source. You must configure the session to use a FlexRay interface, because the timing source is based on that interface’s communication cycle. You can create only one FlexRay cycle timing source for each interface.
This session is selected from the LabVIEW project or returned from XNET Create Session.
The offset within each FlexRay cycle that you want the timing source to tick. The minimum value is zero (0), which specifies a tick at the start of every FlexRay cycle. The value cannot be equal to or greater than the number of macroticks in the cycle, which you can read from the XNET Cluster the session uses, from the FlexRay:Macro Per Cycle property.
For further recommendations about selecting a value, refer to Macrotick Offset on the Details tab.
Error conditions that occur before this node runs. The node responds to this input according to standard error behavior.
Default: No error
An output that is the same as session in, provided for use with subsequent nodes.
The timing source name. You wire this name to the Source Name of the input node outside the Timed Loop. For more information about the Timed Loop nodes, refer to Using the Timed Loop on the Details tab.
If this node returns an error (status true in error out), timing source out is empty, which indicates to the Timed Loop that no valid timing source exists.
Error information. The node produces this output according to standard error behavior.
Use this node 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 node 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 node.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.
Source Name: Wire the timing source name output of this node 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) node 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 node 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 node 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 XNET Start (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 nodes 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 XNET Start 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 nodes 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.
The following figure 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 XNET Read to read the value received from slot 1.
For better visibility in these figures, 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.
The preceding figure shows that the DMA input transfer for slot 1 (IN1) occurs at the same time as XNET Read for slot 1 (R1). Depending on which one completes first, XNET Read 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 the preceding figure, setting macrotick offset to the end of slot 2 would suffice.
When your LabVIEW RT application calls XNET Write, 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.
The following figure shows the effects of this implementation. This example expands on the preceding figure by calling XNET Write with a value for slot 8. XNET Write (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 XNET Write. 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 XNET Write 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 XNET Write before the relevant slot. You merely need to provide time for XNET Write and the related DMA output to complete prior to the NIT.
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, XNET Read, LabVIEW code within the Timed Loop (for example, a simulation model), XNET Write, 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:
Within the Timed Loop, the example does the following:
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 XNET Read/XNET Write, DMA input/output, and CC input/output.
= (4 x Static_Slot)
= (4 x 58)
= EndOfSlot4 + ((NIT_Start - EndOfSlot4) / 2)
= 232 + ((900 - 232) / 2)
= 232 + 334
|macrotick offset||= (Midpoint - (SimModelTime / 2)) = (566 - (100 / 2)) = 516|
The following figure 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.
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. XNET Read 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 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 XNET Read (State FlexRay Cycle Macrotick).
Where This Node Can Run:
Desktop OS: Windows