Home Support NI Product Manuals NI-XNET 20.5 Manual

Table Of Contents

XNET Write (State » LIN » Schedule Change) (G Dataflow)

Download Manual | Offline Viewer Required
Version:
Last Modified: September 16, 2019

Writes a request for the LIN interface to change the running schedule. You can use this XNET Write node with any input or output session for LIN.

connector_pane_image
datatype_icon

session in

The session to use for the schedule change. This session is selected from the LabVIEW project or returned from XNET Create Session. The session must use a LIN interface.

datatype_icon

data

The XNET LIN schedule. Although the data type for this input is the XNET LIN Schedule I/O Name, you also can wire a string.

The data input supports the following options:
  • XNET LIN Schedule I/O Name: You can use the complete I/O name. This provides features such as the ability to choose from LIN schedules in a selected database.
  • String with XNET LIN short name: If you prefer to use the XNET LIN Schedule Name (Short) property, you can wire in the property as a string.
  • String with decimal number: This is interpreted as an index into the XNET Cluster LIN:Schedules property used for this session. If you are editing your database file to add/remove LIN schedules, this index may change, in which case the name is the recommended option.
datatype_icon

error in

Error conditions that occur before this node runs.

The node responds to this input according to standard error behavior.

Standard Error Behavior

Many nodes provide an error in input and an error out output so that the node can respond to and communicate errors that occur while code is running. The value of error in specifies whether an error occurred before the node runs. Most nodes respond to values of error in in a standard, predictable way.

error in does not contain an error error in contains an error
If no error occurred before the node runs, the node begins execution normally.

If no error occurs while the node runs, it returns no error. If an error does occur while the node runs, it returns that error information as error out.

If an error occurred before the node runs, the node does not execute. Instead, it returns the error in value as error out.

Default: No error

datatype_icon

session out

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

datatype_icon

error out

Error information.

The node produces this output according to standard error behavior.

Standard Error Behavior

Many nodes provide an error in input and an error out output so that the node can respond to and communicate errors that occur while code is running. The value of error in specifies whether an error occurred before the node runs. Most nodes respond to values of error in in a standard, predictable way.

error in does not contain an error error in contains an error
If no error occurred before the node runs, the node begins execution normally.

If no error occurs while the node runs, it returns no error. If an error does occur while the node runs, it returns that error information as error out.

If an error occurred before the node runs, the node does not execute. Instead, it returns the error in value as error out.

Description

You can use XNET Write (State LIN Schedule Change) with any XNET session mode, as long as the session interface is LIN. Because the schedule change applies to the LIN interface, it can apply to multiple sessions.

According to the LIN protocol, only the master executes schedules, not slaves. If the XNET Session Interface:LIN:Master? property is false (slave), this write function implicitly sets that property to true (master). If the interface currently is running as a slave, this write returns an error, because it cannot change to master while running.

XNET Write (State LIN Schedule Change) behavior depends on the Run Mode property of the XNET LIN schedule that you wire in as data:

  • Continuous: This mode changes the single run-continuous schedule for the interface. The single run-continuous schedule executes all its entries (slots) repetitively, starting over with the first entry after running the last entry.

    The run-continuous schedule is handled as if it is lowest priority. If you write a run-once schedule in the middle of a run-continuous execution, the run-continuous schedule is interrupted after the current slot finishes. The scheduler switches to the run-once schedule, and when all run-once schedules are done, the scheduler returns to the slot in the run-continuous schedule where it left off. For example, if run-continuous schedule A has 4 slots, and it is executing slot 2 when a run-once schedule B is written, slot 2 of A finishes, then all slots of schedule B run, then the scheduler returns to slot 3 of schedule A.

    Only one run-continuous schedule exists at a time. If you change from one run-continuous schedule to another in the middle of a run, the current schedule completes all of its slots, then the scheduler changes to the new run-continuous schedule.

  • Once: This mode writes a request for a run-once schedule. Multiple run-once schedules can be pending for execution. Each run-once schedule executes all its entries (slots), and then it is considered done.

    Each run-once schedule has a priority from 1 to 254. Lower values correspond to higher priority (1 is highest). The LIN interface's scheduler maintains a priority queue of run-once schedule requests. This means the highest-priority run-once schedule executes first, followed by the next run-once in priority, and when no run-once schedules are pending, the interface returns to the run-continuous schedule.

    A run-once schedule cannot interrupt another run-once schedule. For example, if run-once schedule X has 3 slots and is executing slot 0 when a run-once schedule Y with higher priority is written, slots 0, 1, and 2 of X finish, then all slots of schedule Y run.

  • Null: This mode stops scheduler execution after the current slot is finished. The queue of run-once schedules is flushed (all elements discarded).

    The null schedule is considered the highest priority schedule. It overrides the single run-continuous schedule, thus acting as the default scheduling behavior. For example, if you write a null schedule, then write a run-once schedule, the run-once schedule executes all its slots, then communication stops (returns to null schedule).

    XNET Write (State LIN Schedule Change) does not wait for the requested schedule to finish execution prior to return. The node does not wait for the schedule to begin execution, because in the case of run-once schedules, that may take a long time (depending on priority). Because this node simply writes a schedule request and returns, it is safe to use within a high-priority loop in LabVIEW Real-Time.

Node configuration is handled using XNET Write (State LIN Schedule Change) instead of XNET Write (State LIN Diagnostic Schedule Change). Wire the node configuration schedule defined for the LIN cluster into XNET Write (State LIN Schedule Change) so that it is the first schedule executed for the LIN, with a run mode of once. The data for each node configuration service request entry in the node configuration schedule is automatically transmitted by the master. After the node configuration schedule has completed, use XNET Write (State LIN Diagnostic Schedule Change) to write master request messages and query for slave response messages, or XNET Write (State LIN Schedule Change) to run normal schedules.

Where This Node Can Run:

Desktop OS: Windows

FPGA: Supported

Web Server: Not supported in VIs that run in a web application

Recently Viewed Topics