Methods to store/retrieve GPIB handle/session during sequence run.

[GovBob]

Presently my sequence pulls the GPIB addresses (2 instruments) from stations globals to initialize the instruments. I then store the generated session/handle as a LabView I/O control (container) in locals to be accessed later in the sequence. I've also tried to store them in the file globals. I've tried a combination of the 2 methods as well. Has anyone used a different method to store GPIB Session/handles? I'm having a strange problem with calls to the instrument using the wrong address.

[RayFarmer]

Hi,

How do you mean "I'm having a strange problem with calls to the instrument using the wrong address"?

Is this during Initialisation?

What TestStand and LabVIEW versions are you using?

regards

Ray Farmer

[GovBob]

Thanks for your interest Ray,

 I'm using LabView 8.5, TestStand 4.0.1f1, NIVISA 4.2 (runtime) and NI-488.2 ver 2.52. I'm confident this problem is not related to hardware failure because I have 4 test stations plus my development station that exhibit this behavior. This application worked fine using TestStand 3.1 and LabView 7.1. The application was refactored to add some functionality and I used the same methods then that I'm trying to use now concerning sessions/handles. I do have an active service request into NI but since they don't have my hardware they are having a hard time helping me.

 The problem is not consistant meaning that it does not happen every 'run' of the sequence. It might happen on the 3rd 'run' or the 16th 'run' or at any 'run' but the first. I've whittled down the application so that I use NI's sequential model in the sequence editor to discount any custom software. This test sequence is rather simple as the only thing it does is make calls to 2 instruments. An IFR 2975 service monitor and a Agilent/HP 6642A power supply. I basically intialize the P.S. and set the voltage and current. I initialize the IFR. I then take 3 current readings (1 per step) from the P.S. with some wait steps in between. I close the session to the IFR, shut off the output on the P.S. and close the session to the P.S. Attached is a NISPY file of several 'runs'. At line 859 is the beginning of a good 'run'. At line 929 is the start of a 'run' where things go wrong. Each 'run' consists of 70 calls. If you compare line 878 (good run) with line 948 (bad run) you can see where the power supply is addressed wrong and even worse it is responding to the wrong address. I have nothing in my code that should dynamically change the address of this instrument.

 Short of initializing and closing the P.S. at each step that calls it I don't know what to do.

[RayFarmer]

Hi,

It seems like something is getting corrupted from the TestStand to the LabVIEW when you call the VISA Enable Event. I guess you are using the Session to Refnum to convert your handle stored in TestStand back to a session.

Did you say you used these same steps and code in an early version of TestStand with out any problems?

Is the IFR code using CVI driver wrapped with labVIEW?

Have you tried storing your handle in a labview global rather than retrieve it from TestStand. Just to eliminate TestStand. If you dont unload any of your SequenceFile then your LabVIEW will remain in memory and therefore you handles will not be lost.

Alternatively, you could pass a String containing the Resource Name String (GPIB::4) from TestStand to your VI instead of the U32 value.and wire this to your VI Resource Name connector.

Regards

Ray Farmer.

[GovBob]

Ray,

"I guess you are using the Session to Refnum to convert your handle stored in TestStand back to a session." I'm not sure about this. What I'm using is teststands "LabVIEWIOControl (container)". According to the help file this is a cluster of a string device name and a number session number. Is this considered a Refnum?

"Did you say you used these same steps and code in an early version of TestStand with out any problems?" Basically yes. The same methodology for storing session/handles worked under TestStand 3.1 LabView 7.1. Both drivers and step tests have changed. 

"Is the IFR code using CVI driver wrapped with labVIEW?" That's correct. Man you're good. If remember correctly IFR sent me a upgraded version of the CVI driver (because there was too many problems with the old one. but that's a whole other story) and I used NI's tool to create a wrapper in LabView 8.2.

I'm going to try your idea of using a LabView global at least for one instruments session/handle. I'm still trying to come to grips with how the power supply could answer to a call on the wrong address. I guess that will remain a mystery.

Thanks for your help and I'll let you know how it goes.

 Would posting the sequence do any good since no one has the hardware?

[Believer]

Hi GovBob,

Did you ever get this issue resolved? In the end was there any problem using the LabVIEWIOControl? I am just about to start instrument control and want to begin well.

Many thanks,

Ronnie

[GovBob]

Ronnie,

 You should feel confident in using the LabVIEW i/o control method. What I ran into was an isolated case due to a poorly written driver that was corrupting the data space.