Heisenbug: Subsequence call, different file, LabVIEW

[SPM]

Hi, all,

I'm wondering if anyone has seen this Heisenbug. Sometimes, not always, when I call a subsequence in a different file, LabVIEW refuses to start -- even if the subsequence contains no LabVIEW. Usually I have to kill all threads to clear the problem.

If I'm lucky, I get a message in the report that the LabVIEW ActiveX server couldn't be contacted or some such. Or sometimes I get a popup with a 406 error (Memory Manager) in LabVIEW.

Once this starts happening, the TestStand script is permanently scrozzled and I have to revert to a known good copy.

Also possibly relevant:

- TestStand 4.1, LabVIEW 8.5. 

- I'm starting a subsequence that includes LabVIEW calls in a separate thread. This has been working when the subsequence is in the same file. (The bug still shows up sometimes when the subsequence is in the same file.) 

- The only common factor I've seen so far is that both the calling and called files contain LabVIEW.

Has anyone seen something like this? It's killing my ability to modularize the tests I'm working on.

Thanks,

- Steve.

Message Edited by SPM on 08-29-2008 12:16 PM

[Norbert_B]

Steve,

since i never heared from "Heisenbug", i take it that you are talking about a sporadical appearing "bug".

So, there have to be situations where your application works like expected. True?

If so, is LV already open in the background when starting the execution?

What is the adaptersetting for the LV-modules?

Do you have restricted user rights? Does your user have access to LV at all?

hope this helps,

Norbert 

[SPM]

Hi, Norbert,

See http://en.wikipedia.org/wiki/Heisenbug for the origin of the term.

Yes, there are  .seq files that work OK when they call other .seq files.

The failure can be from a cold start of both TestStand and LabVIEW when it happens. Once it happens, it persists with the .seq file. (Other .seq files work, but the damaged ones never work.)

I do have access to LV and my user rights are unrestricted.

The adapter configuration is for:

• LV 8.5 development system
• Reserve loaded VIs for execution checked
• Allow only new templates checked (this shouldn't be a problem because it's all I have)

Does this help?

Thanks,

- Steve.

Message Edited by SPM on 09-02-2008 08:56 AM

[Norbert_B]

Steve,

reading your post leaves the impression that this malfunction occurs only after a reboot.

So i take it that you switch on the PC, start TestStand after booting and start the execution. There it can (!) happen, that the file somehow gets messed up and does not work anymore with the given issue.

Other sequencefiles can be loaded and executed properly after this.

If that is correct:

Can you check out if this behaviour is connected to e.g. special VIs?

Did you ever encounter this issue with examples from NI?

Is it connected to certain sequencefiles? If so, how do they concur (e.g. step definitions)?

What happens if you make sure that LV is running before execution of the sequence?

If you reboot the system, is the "corrupted" sequencefile still malefunctioning or does it (possibly) work again?

hope this helps,

Norbert 

[SPM]

Hi, Norbert,

The malfunction can happen any time, not just at reboot.

After rebooting, a corrupted sequence file stays corrupt.

The only concurrence I've seen between sequence files where this happens is that the calling file starts a separate thread and both the calling and called files use the LabVIEW adapter. Calling and called sequence files also access physical device channels (DAQ-6501) but the called sequences need not do this to produce the malfunction.

I've never seen this issue in the examples from NI.

My "gut feeling" is that the interface between TS and LV is a little different in the cases where subsequences are contained in the same file versus other files. Maybe the threading sometimes (but not always) makes a difference too.

- Steve.

Message Edited by SPM on 09-02-2008 10:51 AM

[Norbert_B]

Steve,

is it possible for you to create a small example sequence where this issue can occur at your machine? If so, please post it as well as all used modules.

Do you have the chance to check on another system? (maybe corrupt installation of LV and/or TS) 

Norbert 

[SPM]

Some progress. It looks like the problem occurs when two or more sequence files call subsequences in the same file -- but the situation is more complicated than that. Not all LabVIEW steps lock up. I'm still working to understand the difference between what does and what doesn't.

Adding other new sequences that call the same subsequence filereproduces the error, so I'm thinking that actually it's the subsequence file that's getting corrupted.

Screenshots of the LabVIEW error messages attached. The first occurs when the LabVIEW adapter is first executed in TestStand. The second occurs when I shut LabVIEW down after the malfunction.

Thanks,

- Steve.

[RayFarmer]

Hi

What version of TestStand are you using with your LabVIEW 8.5?

I would try, un-installing then installing your TestStand and/or Labview again, because you should get any problems just adding a new sequence to a sequence file. Try disabling your virus scanning during your installs.

Regards

Ray Farmer

[SPM]

The problem occurs on at least two machines, so I doubt it's a munged installation.

Using TS 4.1.

- Steve.

[RayFarmer]

Hi,

[....LabVIEW refuses to start -- even if the subsequence contains no LabVIEW. Usually I have to kill all threads to clear the problem. ]

I have never know LabVIEW to even start if you have no LabVIEW adaptors used in a SequenceFile.

Is it possible to supply a small example that hightlights this problems.

Regards

Ray Farmer