Table Of Contents

XNET Read (State » FlexRay » Comm) (G Dataflow)

Version:
    Last Modified: February 22, 2017

    Reads the state of FlexRay communication using an XNET session.

    connector_pane_image
    datatype_icon

    session in

    The session to read. This session is selected from the LabVIEW project or returned from XNET Create Session.

    datatype_icon

    error in

    Error conditions that occur before this node runs. The node responds to this input according to standard error behavior.

    Default: No error

    datatype_icon

    session out

    An output that is the same as session in, provided for use with subsequent nodes.

    datatype_icon

    FlexRay comm

    An output that returns a LabVIEW cluster containing the communication elements.

    datatype_icon

    POC state

    A parameter that specifies the FlexRay interface state.The decimal value is in parentheses:

    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.

    datatype_icon

    clock correction failed

    A parameter that returns the number of consecutive even/odd cycle pairs that have occurred without successful clock synchronization. If this count reaches the value in the XNET Cluster FlexRay:Max Without Clock Correction Passive property, the FlexRay interface POC state transitions from Normal Active to Normal Passive state. If this count reaches the value in the XNET cluster FlexRay:Max Without Clock Correction Fatal property, the FlexRay interface POC state transitions from Normal Passive to Halt state.

    In the FlexRay specification, this value is referred to as vClockCorrectionFailed.

    datatype_icon

    passive to active count

    A parametert that returns the number of consecutive even/odd cycle pairs that have occurred with successful clock synchronization. This count increments while the FlexRay interface is in POC state Error Passive. If the count reaches the value in the XNET Session Interface:FlexRay:Allow Passive to Active property, the interface POC state transitions to Normal Active.

    In the FlexRay specification, this value is referred to as vAllowPassiveToActive.

    datatype_icon

    fault?

    A parameter that indicates that a fault occurred, and its code is available as fault code.

    datatype_icon

    fault code

    A parameter that returns a numeric code you can use to obtain a fault description.If fault? is false, the fault code is 0.

    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.

    datatype_icon

    channel A sleep?

    A parameter that indicates whether channel A currently is asleep.

    datatype_icon

    channel B sleep?

    A parameter that indicates whether channel B currently is asleep.

    datatype_icon

    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.

    Where This Node Can Run:

    Desktop OS: Windows

    FPGA: Supported


    Recently Viewed Topics