LabVIEWIOControl not always passed into VI.

[drewsali]

Hi all,

I'm using a FileGlobal in TestStand to keep an array of LabVIEWIOControls of all the comports I am accessing in my serial application. I pass the variable into one particular VI (Communication.vi) several times throughout my test sequence, but some of the time the VISA resource name is not passed in and an "_unnamedTask< (0)" appears in the VI for the VISA resource name control on the front panel instead of the comport name (i.e. "COM1").

Of course the VI errors if it does not have a VISA reference and it reports

"VISA:  (Hex 0xBFFF000E) The given session or object reference is invalid

-1073807346; User-defined error code."

However, in debug mode, when the front panel displays and the VISA resource reference is unnamed I can select the appropriate comport in the drop down and the VI works.

I'm monitoring the FileGlobal in the step settings window in TestStand, and it has the proper value, and the variable is wired to the VI and passed in through the connector pane. Why is it losing the comport value some of the time? Seems like it works for the first few VI's, (it usually trips on the second or third instance of the VI, but not always) but once the value stops getting passed, it is stuck that way until I terminate the sequence.

The test sequence is not new, but this error is new and on the heels of me upgrading from TestStand 3.5 to 4.1.

Thanks for hints. I can post .seq and vi's if needed.

Andrew

[Eric_L]

Hello Andrew,

Please go ahead and post the sequence and VI files for us to have a look at.

Eric

[drewsali]

Here is the sequence and the VI in use. TestStand 4.1/LabVIEW 8.6

[drewsali]

Here are some dependency files for "E4-Sys_Communication.vi". I just realized that I left them out and they might be helpful for anyone that is trying to look at the VI.

[drewsali · Accepted solution]

Though he is not participating in this thread, Kudos to Bryan Heslop, FSE for New Mexico for helping us to identify the issue.

The root problem was mismanagement of the VISA resource session. Using probes in LabVIEW and the watch window in TestStand, Bryan helped us to narrow down the issue to a particular step in TestStand that was calling a VI that was closing the VISA session. We had not noticed this because TestStand was holding the value in a fileglobal and it was not apparent that the session had been terminated.

Curiously, this same mismanagement of the VISA resource was/is not a problem in the seemingly more lenient TestStand 3.5. There must be a difference in the way 4.1 handles VISA sessions that makes it a hard failure. I would still be interested to understand the difference if anyone has insight on this.

Thanks,

Andrew

[Kracken]

Hi Andrew,

That is great to hear!  Big Kudos to Bryan!

Regards,

Brandon V.