NI LIN 8506 acts as a slave

[seica1]

I have a customer device that has a LIN port to communicate, it acts as a Master Node.

Master send to my application, a PC with NI LIN 8506 device, the diagnostic request 0x3C and the response 0x3D to my application (I see both on BUS monitor) I have to put on the BUS the response 0x3D with the Payload bytes but I'm not able to do that, I used any VIs taken by the examples library with no success, I see the the 0x3D with payload on the BUS monitor but the master di not receive anything, there are also some bus error.

I started to use LIN Diagnostic Frame Slave.vi and all the variant similar to that.

I used the the 'NIXNET_ExampleLDF.ldf' database like it is.

Labview Version 23 and the last XNET library.

Is there any other thing to do or configuration to set my LIN port as a slave that respond to master request?

Regards.

Massimo Ponte

[FeSe]

Hello,

To make sure I understand correctly:

You are using an NI USB-8506 LIN interface with LabVIEW 2023 and the latest NI-XNET driver. Your device is configured as a LIN Slave, and you are trying to respond to a diagnostic request (ID 0x3C) with a response (ID 0x3D). You’ve tested all example VIs, including LIN Diagnostic Frame Slave.vi, and you can see the 0x3D frame with payload on the Bus Monitor. However, the Master does not receive the response, and bus errors are present. This suggests a possible issue with timing, frame queuing, or checksum configuration.

Below are some useful references and suggestions based on similar cases:

1. The Master only sends the header of frame 0x3D

In the LIN protocol, the Master transmits only the header of the diagnostic response frame (0x3D). The Slave must inject the payload in real time. If your VI isn’t properly synchronized, the payload may not be inserted in time, resulting in an empty frame. The suggestion is to use a Frame Output Queued session and make sure the 0x3D frame is already queued before the Master sends the header.

NI Forum – Slave Response ISSUE

NI-XNET User Manual – LIN

2. Response timing is too slow: the payload must be ready before the Master sends the header of frame 0x3D. If your VI queues the response too late, the frame will be transmitted without data. The suggestion is to prepare and queue the 0x3D frame immediately after receiving the 0x3C request, and keep it ready.

A similar issue was discussed in the NI forum, where the Slave sent multi-frame responses that were visible on the Bus Monitor but not received by the Master.

So ensure that all frames are correctly queued and scheduled, and that the .ldf file supports multi-frame diagnostic responses.  NI Forum – Multi-frame LIN Diagnostic Responses

Addition, this NI forum thread confirms that in LIN communication, the Master sends only the header of the diagnostic response frame, and the Slave must inject the payload in real time. It also discusses the correct use of NI-XNET sessions and timing requirements.

NI Forum – LIN Master/Slave Diagnostic Frame

Please let me know if this matches your intended approach or let me know if this helps resolve the issue.

Best regards

[seica1]

I managed to implement the slave response. I simply opened a queued session and sent the completion of the 0x3d message. There are no buses, and on the monitor I correctly see the master's 0x3C requests and its 0x3D response.
The only small problem, but I'm not sure it's on my side, is that the master sends me the following request:
0x3C 0x02 0x03 0x22 0x08 0x04 0xFF 0xFF 0xFF. So on NAD 2, I should respond:
0x3D 0x02 0x06 0x62 00 00 00 0x90 0x01
In this case, the master receives nothing, and on the monitor I see the 0x3D request without any data.
If I use NAD 0x00, the master receives the response correctly.
I don't know if it's my problem or the master's, I have no control over the master, it's a customer card.

I used the attached VI with the default data.

Another thing that I don't understand is how the database is used in this case where my LIN card is a slave, I tried to modify every parameter but I did not see any difference on the communication, seems the DB is not used by the VI.

Thank you.

Best regards.