I have been writing LV code for quite a long time and am always trying to improve how I do things. Recently I came across a comment in one of the forums that VISA Open is no longer needed. Close is generally still recommended. Here are some other places where a similar discussion was held but the kind of closure I'm looking for wasn't achieved.
tl;dr Is there consensus on whether it is worth the while to carry a VISA Session around an application as in an action engine?
In my application I open VISA Resource name/handle/session for each available instrument and make program functionality available based on that initial attempt by VISA Open. I then hang on to that session for each instrument in an instruments action engine. I use it whenever needed and only close it at the end of usage, which could be several days away. A complication is that at some point, the user might want to talk to a previously unavailable instrument and that instrument is now available. I want to try to Open again at that time and if successful, store this now valid VISA Session information. That is how I am currently handling things and I have to write/maintain quite a bit of code to use the valid/invalid session information. I do this to keep inability to status/command messages very limited.
Would I be better off just using VISA Write/Read as needed and never passing the session reference around? The benefit would be that I don't have to disable sections of code based on instrument status, I would just make the attempt and catch and present any errors that occurred. I could still implement a close, it's just that I would write/read/close a given instrument based on the VISA formatted string address.
So, what I am asking is, am I being a dinosaur by using the methodology of storing and passing around my VISA handles/session references as if they were my precious and having it drive the whole design?
Sad there were no other responses to this.
I didn't even know this discussion existed!
As for what I do, it depends on the situation. But in general it boils down to 2 ways to manage my sessions:
1. Use a Queued Message Handler. This is a parallel loop that uses a queue or User Event to get commands to do something. This loop is specific to a single instrument. When the QMH is commanded to shutdown, it closes its session and stops.
2. Use an Action Engine to store the object for my instrument. I have been using OOP and PPLs to make Hardware Abstraction Layers (HALs). So all of my instruments end up in a class. But then I will use the AE to store the objects for a type of instrument and use some lookup (usually a string) to get the object of the desired instrument. I tend to use the global close to have all of the objects in the AE perform their close process. This will have to be called by the main application as part of the shutdown process.
Ok, so I *am* still following best practices by sternly encouraging others on my team to implement a VISA open and a VISA close in the QMH. We inherited some legacy code that after so many runs will destroy the VISA bus. I asked them to point out where they manage their VISA sessions. I was met with blank stares. I informed them that this was probably why after x number of runs, our VISA bus is trashed and we have to power cycle the PC in order to restore communication with our GPIB instruments. They pointed out that the code seems to work just fine without a VISA open.
This led me on a Google search which directed me towards this year old discussion with no responses.
I guess I shall continue my potentially dinosaur methodology of storing and passing around my VISA handles/session references as if they were my precious.
OK, here is how it really works.
LabVIEW calls into VISA by string. If a Session exists with that String as the name VISA uses that session. If no string matches, VISA creates a new Session.
So Any session you have saved in a SR or FBN in an Action Engine really persists until the vi goes idle and the VISA memory is de-allocated. (Like if you unload a sequence from TestStand that called your VISA resource module Action Engine).
CAVEAT: The VISA Property User Data does not persist.... VISA Bug not anything NI can control.
So,"Engines" for VISA Resources, Scoped to a Library on a project, with the API Public and the engine core.vi Private, is the best practice I know of.