Automotive and Embedded Networks
NI USB-8476 LIN Schedule
I have done LIN XNet stuff but it was a few years ago and I don't have any LIN hardware to demonstrate on at the moment. But here is an overview that I hope will help.
When it comes to CAN every device on the bus will send data when it wants to, when it wants to. If I have an ECU that sends the vehicle speed it may be designed to send it on ID 0x100 every 100ms. If the bus is busy, a message may be lost, or if a higher priority message is being sent that device's message won't go out, and it will wait until the bus isn't active and try to send it again. A typical CAN bus is going to be idle more often then transmitting. This is refereed to as the bus load as a percentage of the baud rate. Lower is better since high bus load will often mean messages are lost and will need to be sent again. As the bus load increases, it is more likely that an ECU's message will need to be retransmitted. Because of this CAN isn't really deterministic. That frame may not go out exactly every 100ms.
LIN is quite different. Instead of every device on the bus just sending data, there is a single master on the bus. This master defines the schedule. The schedule is the order of what IDs are going to be on the bus. Lets say I have ECU1 which sends vehicle speed on 0x100, and there is a second ECU2 that send vehicle temperate on 0x200. My master ECU can make a schedule of:
10ms Delay - 0x100
10ms Delay - 0x200
This means that the master will send out the ID 0x100, then wait for the slave that is responsible for that data to send it. The device responsible for this might even be the master. Then 10ms later the master will send the header 0x200 and wait for the slave responsible for that ID to send the data. Then this schedule repeats. No data will be on the bus unless the master is asking for it. If a LIN slave device is powered it likely will have no traffic at all.
Now when we read the data we know every 20ms there will be a reading for vehicle speed, and every 20ms there will be a reading for vehicle temperature. There is no collision, no priority levels to worry about, and assuming all ECUs are powered this will mean no data lost. And as a bonus this should be deterministic. If we want data faster than that we can reduce the delay to 0ms at which point he bus load will be 100%. I've seen times when this is fine and all ECUs can keep up.
So how can you make your own schedule? Well yes if you have an LDF it will likely have one or more schedules in it. LDFs usually will have one schedule setup reading the basic data but really fast, or a slower schedule with more data to read. In both cases the bus load will likely be near 100%, but this is fine for LIN (but not for CAN). You can make your own schedule with the XNet Database Editor or by using the API. Open the Help >> Find Examples and search LIN Schedule and you'll find things like LIN Dynamic Database Creation.
However an easier method but one that is more rigid, is to open the NI-XNET Database Editor. This is installed with XNet in your start menu. From here go to File >> New, then right click the network and make a new LIN interface. Then right click and create all the frames you want. At this point they can be raw frames, signals can be added later. Then make the schedule, and define the frames to read and in what order. Then save. Now when you want to read or write or do whatever in LIN, you can reference this database by name. This can also be exported to an LDF if you have other tools that can read it.
What you read will just be raw frames unless you defined the signals. So without the LDF you are going to have a hard time. If you do have the LDF in the Database Editor you can go to File >> Open and pick the LDF and it will import the names and everything. This can also be done programatically with the database API.
I've never used NI-LIN (the non-XNet), but I assume it isn't well maintained since everything NI-LIN can do NI-XNet can do better, it just may have a steeper learning curve. NI-LIN examples should also be in the Help >> Find Examples.
Pretty much. The schedule is responsible for putting the IDs on the bus and the other devices are responsible for putting the data on the bus, after the ID it is responsible is seen.
If you open Help >> Find Example there is a LIN Frame Input Queued example (search). Here we create an input sessions, then we choose to be the master, and start a schedule. Then we read all LIN frames we see on the bus which should have the data populated by all other devices.
Now there are times when we went to send data to a device. In these cases we still are the master, but our schedule will have an ID that the master is responsible for sending. There is an example of LIN Frame Output Single Point, where it looks very similar but here we write the data we want to send. The data won't actually go out unless the schedule has that ID in it. You can combine these two VIs so that you have a schedule with IDs you want to read, and IDs you want to write. You can then create two sessions, one for reading all frames, and one for writing the frames you want.
Really thanks for your response!
So in Fast schedule in LDF database, the MasterFrame is for sending data to device with ID 0x02, and the SlaveFrame is for reading data from 0x05.
If I want to read data from the slave with ID 0x23, I just need to change the frame ID and create a schedule just like MasterRequest_Schedule in example datebase using LIN Frame Input Single Point.vi with related configration?
The first half regarding the fast schedule: Yes
The second half: I'm unsure.
I know that I was able to flash a LIN device which requires sending and receiving a variety of data, which doesn't rely on a schedule. And with the Master Request and Slave Response I suspect that is what you have there. You want to send a frame on the Master Request, and get a Slave Response, which then may lead to more Master Request messages. This is similar to the ISO-15765 or UDS, or NI-ADCS. I've done this in the past over LIN but am unsure how it was done and don't have access to hardware. I can't remember how this was done, if I was constantly switching schedules, or if there was a way to just write a frame without it.
