VISA READ timeout error - multiple GPIB resources

[astralth]

Hi,

I am working on a 3 instruments GPIB network (optical attenuator, fiber amplifier, spectrum analyzer), controlled using VISA sessions in Labview. When run separately, the three corresponding VIs (which are located in three different Labview projects) work as expected. However, when they are ran simultaneously, one of them gives VISA READ -1073807339 timeout errors. These errors seem to happen when an other instrument is sending / receiving data / instructions at the same time as it is.

The exact context for these error is either :

  -  an other VI is running, which includes sending several queries and reading the answers every 100 ms,

  - upon starting the failing VI, I get a  timeout error from one of the first subVI containing a VISA READ operation to be executed (sometimes initialize.vi (in state 1), sometimes one of the subVIs ran from the Idle state (state 0) upon timeout of the event structure).

or :

  - the failing VI is running,

  - upon starting an other VI, which includes repetitively sending queries and reading answers, the failing VI throws an error from one of the first subVI containing a VISA READ operation to be executed (one of the subVIs ran from the Idle state (state 0) upon timeout of the event structure).

What I tried :

  -  gradually increasing the delay between the VISA WRITE and READ operations for the relevant instrument (from 10 ms to 10s), to no avail. More puzzling is my obseration that, when this VI is run alone, increasing the WRITE / READ delay leads to the same timeout errors. I could not find any mention of such behavior through google and forum searches. Hopefully this can point to a solution to the main issue,

  - switching between synchronous and asynchronous VISA WRITE / READ operations,

  - reordering the GPIB network from a star topology to a linear topology (all three instruments do have different GPIB addresses in case anyone wonders).

My thoughts :

It seems to me that the error is related to a delay introduced between a VISA query and its associated read operation by the transmission of another query to another instrument in the same GPIB network. However I have no idea why transmitting a query to another instrument would introduce such a delay, or why this delay would lead to a timeout error (and only from one instrument, while the write / read VIs in each driver are basically the same). Hopefully a more experienced Labview-er will be able to shed some light on my issue.

Included is the project containing the failing VI (main.vi) and the custom driver it makes use of. 

[Dennis_Knutson]

GPIB does not permit simultaneous communication so add code for sequential operations. Of you want simultaneous communication, you would need a dedicated GPIB controller for each instrument.

[astralth]

Thank you for answering Dennis. Is there any tidy way to sequentialize the GPIB transmissions from different Labview VIs in different projects that you know of ?

[tyk007 · Accepted solution]

There are a number of ways. If you want to keep seperate projects for the instruments you could use the often maligned semaphores around your calls for the VIs in each project. The locking is not scheduled or predictable but it would give you controlled access to the GPIB resource.

[astralth]

Thank you for your suggestion tyk007, I will look into semaphores. I think I should learn more about GPIB operation too, I was convinced that it the commands were put in some kind of queue before being sent to the instruments.

I will wait to see of anyone has a other suggestions and close the topic. Thanks again !

[crossrulz]

---

@astralth wrote:

Is there any tidy way to sequentialize the GPIB transmissions from different Labview VIs in different projects that you know of ?

---

In different projects?  Semaphores will not work then.  Within the same project, semaphores will work quite nicely.

If we are talking about actual different applications, then what you really need is yet another application that you can send TCP messages to that does the actual communications over the GPIB bus.  This is a major pain to do properly.

My main question would be why do you have multiple applications trying to use the same instrumentation bus?  Everything for the instrument communications should be in a single application.  Then you can use the semaphores.

[astralth]

Thank you for your input crossrulz. This is indeed what I realized while looking into semaphores.

Let me first make our architecture clear so that I'm 100% certain we are talking about the same thing. We have a NI GPIB-USB-HS GPIB Controller connected to a linear GPIB network of three instruments. I was convinced that a network allowing up to 15 instruments to be connected at the same time would allow for parallel operation, but it seems I was mistaken.

I like how semaphores work, and I don't see any obstacle to gathering all these VIs into one project. My conception of a Labview project was that one Labview project was intended to gather subVIs, libraries and controls used in a more complex "main" VI, which would ultimately be made into a single standalone executable. It seems I was mistaken too and that a single Labview project should be used to gather several standalone VIs designed to work together, and their subVIs. Hopefully I got it right now.

The other option that you suggest for accessing the same GPIB bus from different projects (having a TCP control interface running and controlling communications through the bus) might indeed be a bit overkill for what I'm tring to achieve, and I would need to spend too much time learning and developing it.

A last option I looked into is the VISA Lock Async VI, but I don't understand yet if 1. locking the VISA session for an instrument in the bus would lock the entire bus ; 2. if it would be possible to use this approach with VIs running in different projects and 3. if it would not just yield errors when one VI is trying to access the locked GPIB bus instead of making it wait until the resource is available.

I'll look further into these options today, but would appreciate any additional information / advice you might have. Thank you.

[tyk007]

Sorry, I assumed you were referring to project libraries not projects; my bad. Crossrulz is indeed correct, projects in the development environment are self-contained in terms of memory allocation (to gloss over the dtails) so they are more involved than just a simple way of collating the VI hierarchy of an application. They key is that last word application - everything you need for an application to work should be in the project. This includes your GPIB instrument VIs as well as your Main VI. This would be my recommendation rather than an inter-process communication method. You could still use VISA Lock/Unlock methods for VIs in the project instead of semaphores but I personally prefer the freedom of being able to extend my lock "scope" to actions other than GPIB communication without adding confusion later.

[astralth]

I think the best way to deal with this is to gather my 3 main VIs (which each open a separate window)  in a single project and run them from here. This way I can implement semaphores.

The way I did it is that I used autopopulating folders to include the files from my three original projects in a "master project". Is it good practice or is there a better way to do this ?

I'll keep you updated with how implementing semaphores go.

[tyk007]

---

@astralth wrote:

I think the best way to deal with this is to gather my 3 main VIs (which each open a separate window)  in a single project and run them from here. This way I can implement semaphores.

The way I did it is that I used autopopulating folders to include the files from my three original projects in a "master project". Is it good practice or is there a better way to do this ?

I'll keep you updated with how implementing semaphores go.

---

In your scenario auto-populating folders are fine. If you plan to build a single executable do not forget that you need to have a single VI as the starting point. This can call the three Front Panels you want to show; set them to automatically show the front panel when called.