GPIB From Different threads

[bfarley]

I have a program with three threads talking to different instruments over the same GPIB bus.  I am getting regular hang-ups.  VISA is supposed to be thread safe, but is there something else I need to do - VISA lock or such?

Bill F 

[Robert M]

Hi Bill,

What version of VISA do you have installed?  The latest version is 3.4.1 

Do you, by chance, have another GPIB board you can add to your system for testing purposes?  I've seen something similar to this, and putting one of the instruments on a different bus while leaving the rest of the first bus seemed to solve the problem.

Let me know how it goes,

[bfarley]

Robert,

I'm using VISA version 3.2f1.  Were there any known issues related to this issue that have been corrected in later versions?

I dont think I could set up a second bus.  Either way, the deployed system can only have one.  So if I showed the issue was corrected after connecting to a second bus - where does that leave me?  I found another post with someone having the same issue, and he said he had to use VISA Lock Asynch to correct the probelm.  I really dont want to have to go to that - especially if I'm doing something that is supposed to be ok.

I had thought about creating another thread to do all the gpib comm - each thread would would send commands to the "command processor" thread via a queue.  This seems like it would be quite slow though, and there is a problem of doing queries - the calling thread has to block and wait for a response from the command processor via another queue or some such.

If anyone has any ideas on a smarter way to do this I'm listening...

Thanks,

Bill F

[johnsold]

Bill,

I think your concept of a separate communications node is a good one. I use queues for passing data and commands between independent nodes often. The queues themselves are quite fast.

As for the waiting for response issue, a state machine could monitor the condition "I wrote to the device and now must wait for a response" without blocking everything else. Just have an Idle state or Waiting for Response state. The next "Active" state cannot be entered until the response is received. The communications node can send responses to the correct place based on the GPIB address.

Lynn

[Ben]

Please see reply #7 in this thread.

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=797&jump=true

Ben

[bfarley]

Thanks Ben,

My problem is slightly different in that VI Server is involved and my hang ups are not temporary - they are the three-finger-salute kind.  However, I do know that the problem only occurs when another vi is running that does periodically transfer a lot of data (updating a graph with a specan display), which is similar to your issue.

LoganS said there is a fix coming to NI 488.2 but there were no updates to that message.  Is this still an outstanding issue?  I'm currently running version 2.30

[Ben]

Last I heard this was not fixed.

I have not been updated otherwise.

"The VI server is executed largely within the UI thread..."  as per Greg McKaskle in this thread

http://forums.ni.com/ni/board/message?board.id=170&message.id=151616#M151616

The problem I described in that thread has been seen to manifest itself in a complete lock-up if the operation times out.

Ben