Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Swapping LIN Schedules on the Fly with Diagnostics

Solved!
Go to solution

Hi Everyone,

 

I am working on a project where I want to be able to start and stop LIN Schedules on the fly, but writing a Schedule with the Run Mode = Null does not seem to stop the communication every time.

Also, writing the schedule with Run Mode = Continuous does not always start it back up.

 

The same thing seems to be happening with my Diagnostics. Using the XNET LIN Diag Change does not seem to stop the Slave Response Schedule from spamming 0x3D headers on the bus even after the diagnostic has been received.

I'm not seeing any errors present.

 

Has anyone else had issues controlling LIN Frame Streams?

 

Attached is a project with my formatting vi's and a database I've been using to test.

Could someone else try to run this and see if they can get the Start/Stop LIN buttons to not work? Bonus points for trying the diagnostics.

Apologies for the vi's not being organized all that well, this is more of a proof of concept before final project development.

 

Using:

Windows 7

LabVIEW 2014 SP1

XNET 15.0

 

Thanks!

0 Kudos
Message 1 of 5
(4,721 Views)

Hello!

 

Could you provide steps on how to run your code? I tried running it and keep running into an error. Also what is your hardware setup?

 

Danielle

National Instruments

0 Kudos
Message 2 of 5
(4,660 Views)

Sure, no problem.

 

If you open the project, there should be 1 vi not in a subfolder called LIN Control Main.vi.

On the front panel of that vi, you need to select a LIN Cluster, a LIN Interface, and a LIN Schedule before running the vi.

If using the included fibex database, the cluster is DUT_LIN, and the schedule can be ALL_FRAMES or AB_FRAMES, it doesn't matter.

With those filled in and power applied to whatever LIN Hardware you have you should be able to run the vi and see no errors.

 

In my hardware setup I talk to a part, but you will probably have to just connect to another LIN Port and run a bus monitor as a slave. Or turn Echo Tx to True in my source code (the property node immediately following the Frame Out Stream Open call).

 

Once the program is running, try pressing Start LIN and Stop LIN and seeing if the LIN communication actually starts/stops. What I see is that it works on every other run of the vi.

 

I'm using a 4-slot cDAQ-9174 with my NI-9860 and LIN Transceiver Cable in slot 3. I have a 9215 in slot 1 and a 9401 in slot 2, but they are not in use.

0 Kudos
Message 3 of 5
(4,656 Views)
Solution
Accepted by RobAfton

I am working on a project where I want to be able to start and stop LIN Schedules on the fly, but writing a Schedule with the Run Mode = Null does not seem to stop the communication every time.

 

It looks like you are trying to set a run mode of Null for a normal and diagnostic schedules after the sessions are created (during active communication) which is not allowed. The way to clear the normal scheduler is to create a schedule with a run mode of Null before creating any sessions, then write that null schedule during active communication. The way to clear the diagnostic scheduler is to write the Null constant value to it during active communication

 

Also, writing the schedule with Run Mode = Continuous does not always start it back up.

 What starts the normal scheduler is writing a schedule that has been preconfigured (before session create) for run-continuous or run-once mode. What stops the normal scheduler is writing a schedule that has been preconfigured (before session create) for null mode. What starts the diagnostic scheduler is setting master request or a slave response. What stops the diagnostic scheduler is setting Null. We can’t set the run mode to Null after session create and rewrite the schedule to have it clear the scheduler. Likewise, we can’t set the run mode to continuous after session create then write the scheduler to have it start executing.

 

The same thing seems to be happening with my Diagnostics. Using the XNET LIN Diag Change does not seem to stop the Slave Response Schedule from spamming 0x3D headers on the bus even after the diagnostic has been received.

The expected behavior when Slave Response is written to LIN Diag Change, if for the scheduler to continue looping tx of the Slave Response header until the user stops it by writing Null to LIN Diag Change. The reason is that per the LIN spec., the slave does not have to respond to each response header. This is discussed in the help topic for LIN Diag Change. The master is allowed to poll the slave with multiple response headers until it gets the full response. The user is responsible for determining when the expected number of response frames have been received, then writing Null to LIN Diag Change at that point to stop the scheduler. If we do not want tx of slave response headers after receiving the slave response, we can add code to verify receipt of the expected number of slave response frames after writing a diagnostic schedule change of Slave Response. At that point, we then write a Null diagnostic schedule change.

 

I'm not seeing any errors present.

 This may have been an oversight or a result of debugging but some of the cases did not have error wires connected properly which could have been masking some error information.

 

The application uses stream output to write the master request frames, but also setting master request and slave response diagnostic schedule. Those are mutually exclusive approaches: we either needs to create a stream output session and write master request frames (full frames) directly to it, and never use the diagnostic scheduler, or create a frame output queued session for the master request frame and use the diagnostic scheduler. See Help for XNET Write (State LIN Diagnostic Schedule Change).vi. 

 

We have attached a modified example that should exemplify the desired behavior. We left the diagnostic schedule writes in there and changed the session to frame output queued, since that is the recommended way to handle diagnostic scheduling. It ensures that normal and diagnostic schedule interleaving which is something you might need at some point in the future, in addition to enforcing diagnostic timing.

 

Jeff L
National Instruments
Message 4 of 5
(4,648 Views)

Excellent response JefeL, your explanation greatly helped me understand how the LIN drivers are intended to work.

Thanks!

0 Kudos
Message 5 of 5
(4,638 Views)