Cyclic and Event Timing

For all embedded network protocols (for example, CAN, FlexRay, and LIN), the transmit of a specific frame is classified as one of the following:

  • Cyclic: The frame transmits at a cyclic (periodic) rate, regardless of whether the application has updated its payload data. The advantage of cyclic behavior is that the application does not need to worry about when to transmit, yet data changes arrive at other ECUs within a well-defined deadline.
  • Event: The frame transmits when a specific event occurs. This event often is simply that the application updated the payload data, but other events are possible. The advantage is that the frame transmits on the network only as needed.

The following sections describe how the cyclic and event concept apply to each protocol.

Within NI-XNET, a Cyclic frame begins transmit as soon as the session starts, regardless of whether you called the appropriate XNET Write VI (LabVIEW) or nxWrite function (C). The call to the appropriate write function is the event that drives an Event frame transmit.

CAN

For each frame, the XNET Frame CAN:Timing Type property determines whether the network transfer is cyclic or event:

  • Cyclic Data: This is typical Cyclic frame behavior.
  • Event Data: This is typical Event frame behavior.
  • Cyclic Remote: Because one ECU in the network transmits the CAN remote frame at a cyclic (periodic) rate, the resulting CAN data frame also is cyclic.
  • Event Remote: One ECU in the network transmits the CAN remote frame based on an event. Another ECU responds with the corresponding CAN data frame. In NI-XNET, the appropriate XNET Write VI or nxWritefunction generates the event to transmit the CAN remote frame.

FlexRay

For each frame, the XNET Frame FlexRay:Timing Type property determines whether the network transfer is cyclic or event:

  • Cyclic (in static segment): No null frame transmits, so this is typical Cyclic frame behavior.
  • Event (in static segment): The null frame indicates no event.
  • Cyclic (in dynamic segment): The frame transmits each FlexRay cycle. This configuration is not common for the dynamic segment, which typically is for Event frames only.
  • Event (in dynamic segment): This is typical Event frame behavior.

LIN

As described in the Using LIN topic, the currently running schedule entries determine each LIN frame's timing. In each schedule entry, the master transmits a single frame header, and the payload of one (or more) frames can follow.

For each schedule entry, the XNET LIN Schedule Entry Type property determines how the associated frames transmit. The schedule run mode also contributes to the cyclic or event behavior.

  • Cyclic: Unconditional type, Continuous run mode: This is typical Cyclic frame behavior.
  • Event: Unconditional type, Once run mode: Although the frame transmits unconditionally, the schedule runs once based on an event, so this is Event frame behavior. In NI-XNET, the XNET Write (State LIN Schedule Change) VI or nxWriteState(nxState_LINScheduleChange) function changes the mode to the run-once schedule. This effectively generates the event to transmit the LIN frame.
  • Event: Sporadic type: In this schedule entry, the master can transmit one of multiple Event-driven frames. In NI-XNET, the appropriate XNET Write VI or nxWrite function writes signal or frame values to generate the event to transmit. Because the entry itself is Event, this behavior applies regardless of the schedule's run mode.
  • Event: Event-triggered type: In this schedule entry, multiple slave ECUs can transmit in the entry, each using an Event-driven frame. In NI-XNET, the appropriate XNET Write VI or nxWrite function writes signal or frame values to generate the event to transmit. Because the entry itself is Event, this behavior applies regardless of the schedule's run mode.