When it comes to CAN every device on the bus will send data when it wants to. If I have an ECU that sends the vehicle speed it might 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 quite often just waiting for a device to send data. The amount of idle time can be 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 deterministic. That frame may not go out exactly every 100ms, and as the bus load increases the likelihood that the frame will take longer goes up.
10ms Delay - 0x100
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 itself. 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, but there is no master, there will be no traffic at all.
LDFs files usually will have one schedule setup reading the basic data but more quickly, and 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, then save it to the database, and use that database and schedule by name within the application. Alternatively a schedule can be made at runtime with XNet. Open the Help >> Find Examples and search LIN Schedule and you'll find things like LIN Dynamic Database Creation. This example allows you to select the individual IDs, and timing of a schedule. Just like with CAN, the XNet database editor allows you to export the database to a file for other tools.
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 interpreting the information that is read. 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 programmatically with the database API.
Schedule
LIN is quite different from CAN. Instead of every device on the bus just sending data asynchronously, there is a single master on the bus, with one or more of slave devices. This master defines the schedule that is used which can be changed at any time. 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 ID 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 itself. 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, but there is no master, there will be no traffic at all.
Determinism
In the example given, we can know for a fact that 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, and no priority levels to worry about, and assuming all ECUs are powered this will mean no data lost. As a result this will mean the data coming in will be deterministic. If we want data to come in faster, we can either reduce the delay between frames, or reduce the number of frames to read. Depending on the baud rate of the bus, and the schedule selected, ECUs may have a hard time responding fast enough.LDF File
The LDF file for LIN is comparable to the DBC file in CAN which was covered in Part 5 of the CAN blog series. The LDF will have Frames just like CAN, and will have Signals within a frame that define the bits used, as well as scaling to engineering units. LIN is also limited to an 8 byte payload just like all non-FD CAN frames.LDFs files usually will have one schedule setup reading the basic data but more quickly, and 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, then save it to the database, and use that database and schedule by name within the application. Alternatively a schedule can be made at runtime with XNet. Open the Help >> Find Examples and search LIN Schedule and you'll find things like LIN Dynamic Database Creation. This example allows you to select the individual IDs, and timing of a schedule. Just like with CAN, the XNet database editor allows you to export the database to a file for other tools.
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 interpreting the information that is read. 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 programmatically with the database API.
XNet Session Types
The same XNet API can be used on both CAN and LIN communication. As a result many of the same programming practices used on CAN are used on LIN. In Part 6 of the CAN blog the 12 main session types are described and these session types also apply to LIN. And just like CAN, multiple sessions can be opened at the same time, to make an application that is very flexible.ID Responsibility
In addition to having only one master on the bus, another requirement is that there are no two devices on the bus, that are responsible for the same ID. In CAN any device can send any ID at any time. But with LIN being synchronous, each ID needs to come from a single device. CAN buses generally don't reuse IDs between different devices, but if they did it would still function. If two devices on a LIN bus try to send a response to the same ID there would be data loss.Wiring
In Part 1 of this blog series we talked about the wiring for CAN. It typically is a twisted pair of wires that are the CAN High and CAN Low signals shared between all devices, with a resistor on each end of the bus. With LIN there is only one data wire between the devices. However each device needs to be powered, and each device needs to share a common ground. For NI and XNet devices the pinout is below. Other manufacturers can have different pinouts so check with the appropriate documentation. No resistors are needed.