LIN Frames input

[Madottati]

Hi all,

I have modified the "LIN Frame Input Output Same Port.vi", which is delivered as an example in the XNET driver package.

I added the transmitted frames as input of the "XNET Create Session (Frame Input Single-Point).vi", in order to see each frame (even the transmitted ones) when I call the Read Frame VI. It works fine, I see my 2 Master frames with payload, and the slave frame with the payload of my ECU.

The problem is, when I disconnect my ECU, I still get the frame from the ECU:

- with payload of all bytes = 0

- with the timestamp of the last received frame.

Normally, if there is no connection to the ECU, the master should transmit only the ID, and the payload should be empty - as no ECU writes its data to into it.

On the screenshot you can see, that the frames with ID 0x28 and 0x29 are transmitted and echoed, but the Frame with D 0x24 has also four zeros as data, without any connected ECU. Is there any setting, which disables the reception of "dummy" data?

Another question is, how to build up a CAN / LIN monitor with XNET. Is it the right way to call the "Read.vi" frequently and parse the resulted frames?

regards

Madottati

[Duffy2007]

Hello Madottati,

this is a behaviour that came from the driver and we can not change it.

When a Frame In or Out Single Point is configured the driver look into a register

for the identifier and reads out the values, if the cable disconnected the default

values will be rad out.

I hope the information helps you. 

[Madottati]

Hello Alexander,

yes I understood, but this doesn't help me.

Why are the default payload data read, if there is no data in? Once the slave for whatever reason stops sending data, the default data is not acceptable for me. On the LINape trace below you can see, that the master has sent the ID to the bus, but the slave does not respond. Only the 0x3D IDs appeear, but no data. If I see a trace using a <Frame Input Stream> session, I can't decide, whether the master didn't send the ID, or the slave didn't respond.

TX: 1 0016971797 Wakeup
TX: 1 0016971828 3C 08 FA 02 10 61 00 00 00 00
RX: 0 0016972156 3D 08
RX: 0 0016972468 3D 08
RX: 0 0016972780 3D 08
RX: 0 0016973092 3D 08
RX: 0 0016973404 3D 08
RX: 0 0016973716 3D 08
RX: 0 0016974028 3D 08
RX: 0 0016974345 3D 08
RX: 0 0016974667 3D 08
RX: 0 0016974979 3D 08
TX: 1 0016974995 3C 08 FA 02 10 61 00 00 00 00
RX: 1 0016975010 3D 08 FA 06 50 61 00 00 00 00

Madottati

[GPIB_Guru]

Single-Point sessions return the most recently received data. If not data is received, it returns default data. These modes are useful in hardware-in-the-loop type of testing where you are running a state machine and you will always work on the most recently received data. You determine default data vs non-default data by looking at the timestamp. Default data comes with a timestamp of 0.

It sounds like you should be using one of the queued modes (either Stream Input or Frame Input Queued). These modes only return frames that were physically received from the network. (if you are looking for a monitor of all received frames, Stream Input would be the way to go as it returns all received frames in the order received in a single queue.)

[Madottati]

Hi GPIB guru,

I have tired it with the frame input queued mode, It also doesn't delivers anything (empty array output of the XNET Read.VI), if I disconnect the ECU, which should respond.

The frame input single point mode returns the frame in the frame array output, but the timestampt is unchanged. My problem with this is, that there must be a time stamp, when the master sends the frame ID to the bus. And I can't see that, since it stays unchanged.

Madottati

[GPIB_Guru]

---

Madottati wrote:

I have tired it with the frame input queued mode, It also doesn't delivers anything (empty array output of the XNET Read.VI), if I disconnect the ECU, which should respond.

---

I am not sure what you mean here. If you use queued mode, it won't delive anything if the ECU is disconnected.

[Madottati]

Exactly that is the point!

The ECU does not fill its payload data, but the master sends the ID physically to the LIN bus. This ID is what I want to see in my trace, without any payload data&colon;

Timestamp + ID + no data.

[GPIB_Guru]

The header _is_ being sent on the bus.

You can enable logging of error frames (property node >> Interface:Bus Error Frames to Input Stream?) and you should see an error frame being logged in a stream input session. I believe it will show up as a timeout error (a 5 in byte 1). I am not sure if you get the ID that you attempted to send out or not, but you can experiment.

[Madottati]

I tried it also, but a "no response" is not an error, which could be returned from the hardware.

During my experiments I tried all possible property nodes and sessions, but I can't find the solution,