Automotive and Embedded Networks

[LVB]

Why does the first read of the Frame Input Single-Point always return a zero timestamp and default payload?

This can be seen using "CAN Frame Input Single Point" from the example finder.

[GPIB_Guru]

Has a valid frame been received from the CAN bus?

[LVB]

---

GPIB Guru wrote:

Has a valid frame been received from the CAN bus?

---

What XNET function returns this information?

I start the CAN Frame Output Stream VI before starting the CAN Frame Input Single-Point VI so there are frames being actively transmitted before the CAN Frame Read occurs.

[GPIB_Guru]

You are essentially doing a "Start", "Get Comm State", "Read". Note that the latter two VIs are quite fast to execute.

You are running at 500k.Assuming that there IS a frame being transmitted right around your call to "Start"

1. Assuming that the transmitter started to transmit a frame immediately AFTER you called Start (best case scenario for you), the frame is going to take 242us until it is completely transmitted across the bus.

2. Assuming the transmitter started to transmit the frame immediately BEFORE you called start (worst case scenario), the frame will transmit across the bus and you wil not receive it (since you were not started when the frame started). If there are no other listeners on the bus, the frame will be retried and you will receive it the second time. Since the frame transmitted essentially 2x, it will take about 484us (slightly less since it started before start, but this is a good estimation.

So, essentially, after start, you need to wait about 242-484us until the frame will be received by the XNET card. (note, if the transmitter isn't transmitting until after you call start, it could be significantly longer). Since you are calling "Wait for integrated", this will take some time (but it waits for an integration, not for a frame to be received. Integration is typically about 11 bit times of an IDLE bus, which should be on the order ot 20us plus some overhead, so we can call it 50us. The other calls as mention just read from local memory and are fast to execute, probably on the order of single digit us... Therefore, your first call to read is happening about 20-100us after start, which is too quick for a frame to have been received.

[LVB]

---

GPIB Guru wrote:

...

your first call to read is happening about 20-100us after start, which is too quick for a frame to have been received.

---

You are correct about the delay required before the read.

---

From the NI-XNET Hardware and Software Manual

If the session mode is Frame Input Single-Point, set number to read to either –1 or the number of frames in the  sessions list. This ensures that the XNET Read (Frame CAN).vi can return the current value of all session frames.

If the session mode is Frame Input Single-Point, you must leave timeout unwired (0.0). Because this mode reads the most recent value of each frame, timeout does not apply.

---

I was expecting the XNET Read session to wait for a frame before returning because I wired "number to read = 1".  The Frame Input Queued session behaves this way.  However, it appears both the "Number of Frames" and "Timeout" are useless with the Frame Input Single Point...  The only way to "wait" for a "valid frame received" is to poll the XNET Read function for a nonzero timestamp.

[GPIB_Guru]

That text is not very useful. Basically, Single-point input returns immediately. Setting the value to 0 or the number of signals does exactly the same thing. Setting it to a different value probably returns and error, but I would need to check. There are no timeouts for single-point input. If you actually care about NEW data only, you can add a trigger signal to your list and keep reading until that returns a 1. Single point is typically used for HiL or something else where they only care about recent data and they often set reasonable defaults in case the data hasn't been received yet.