LIN communication issue during connexion between NI-USB 8476 and TRC-8546

[TeraEngineer]

Hello,

I am using TRC-8546 to communicate on bus LIN with my slave device: it works (almost) well.

I would like to use the NI USB-8476 device to spy the datas transiting on the bus LIN but once I physically connect this device on my bus LIN, it totally blocks my communication between the TRC-8576 and my slave..

I know the connector is well cable because I use the same connector with a second TRC-8546 and it works.

(I am not using anymore the second TRC-8546 to spy because It seems that the NI-9860 which is handling both TRC-8546 is missing some datas to be spied..)

I have obviously checked here the pinout of the NI USB-8476, which is the same.

Also, I have made a self-test of the NI USB 8476 on MAX and it is fine.

So, do you have any idea to how to debug this ?

Thank you in advance,

[Hooovahh]

So LIN works in a master and slave configuration.  This means that one device on the bus is designated the master, and will pull the data pin high and hold it there.  Then it will pulse this line to populating the arbitration ID or header.  Then it is the responsibility of the slave on the bus, whos is responsible for that data, to then pull the line low.  Then the master will again pulse the line populating another arbitration ID.  This will then repeat and is known as the schedule.  This is different from CAN in several ways.  First the bus is deterministic.  You know how long it takes to send data, and you know how many IDs the master will request because you know the schedule.  CAN is nondeterministic.  Higher priority messages will go out and lower priority ones might need to be resent.  For this reason LIN is basically always at 100% bus load.  Well it can be less than that, but it will be because the master adds delays intentionally.

So why tell you all this?  Well because if you add another master to the bus, it will be pulled high, and no slave will be able to pull it down, and there will be no data.  So if you add another LIN device to just listen, it need to be configured as a slave.  Open MAX and find your device.  Then right click it and go to the bus monitor.  I don't have a LIN device at the moment, but from there you should be able to configure it and start it.  Then try connecting it to your bus and see what you see.  There are examples shipped with LabVIEW that can help configuring the device as a master or slave.

[TeraEngineer]

Hello again Hooovahh,

Thank you for this remind.

I totally agree with you, except that for me, bus monitor tool should and can be only in slave mode. Moreover, I can't select master or slave on that tool, neither on LIN module (TRC-8546) using XNET neither on LIN module (NI USB-8476)using NI-CAN.

I could try to check a VI which use NI USB-8476 configured as a slave, but, indeed, as soon as I plug the NI USB-8476, meaning making it joining the LIN bus node, I can not work properly between my TRC-8546 and my slave. Maybe the device is broken ?.

[Hooovahh]

Sorry I don't have any actual LIN devices to test with at the moment.  The bus monitor has been my go to program as a sanity check that the setup works.  It sounds like a database is required to use the bus monitor, which makes me think that it configures the device as a master, with a defined schedule.  

Maybe open the example finder in Help >> Find Examples in LabVIEW then open the LIN Frame Input Stream.  There you'll specify the interface, baud rate, and have Master unchecked.  This should just set it up as a slave and display stuff it sees.

[TeraEngineer]

Hello Hooovahh, 

---

@Hooovahh  a écrit :

Maybe open the example finder in Help >> Find Examples in LabVIEW then open the LIN Frame Input Stream.  There you'll specify the interface, baud rate, and have Master unchecked.  This should just set it up as a slave and display stuff it sees.

---

Indeed, it is an example for devices using XNET , not NI-CAN, so it could not work. By the way, I am surprised to not find any master/slave bit/choice for the example given of NI-CAN.. (!?)

Hey, I have just noticed (despite it is actually in your signature) that you are the guy who wrote the website I was using to learn some XNET stuffs. So I would like to thank you, it is pretty well made and helpfull.

I am struggling finishing my VI setting up the LIN communication with all my slaves. I have posted a topic here, could you please take look ?

[Hooovahh]

---

@TeraEngineer wrote:

Indeed, it is an example for devices using XNET , not NI-CAN, so it could not work. By the way, I am surprised to not find any master/slave bit/choice for the example given of NI-CAN.. (!?)

---

Oh yeah sorry I keep forgetting.  I have no experience with those older LIN devices, I've only ever done LIN in XNet.  I just expected there to be good examples and test panels for it.

---

@TeraEngineer wrote:

Hey, I have just noticed (despite it is actually in your signature) that you are the guy who wrote the website I was using to learn some XNET stuffs. So I would like to thank you, it is pretty well made and helpfull.

---

Thank you, you reminded me that I had a LIN/CAN Comparison blog post drafted that I never finished so I posted that yesterday.

---

@TeraEngineer wrote:

Hello Hooovahh, 

I am struggling finishing my VI setting up the LIN communication with all my slaves. I have posted a topic here, could you please take look ?

---

That looks like quite a challenge.  Muxing the LIN master, then getting the response back sounds painful.  I can't open the source since I don't have access to a 2021 machine at the moment.  In a previous project I did use a switch matrix card which allowed routing the master to one slave at a time and that worked fine, but it wasn't that many devices, and it wasn't a periodic schedule, it was a single frame at a time, on a single slave at a time.  And even that was slow just to verify the slave was talking.  Sorry I can't help any further.

[TeraEngineer]

---

@Hooovahh  a écrit :

---

---

That looks like quite a challenge.  Muxing the LIN master, then getting the response back sounds painful.  I can't open the source since I don't have access to a 2021 machine at the moment.  In a previous project I did use a switch matrix card which allowed routing the master to one slave at a time and that worked fine, but it wasn't that many devices, and it wasn't a periodic schedule, it was a single frame at a time, on a single slave at a time.  And even that was slow just to verify the slave was talking.  Sorry I can't help any further.

---

Maybe we are misunderstanding or maybe I am not seeing the difference between, but it is actually a kind of "matrix card" which allows routing the master to one slave at a time.

Concerning periodic schedule, as I just need to send one frame and to get on frame for each slave, I was in fact wondering if an other mode such as sporadic / event-triggered would work and be better. But I do not really know yet the way they work, so I am going to study that.

What's your point of view ? would it kind of speed up the execution time ?

I can save and share the source in older version on the other topic if you could check maybe?

---

@Hooovahh  a écrit :

---

---

Thank you, you reminded me that I had a LIN/CAN Comparison blog post drafted that I never finished so I posted that yesterday.

---

---

Glad to know that I have made you think about it 😃

[Hooovahh]

I only thought the sporadic or event driven frames might allow you to have a bit more control.  Like if you send a single frame, then you can choose the amount of wait used before trying again, or moving on to the next slave, and have control of the switching time for the mux.  I think with a periodic send I'd be worried that you can't really synchronize the mux well with the LIN traffic.  But again my experience with LIN is quite limited, and I have zero experience with the older LIN devices.

I think you should be able to accomplish what you want with this approach.  But in the future you might want to look into Intepid hardware.  They have a neoVI Fire 3 for instance that has 8 LIN ports.  There are basic LabVIEW drivers which might work but need cleaning up.  It would avoid some of the issues you are having, but would add cost and you'd need quite a few of them for this application.