I am trying to implement a LIN schedule that allows me to send and receive diagnostic messages at-will on top of a running LIN bus schedule. It goes as such:
0x00 (master) - cyclical
0x01 (slave1) - cyclical
0x02 (slave2) - cyclical
0x3C (master diag command) - when I feel like it
0x3D (slave response) - after it sends diag command
The object is to not interrupt the regularly scheduled cyclical messages, but to insert the diagnostic commands when my top-level VI requests it.
Anyone seen anything like this before?
NOTE: Changing the schedule to ONLY 0x3C and 0x3D will kill the bus - my slaves are very sensitive and will take control of the bus if theyre left with silence.
NOTE2: Using XNET API in LV2012
LIN Diagnostics can be interleaved inbetween instances of Run-Continuous schedules as shown:
Therun continuous mode will immidiately repeat the current schedule so there is not usually time inbetween schedules for diagnostics. This may or may not be acceptable depending on the tolerance of your ECUs.
If you are using a run-once schedule with large gaps of time between runs then you can implement a method to squeeze diagnostics inbetween them.
the slaves will not allow for this latency between cyclical messages if there is no diagnostic message present. they will think the bus is down.
Can you clarify what the slave requirements are as it is unclear if a diagnostic message or the normal schedule is required to keep the ECUs operational.
What are the time parameters we are working with i.e the cyclic rate of this watchdog message? What does your continuous schedule look like? Can you provide a copy of the database or an approximation?
What happens when the slaves don't receive these messages? When you say "they will think the bus is down" do they go into a sleep state or something else? Is the payload in the frame what is important to keep the ECU alive or are we talking about the physical LIN bus going to sleep?
so the schedule is 0x00, 0x01, 0x02 every 50ms.
intermittently, if the slave detects a 0x3C diagnostic request, it will immediately respond 0x3D, then resume normal schedule.
If the 0-1-2 schedule is not resumed for 2 seconds, one of the slaves will take the bus back over as the master.
I didn't have much time to polish these examples but they demonstrate how to interleave some diagnostics inbetween a run-continuous schedule. It uses the shipping example LDF database and sends out two frames from the master on the fast schedule. The master VI sends out dummy data with each write and monitors the slaves diagnostic responses.
The slave simply reads all data and looks for a master request. Once it detects a master request it will write a slave response. We can use the XNET bus monitor to verify that the 5 frames of the master request or slave response are interleaved between the normally running schedule. You might take a look and see if this could work for you.