gpib error code -1073807300

[Martin_Kroner]

  Hi,

I am using multiple VIs that communicate with different GPIB instruments via the same USB-GPIB-B connector. After some hours (sometimes days) I get a GPIB error -1073807300.  According to the knowledge base this should only occur if either the GPIB drivers are not properly installed (How can I check this? I would guess that the drivers are fine since the problem only occurs with several VIs running) or if more than one Visa session for the same instrument are open.  

I am using Labview 2009 on a WinXP computer. I thought that by denying multiple sessions in the visa open function this error should be avoided?  (By the way, the VIs communicate on the tens of ms timescale with the instruments)

Is there any way to fix this without putting all GPIB communications into one VI?

[smercurio_fc]

Actually, it isn't so much as having more than one VISA session for the same instrument, as it's having too many VISA sessions open. Are you constantly doing a VISA Open in your code? You should only need to do this once, for each instrument, at the beginning of your program.

As for checking your GPIB interface, you can use MAX to do that. If the error is related to that, then it's possible you have a USB issue. This has cropped up with some, and the usual culprit is the OS. 

[Martin_Kroner]

Thank you very much for your answer. Actually, I only have this problem with one particular VI that communicates with one device (an Agilent function generator). I originally did open the VISA at the beginning of the program and ended it at the end. But since the program is running all the time I thought perhaps something bad happens when the visa session is open and an other VI communicated with an other instrument over the same GPIB bus. So I opened end closed the visa session before and after every communication event. But this did not fix the problem. 

I do not have any error messages in MAX concerning the USB-GPIB connector. However a view months ago I had this "Interface lost power" issue that seems to be quite common with the USB-B device and I think I could solve it by using a particular USB hub with its own power supply. 

I attached a VI that caused the error. This Sub-VI is called by a the VI whenever the offset of the function generator has to be changed.  

In fact a monolithic VI that communicates with all devices runs error-free for days. So I was wandering, is there a special issue with two VIs running in parallel and independent from each other accessing the same GPIB bus?

[muks]

Have you seen this?

[Martin_Kroner]

Thanks, but yes I did see it. This is actually what inspired me to change my code such that I open the VISA session before and close it after each communication event. I am only wondering if perhaps the communication is being interrupted by an other VI communicating with a different device over the same GPIB bus before the visa session can be closed properly. Because, as I said, in a single VI when I open and close my visa sessions properly nothing bad happens and the application runs for days communicating with the instrument on the ms timescale. The knowledge base only covers the situation where the visa session is opened but not closed. Since I close the visa session in my code and still get this error, there must be something beyond simply closing the visa session. 

[smercurio_fc]

---

Martin Kroner wrote:
I attached a VI that caused the error. This Sub-VI is called by a the VI whenever the offset of the function generator has to be changed.  

In fact a monolithic VI that communicates with all devices runs error-free for days. So I was wandering, is there a special issue with two VIs running in parallel and independent from each other accessing the same GPIB bus?

---

While multiple devices can be addressed to listen, only one device can be instructed by the controller to be a talker (i.e., placing data onto the bus). Thus, if you have the potential of setting more than one instrument to be a talker, then you will have a problem.

Aside: In the VI you uploaded why did you make the command for the offset a string control with a default value as opposed to just a string constant?

[Martin_Kroner]

Thanks a lot! I see your point. So it is indeed a more sophisticated problem. Then the only way to really avoid this would be to somehow ensure that the different VIs are not trying to communicate at the same time.

The constant versus control question... This is a relic from when I started to make these subVIs. Originally I wanted to have only one VI that receives the command string also from the main VI. Only later I changed this without going back to string constants. So, is there a disadvantage for this? I know it is bad style... Perhaps, I should change this sometime... Still, thanks a lot for your interest in my problem!