XNET Write (State LIN Schedule Change).vi

XNET Write (State LIN Schedule Change).vi

Purpose

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

Format

Inputs

	session in is the session to use for the schedule change. This session is selected from the LabVIEW project or returned from the XNET Create Session VI. The session must use a LIN interface.
	data is 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.
	error in is the error cluster input (refer to Error Handling).

Outputs

	session out is the same as session in, provided for use with subsequent VIs.
	error out is the error cluster output (refer to Error Handling).

Description

You can use the XNET Write (State LIN Schedule Change) VI 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.

The XNET Write (State LIN Schedule Change) VI 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).
  
  The XNET Write (State LIN Schedule Change) VI does not wait for the requested schedule to finish execution prior to return. The VI 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 VI 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 the XNET Write (State LIN Schedule Change) VI instead of the XNET Write (State LIN Diagnostic Schedule Change) VI. Wire the node configuration schedule defined for the LIN cluster into the XNET Write (State LIN Schedule Change) VI 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 the XNET Write (State LIN Diagnostic Schedule Change) VI to write master request messages and query for slave response messages, or the XNET Write (State LIN Schedule Change) VI to run normal schedules.