How do I send a LIN diagnostic request with the second byte equal to or greater than 0x30 using XNET 1.7?

[Olivier77]

Hello,

I use canalyzer to check what is send via XNet. (I also check with a oscilloscope directly on the LIN line)
I can t use XNet bus monitor since the XNet is allready used to send the frame via the NI9866, which have only one LIN line.

I just found something interresting :

   - If I create a schedule table with only the MasterReq, I can send the second byte to whatever I want

     I used NIXNET_exampleLDF.ldf and added this in the schedule tables

       OnlyMasterReqSch {

         MasterReq delay 200 ms;

       }

   - If I add another frame in the schedule table (even the SlaveResp), then frames with second byte over 0x2F are not sent.

     I used NIXNET_exampleLDF.ldf and added this in the schedule tables

       OnlyMasterReqSch {

         MasterReq delay 200 ms;

         SlaveResp delay 200 ms;

       }

Here is what I set in labview :

[Gucky]

You should define an own schedule table for the SlaveResp frame and the MasteReq frame. (Take a look at the LIN spec, for LIN 2.1)

For example:

Schedule_tables {

  MasterRequest {
      MasterReq delay 10 ms;
  }
  SlaveResponse {
      SlaveResp delay 10 ms;

}

By the way: You can use the XNET Bus Monitor also on Port LIN1.

In the Bus Monitor "Interface and Database Settings" enable "Log Transmitted Frames" and select Subordinate for the "Run Mode". You should see now the bus traffic on LIN1.

Hope this helps. 

[Olivier77]

Ok.

I looked at the LIN standart, and indeed the example shoes schedule tables with only MasterReq or SlaveResp, but I did nt found in the standart that it is a rule.

As it is, I was used to work with french automotive customers who have schedule tables mixing MasterReq with SlaveResp and other unconditional frames.

And that does not explain why it works till 0x30 is reached.

But that helps, and I ll be able to work around this problem with a little work.

Tx

Olivier

[kevin.key]

I work with Jaime, and have verified the same problem on another system. Basically, our code to send diagnostic frames works fine as long as the PCI byte is valid. We have a VI that's purpose is just to transmit a diagnostic frame. The code doesn't examine the payload at all, it just takes the frame that is passed in and transmits it. The VI will transmit the frame successfully if the PCI byte is a valid value, otherwise it won't send the frame. If an NI person could confirm that there is a restriction for sending the frame based on the PCI byte, that would be most helpful. And if so, we'd like to be able to send invalid PCI bytes for testing purposes.

[Olivier77]

As described above, a way to work around this problem is to create a schedule table with only the MasterReq, and then for me, it works fine and I can send PCI over 0x30.

For long term solution, you'll have to wait for NI guys response.

[kevin.key]

I thought we had a schedule with the MasterReq in a schedule table of its own originally. I tested this again, and now I'm not seeing the behavior I thought I saw before. Right now, I'm not sure if I know how to reproduce the original problem.