Make XNET and ADCS coexist on a LIN bus

[aRCo]

Hi all,

I'm having a problem while trying to use LIN 2.1 and LIN UDS protocols at the same time on a LIN bus. I installed the XNET package for the LIN 2.1 side. I own the ADCS package and I would like to use it for the LIN UDS side.

In the example that I supply (TestLINCommuincation.vi), the top part concern the LIN 2.1 using XNET (Signal In/Out Single-Point), while the bottom one the LIN UDS using ADCS. In the UDS part there's also a VI called "EnterUDSSession" that uses two XNET sessions (Frame In/Out Stream) created specifically for it.

The XNET part works fine, but I'm stocked with the ADCS part as it generate an error (code -1074384497) when it tries to use the service "ReadByIdentifier" and the ID 0xFD03 (Capture.png, sorry it's in french.. 😉 ).

Any clue on the reason(s) generating the trouble? Can you give me suggestions?

Thanks in advance,

Marco

[JefeL]

The error in question has the description: A LIN diagnostic schedule change requires the diagnostic schedule to be defined in the database. Solution: Define the diagnostic schedule in the database.

This leads me to believe that the database you have selected is missing the details for master request and slave response frames. ADCS comes with an example database that includes these frames and their accompanying schedule. Try opening the shipping example ADCS_LIN_database.ldf in the database editior. The file can be located at:

C:\Program Files (x86)\National Instruments\LabVIEW <Version>\examples\Automotive Diagnostic Command Set

Check to make sure your databases have a schedule entry for both MasterRequest and Slave Response like the example database does:

[aRCo]

Hello, thanks for the answer!! Was busy for a while, but now I'm back.

I modified the VI in order to allow to select the working mode. Three modes are available : XNET, ADCS, and XNET+ADCS. This approach permits me to focus on a specific protocol.

The result of the tests done is that there's no problem using only one between XNET or ADCS. The error (-1074384497) arrives while the two are used together and when opening the UDS session (i.e. the first time an UDS service is used, in this case "UDS DiagnosticSessionControl.VI").

Do I need to change the schedule using "State LIN Diagnostic Schedule Change.VI"?

Thanks 😉

[JefeL]

I think the issue is with the databases used. I essentially recreated your test with a shipping examples and I get it to work fine with the ADCS_LIN_database that ships with ADCS. Its located at:

C:\Program Files (x86)\National Instruments\<LabVIEW Version>\examples\Automotive Diagnostic Command Set\ADCS_LIN_database.ldf

It also works when I switch to the NIXNET_exampleLDF shipping database that comes with XNET (They are very similar).

Without looking at your database it is hard to say. Take a look at the ADCS database and your database in a text editor and do a comparison. Try copying the Diagnostic_signals {} section from the shipping example and paste it into your database. Or try using these shipping databases with the demo ECU.

The example I am testing with is attached. I ran the example on LIN 1, the Demo ECU on LIN 2, a LIN Signal Output Single Point example on LIN3, and the bus monitor on LIN4 to verify all the traffic. You may not have that many interfaces to work with but I wouldn't expect you to get an error if the bus monitor and slave example are missing. You can run the bus monitor in subordinate mode to verify that the headers are going out.

[aRCo]

Thank you so much JefeL.

Here attached the original LDF database. Could you check rapidly and tell me if you see something wrong?

Moreover, owing LV 2017, I ask you to resend the example VI saved for that version.

Bye!

[JefeL · Accepted solution]

I understand what is happening now that I see the database. There is no valid diagnostic schedule to switch to.

ADCS expects the MasterReq and SlaveResp to be in separate diagnostic schedules while the database you provided has them in the normal schedule. Take a look at the ADCS_LIN_database to see how the diagnostic schedules are implemented. You might be able to have the MasterReq and SlaveResp frames in the same schedule but I haven't tested it. The diagnostic schedule(s) will need to be separate and distinct from the unconditional normal schedule.

Attaching a copy of my example saved for LabVIEW 2015.

[aRCo]

Thanks JefeL, I modified the database as suggested and optimized the VI (you can find the new version here attached). The communication works fine and I succeed in updating the XNET signals as well as the ADCS ones.

The only little problem that remains is related to the disconnection phase. In order to put the device to sleep at the end of the session, the master have to sent to the slave a sleep request (ID: 0x3C; Payload: 0x00 FF FF FF FF FF FF FF).

In the "CloseUDSSession" vi, I create a Frame Stram Out session, send this frame, and then close the session. Using a third interface to sniff the communication, this last frame is not logged, so, I presume, not sent.

I tried several things without success. Do you have suggestions? Thanks in advance.

Marco

[JefeL]

I can't open the CloseUDSSession.vi so I am not sure what it does exactly. My gut tells me that you may be closing the session immediately after a write which could stop the scheduler before the header is transmitted. I suggest adding a small wait after the write to ensure the hardware has time to execute the schedule and transmit the frame.

[aRCo]

The adding of the "XNET Wait (transmit complete).VI" in the sub-VI "CloseUDSSession" solved the problem. Everything works fine now.

Thank you very much JefeL! Here's your kudo 😉