After a RTE subsequence keeps returning the same value/status

[ShaOS]

Greeting!

I had the pleasure of inheriting a FCT at my workplace, running Teststand 2016 (32-bit) + LabVIEW 2018.

They had this machine since 2019, and since then it has a really perplexing issue.

They have one subsequence called [DiagOut_And_Compare] it contains one single VI [DiagData_and_Compare]. It's function is simple: it writes one frame to the CAN bus using XNET, and then reads the return message from the UUT.

It is being called multiple times (30+) in the sequence, but on the exact same teststep it sometimes returns a Error, it reports a XNET timeout. (Timeout duration is 80s, and we get no error messages on XNET using the BUS or I/O monitor.)

But this would be fine, except afterwards every single call to this subsequence will instantly report error due to timeout. Also the return string is always the same, furthermore the return string is the same as that of the last successful call.

Restarting the XNET sessions has no effect on it, it only goes away once the whole sequence is closed and reloaded. Has anyone encountered anything like this? I'm not sure if the VIs provided by the manufacturer are the cause, or there is anything I can try on the TS-side of it.

Any idea would be appreciated, as this issue is slowly driving me insane. 

[Oli_Wachno]

Can you please try "Unload all modules" in the Sequence Editor after the error has occured and re-run the seuquence?

[ShaOS]

Greetings!

I had some time alone with the machine:

1) Unloading all modules does fix the issue. 
2) If I unload the VI only (unload after test step), that does not. 

I don't understand this tho, If I stop right after a failure, my variables look like this:

1) The subsequence [DataToReceive] parameter should be the same as [Limits.String], but it remains that of the last successful call.
2) The VI writes the string it receives to [Local.DataOut] (and then compares that to the Limit) and it should be the same as [Result.String] but it is not. That also retains the value from the last successful call.

I could unload all of the modules if it detects an error, that would work, but I'm not sure if it would be optimal. 

[Oli_Wachno · Accepted solution]

Thanks for the feedback! For me, this lools like LabVIEW code using an uninitialized shift register somewhere in your LabVIEW code modules.

I'd bet that there is a shift register on an error wire somewhere.

Curing the cause would be to check you LabVIEW code modules, trying to handle this in TS would probably be a rather not so nice workaroud to get rid of the symptoms.

[ShaOS]

---

@Oli_Wachno wrote:

I'd bet that there is a shift register on an error wire somewhere.

---

As it turns out, you would win that bet!

That Vi calls a second VI, which calls a third, and that one looks like this:

Both the error and the data out wire is uninitialized, and it has no way of ever recovering from an error. 

Thanks for your help, my sanity really appreciates it!