LIN Diagnostic with NI-XNET issues

[Steiger]

I have a test setup with PXI-8516 devices communicating with LIN DUTs. Ordinary communication works fine, as I can read and write to the DUT. However, I also need to send diagnostic commands and receive responses on the LIN Diagnostic frames (hex 3C and 3D), and am not having any success with this when I attempt to do it the same way as I do the regular read and write (for which I simply use modified versions of the Frame Input and Frame Output Single-Point example VIs). Whatever I've attempted, the 3D slave response frame is always empty.

I have to modify our customer's ldf files in order for NI-XNET to recognize them (which is a question in itself) Based on some info in other posts, I added the diagnostic frames as "ordinary" frames, and created a separate schedule for the diagnostic frames, since XNET did not recognize either the diagnostic frames or schedules in the original ldf file. So although it's working for regular communication, at this point I'm not sure whether the issue is with something in the ldf file, or the code.

I've attached code showing one of numerous attempts. The required procedure is to set the slave device into a diagnostic mode, then make a request for diagnostic data from the slave.

Any suggestions on how to proceed?

[kevin.key]

I've had a similar experience, and I ended up using the XNET DB API to programmatically add two schedules, one for 0x3C and 0x3D. The schedules each contain one unconditional entry for the diagnostic frame, and are configured with a RunMode of once. The database is edited at initialization before creating any sessions.

After initializing the db, I create a frame output session for 0x3C, a frame input session for 0x3D, and a frame input stream session. When sending 0x3C diagnostic frames I ensure that any previous frame was already sent, then update the session's frame, and change the schedule to the 0x3C schedule. When receiving 0x3D diagnostic frames I simply change the schedule to the 0x3D schedule. The RunMode Once schedules are queued so you can queue up as many 0x3D's as might be need to fully receive a multi-frame response. The transmit frames can't be queued up to make sure that the response to the 0x3C header doesn't accidentally get the value of the next frame in a multi-frame request. I use the input stream session for making sure 0x3C frames were transmitted successfully, and for getting the payload for the 0x3D frames.

I've found this technique to be reliable. It prevents unintended additional 0x3C or 0x3D headers from being sent, which might happen if you just use the Continuous RunMode. It also allows you to avoid editing the ldf because the schedules for the diagnostic frames are added programmatically.

[kevin.key]

I'm used to being the requestor so as long as that's you're perspective then what I posted makes sense. Otherwise, flip-flop how you're controlling 0x3C and 0x3D.

[Hooovahh]

I know this is a few years old, but I'm hoping to see some example code of what you describe.  I tried setting it up the way you described but even after setting the schedule to run once it kept running continuously.

Also is there a way to have the slave respond, without making a schedule?  By that I mean lets say I just use the Write and send a frame out, then I wait and I want my slave to respond.  Can I perform the write, and have the slave populate the data, without using a schedule?

[kevin.key]

A slave cannot decide when to transmit, because the master transmits the header for every frame. So it is important to set the schedule to the diagnostic response, because this causes the header to be sent.

Since l posted this the xnet api added diagnostic schedules and a few other things for diagnostics to the api. I still use the same basic method though with minor differences.

[Hooovahh]

Thanks for the reply.  I'm aware that a slave will not send anything unless the master populates the header, what I was asking was is there a way to populate the header, without using a schedule?  It sounds like there isn't which I can live with.

I'm very disappointed that there exists no example on NI's site, or example finder that demonstrate how to do diagnostic LIN with XNet.  That being said I think I have a working solution because I couldn't get your solution to work right.

Lets say I have a normal table with a single frame in it, then I change to the Master Request, then perform a single write frame, then change to the slave response, then put a read in a while loop until I see the response I expect or timeout.  I am seeing issues where I change to Master Request, then write my single frame, then change to Slave Response.  If I do this operation one after another then my Request never goes out, because the schedule is changed to a slave before it goes out.  Is there a way to know when a frame is completed on the bus?

The work around I have right now that I think is fine, is I will have the schedule with my normal table in it, and I will add my Slave Response frame to the end.  Then when I want to perform a diagnostic function I will send out one Master Request using the write on a Frame Out Stream.  I don't know when that message goes out, but I do know when the response comes in because I will have it on the read.  This way I don't ever need to change the schedule.  I am constantly getting the slave response but it will just be the same response over and over, until I send a new Master Request frame.  All of this is acceptable but what I was really hoping for was a diagnostic function, where I specify the payload to write, on the ID I want, and it will sit and wait until that response is seen on the ID I expect, and return the data.

[kevin.key]

That's why I use the frame input stream session. I read the frame input stream session until the message I transmitted is read back. Then I know it's safe to change the schedule. That assumes you've enabled the echo transmit property for the interface.

[Hooovahh]

---

@kevin.key wrote:

That assumes you've enabled the echo transmit property for the interface.

---

That's the key I haven't seen you mention yet, now I understand.  But I still think overall my technique would work better in my situation.  Not needing to constantly change schedules is a plus for me, just send the Request, and wait for the next response...well now that I think about it this technique will only be valid if you know something about the expected response and in my situation I do.  Thanks again.

[JeroenCroes]

Hello Hooovahh and kenny,

could you guys, by any chance, upload that VI which sends diagnostic frames?

Thanks a lot!

BR

[RyanPoPo]

JeroenCroes,

Here's a LIN Diagnostics example that you might find useful.

Regards,

Ryan