07-02-2020 06:02 AM
Something strange happens on one of our test systems, where we test LIN DUTs over diagnostics. Everything runs okay, and sporadic we see the following things in the LIN trace, see attached screenshot.
I used google to figure out what it can be, but I could not find the root cause. Can anybody tell me what happens?
Thank you in advance
Madottati
10-12-2020 08:58 AM
Hi,
What Test system do you use ?
10-12-2020 09:40 AM
Hi,
we use our custom test system for automotive parts, but this is unimportant. The error comes from the XNET driver, and we experienced it with cDAQ, PXI and PCI XNET cards.
Madottati
10-30-2020 03:28 AM
Hi,
What driver version do you have ?
11-02-2020 01:43 AM
Hi,
I tried NI XNET 18.5 and 19.1, there is no difference.
11-16-2020 07:51 AM
Maybe this can be helpful.
The time to wait for the LIN frame data to be queued up for transmit. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds.
If timeout is positive, XNET Write (Frame LIN) waits up to that timeout for space to become available in queues. If the space is not available prior to the timeout, a timeout error is returned.
If timeout is negative, XNET Write (Frame LIN) waits indefinitely for space to become available in queues.
If timeout is 0, XNET Write (Frame LIN) does not wait and immediately returns with a timeout error if all data cannot be queued. Regardless of the timeout used, if a timeout error occurs, none of the data is queued, so you can attempt to call XNET Write (Frame LIN) again at a later time with the same data.
This input is optional. The default value is 10.0 (10 seconds).
If the session mode is Frame Output Single-Point, you must set timeout to 0.0. Because this mode writes the most recent value of each frame, timeout does not apply.