Comm
- Updated2023-02-17
- 6 minute(s) read
Comm
Reads the state of FlexRay communication using an XNET session.
.gvi.png?_LANG=enus)
Inputs/Outputs
session in
The session to read.
error in
Error conditions that occur before this node runs.
The node responds to this input according to standard error behavior.
Default value: No error
session out
An output that is the same as session in, provided for use with subsequent nodes.
FlexRay comm
An output that returns a LabVIEW cluster containing the communication elements.
POC state
A parameter that specifies the FlexRay interface state.
| Default Config (0) | This is the FlexRay interface initial state on power-up. The interface is essentially off, in that it is not configured and is not attempting to communicate with other nodes (ECUs). |
| Ready (1) | When the interface starts, it first enters Config state to validate the FlexRay cluster and interface properties. Assuming the properties are valid, the interface transitions to this Ready state.
In the Ready state, the FlexRay interface attempts to integrate (synchronize) with other nodes in the network cluster. This integration process can take several FlexRay cycles, up to 200 ms. If the integration succeeds, the interface transitions to Normal Active. You can use XNET Read (State Time Start) to read the time when the FlexRay interface entered Ready. If integration succeeds, you can use XNET Read (State Time Comm) to read the time when the FlexRay entered Normal Active. |
| Normal Active (2) | This is the normal operation state. The NI-XNET interface is adequately synchronized to the cluster to allow continued frame transmission without disrupting the transmissions of other nodes (ECUs). If synchronization problems occur, the interface can transition from this state to Normal Passive. |
| Normal Passive (3) | Frame reception is allowed, but frame transmission is disabled due to degraded synchronization with the cluster remainder. If synchronization improves, the interface can transition to Normal Active. If synchronization continues to degrade, the interface transitions to Halt. |
| Halt (4) | Communication halted due to synchronization problems.
When the FlexRay interface is in Halt state, all NI-XNET sessions for the interface stop, and no frame values are received or transmitted. To restart the FlexRay interface, you must restart the NI-XNET sessions. If you clear (close) all NI-XNET sessions for the interface, it transitions from Halt to Default Config state. |
| Config (15) | This state is transitional when configuration is valid. If you detect this state after starting the interface, it typically indicates a problem with the configuration. Check the fault? output for a fault. If no fault is returned, check your FlexRay cluster and interface properties. You can check the validity of these properties using the NI-XNET Database Editor, which displays invalid configuration properties. |
In the FlexRay specification, this value is referred to as the Protocol Operation Control (POC) state.
clock correction failed
A parameter that returns the number of consecutive even/odd cycle pairs that have occurred without successful clock synchronization.
In the FlexRay specification, this value is referred to as vClockCorrectionFailed.
passive to active count
A parametert that returns the number of consecutive even/odd cycle pairs that have occurred with successful clock synchronization.
In the FlexRay specification, this value is referred to as vAllowPassiveToActive.
fault?
A parameter that indicates that a fault occurred, and its code is available as fault code.
fault code
A parameter that returns a numeric code you can use to obtain a fault description.
A fault is an error that occurs asynchronously to the NI-XNET nodes your application calls. The fault cause may be related to FlexRay communication, but it also can be related to XNET hardware, such as a fault in the onboard processor. Although faults are extremely rare, XNET Read (State FlexRay Comm) provides a detection method distinct from the error out of NI-XNET nodes, yet easy to use alongside the common practice of checking the communication state.
To obtain a fault description, wire the fault code into the LabVIEW Simple Error Handler error code input and view the resulting message. You also can bundle the fault code into a LabVIEW error cluster as the code element and use front panel features to view the error description.
channel A sleep?
A parameter that indicates whether channel A currently is asleep.
channel B sleep?
A parameter that indicates whether channel B currently is asleep.
error out
Error information.
The node produces this output according to standard error behavior.
Description
You can use XNET Read (State FlexRay Comm) with any XNET session mode, as long as the session interface is FlexRay. Because the state reflects the FlexRay interface, it can apply to multiple sessions.
Your application can use XNET Read (State FlexRay Comm) to check for problems on the FlexRay network independently from the other aspects of your application. For example, you intentionally may introduce noise into the FlexRay cables to test how your ECU behaves under these conditions. When you do this, you do not want the error out of NI-XNET nodes to return errors, because this may cause your application to stop. Your application can use XNET Read (State FlexRay Comm) to read the FlexRay network state quickly as data, so that it does not introduce errors into the flow of your LabVIEW nodes.