XNET Read - Frame LIN VI - doesn't return

[Steiger]

In an application where we are doing a Sleep/Wake cycle on DUTs, I am seeing a very strange intermittent issue with the XNET Read VI, in which LabVIEW stays "stuck" in the Read VI, and control never returns to the calling VI.

The procedure we go through is as follows: we send a Wake signal to the DUT, wait ~300 ms, then do a Write and a Read to confirm the DUT is awake. The DUT is then allowed to go back to sleep by stopping communication. We then wait for 1/2 hour before re-trying the Wake test.

This will work OK for some amount of time, but after a few hours (very intermittent, anywhere from 1 to 20 hours), after we do the Wake command, the program will do the XNET Write, and then get "stuck" in the XNET Read VI, never to return.

The relevant LED on the PXI-8516 card will be blinking when we see this issue. We scoped out the communication with the DUT, and it appears the card is actually continually communicating with the DUT, doing the Write and Read of the correct frames, but for whatever reason on the software side, it's never exiting the XNET Read VI!

I've attached an image showing a comm sub-VI staying in the XNET Read VI, an image of the scoped LIN communication, and the LIN Comm VI itself. If anyone has seen a similar situation or could recommend next steps, I would appreciate it.

(This application is using XNET 1.8 and LV2010)

[JefeL]

Since your scope is showing back and forth traffic I would speculate that this loop is never exiting...

Double check your logic in LIN Comm-Check for Status Read Error.vi. Throw some debugging latches in there and or a timeout to see if you can find some anomalous behavior.

[Steiger]

I have probes in that loop, and they show the XNET Read never exits. When this issue occurs, the loop does the XNET Write, then goes into XNET Read, and stays there. The probe I have on the error wire coming out of XNET Read never updates, so it seems something very strange is happening in XNET Read.

It's also puzzling that the scope is showing the card is continually doing both the Write and Read, as if the loop is actually repeating, but the LabVIEW probes are telling me it isn't!

I've tried repairing and reinstalling XNET 1.8, but no improvement resulted.

[JefeL]

Have you tried putting an indicator on the iteration terminal of the while loop? There could be an issue with the probes or something. If the loop isn't iterating we can take a look at creating an I/O Trace of the XNET function calls.

[Steiger]

It definitely looks like the loop isn't iterating. 

I ran an IO trace with just the XNET calls selected. Attached is a screenshot. This was taken while 1 DUT was in this "stuck" XNET Read state, and 9 DUTs were in an idle state.

[JefeL]

Based on the IO trace it appears that the main loop is executing and calling the session info etc in the bottom left:

This is the only place that Session Info is called from what I can tell and it is called repeatedly in the IO trace. There is no mention of any other XNET code. Since neither of these two VIs are serialized with each other or the main state machine we could theoretically be calling them both plus the read simultaneously. I would like to recommend serializing the calls to Session Info and Comm State so that they are not in parallel. Additionally, I would then serialize their containing case structure to execute either before or after the main state machine executes.