LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Visa open, write, close

Hi everyone,

I am quite new to labview, and I was wondering if someone can explain how visa open, write, read and close really work. In my knowledge (which is close to non-existent), when I use visa write, it opens the visa session, then why do I need visa open? Also when I use visa close, does it change any setting of the port? Should I close visa after every command, if I have  a big program and the same instrument will get used a lot of times? Or should I open the session at the beginning of the program and just do normal visa write and read, and close it at the end? If I close the visa session after every command, am I risking any error, because next time I will send a command using visa write, it will open a session again either way?

 

Thanks,

Kaawn

0 Kudos
Message 1 of 12
(3,924 Views)

Open use it forever close when the program exists.

 

Otherwise you are risking a memory leak when the VISA resource is allocated.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 12
(3,910 Views)

Hi Ben,

Thanks for the reply. So if I have main and instrument handler, I should open it in main, call instrument handler to read or write for as long as I need, and close it at the end from main. Would that be a good structure? Also, how am I risking a memory leak?

 

Thanks,

Kaawn

0 Kudos
Message 3 of 12
(3,906 Views)

Reads and Writes will open the VISA port automatically.

VISA Open is not really necessary, and actually probably not that useful, other than perhaps to receive and error in the event the port is already opened by a different program, or the port doesn't exist.

 

VISA Serial Configure is much more important so that you can set baud rate, data bits, termination characters to be different than what is set within MAX.

VISA Close will cause the settings to revert to MAX defaults the next time you open it unless you do the serial configuration again.

 

Generally you should not close your port after every command.  If you are doing regular communication, open once at beginning of program.  Read and write within your program.  Close before your program ends.  Now if you go long stretches without needing to read or write, then go ahead and close it.  Or if you need to programmatically change which port you are using, then close the old port and open and configure the new port.

Message 4 of 12
(3,904 Views)

Hi RavensFan,

Thanks for the reply. If I have multiple instruments connected in different ports, I will need to open the visa sessions separately, and close them separately, right? So I would probably open them all at the beginning, use them while the program runs, and close them all at the end of the program?

 

Thanks,

Kaawn

0 Kudos
Message 5 of 12
(3,901 Views)

Yes.

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 6 of 12
(3,875 Views)

@Ben wrote:

Open use it forever close when the program exists.

 

Otherwise you are risking a memory leak when the VISA resource is allocated.

 

Ben


I've been using VISA functions for years now and typically open and close the connection no more than a few dozen times in a given use session. It's obviously not enough to cause a problem, but is this a bug, or is it just a potential issue if you don't close your references correctly? For my use, it's basically required that the port is closed between "tasks" because we switch back and forth between a manual terminal and the automated program.

 

Edit to OP: I agree with the other posters that "open once, use forever" is a simpler, better way to go for most programs, I just have something of an edge case. I don't mean to advocate for opening and closing ports all the time.

0 Kudos
Message 7 of 12
(3,863 Views)

@BertMcMahan wrote:

@Ben wrote:

Open use it forever close when the program exists.

 

Otherwise you are risking a memory leak when the VISA resource is allocated.

 

Ben


I've been using VISA functions for years now and typically open and close the connection no more than a few dozen times in a given use session. It's obviously not enough to cause a problem, but is this a bug, or is it just a potential issue if you don't close your references correctly? For my use, it's basically required that the port is closed between "tasks" because we switch back and forth between a manual terminal and the automated program.

 

Edit to OP: I agree with the other posters that "open once, use forever" is a simpler, better way to go for most programs, I just have something of an edge case. I don't mean to advocate for opening and closing ports all the time.


I would still use the open once, do stuff then close at the end paradigm in your case. However, your task would dictate when the open/close occur. So your would open once in the beginning of a session, do all you stuff and then close at the end of the session. Essentially, leave it open while you are actually using it and close it when not in use.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 8 of 12
(3,844 Views)

Oh yes that's what I'm doing. The automated test is a bunch of commands executed over a few minutes, then the run is done and it releases the port. I was meaning to differentiate between "open port at the start of the entire program's execution, close port when the program closes" and "maintain an open connection only part of the time, while it's actively in use." Sorry for the confusion.

 

I was trying to determine if there was an actual memory leak when opening and closing ports, as this test will be run 50-100 times a day (opening two ports and closing them per run). 50-100 times shouldn't be enough to cause errors even with a memory leak but I'd like to know for future program use if it's a potential problem.

0 Kudos
Message 9 of 12
(3,837 Views)

Bert posted ;

 

"

I was trying to determine if there was an actual memory leak when opening and closing ports, as this test will be run 50-100 times a day (opening two ports and closing them per run). 50-100 times shouldn't be enough to cause errors even with a memory leak but I'd like to know for future program use if it's a potential problem.

"

 

I do not think of it as a memory leak because I feel that term is intended to speak of memory that goes away with no explanation of were it went or how to get it back.

 

It is more a matter of understanding the environment that our LV applications run in.

 

I will not commence to hand waving since my knowledge of the OS stopped about the same time as Window NT was invented.

 

When we "open" a connection to a VISA resource (as well as many other similar operations), we are asking the environment (PAL?) to prepare a method for us to interact with the hardware (for example). Hardware is owned by the OS. We have no direct access to it without the OS providing such access.

 

The access is implemented using small blocks of memory that identify what type of access it is (DB, Hardware, etc) and the handles/pointers needed for the OS to understand the nature of the request or operation.

 

Let us step back into the way-back machine when the term "blue screen of death" was something that developers encountered on a regular basis. Those Blue Screens of death were very often "memory access violations". Access violation happen when the CPU attempt to access memory that it does not have the privledges to access (example Kernel mode is required to map memory) or is not mapped to the process.

 

I modern OS's the Blue Screen of death do happen as often as they used to. I suspect this is because resources like  a VISA session when closed are simply "marked closed" waiting to be removed. BUt the "marking" as closed does not removed the pointer/handle to the data structure but only set a bit or some such.

 

Using the approach of "marking" instead of removing allows the LV environment to cover for some of our mistakes that result from the data flow paradigm coding what we drew and not what we intended.

 

Imagine someone opening a VISA session branching the session wire writing then closing in one branch then trying to read in another branch of the wire. If the VISA close actually unmapped the resource, the read after the close would be pointing at a invalid data structure dogs and cats living together and blue screen of death.

 

But by simply marking the session as closed, the late Read can unmark the session as closed and use it as if it was never closed. No Blue Screen of Death.  

 

Done with the hand waving!

 

A few years ago I wrote a quick VI that did nothing but "open, read, then close" in a loop with no timer slowing it down and let it run over the week-end. On Monday morning I noticed the VI had more memory allocated to it. When I stopped the VI and it went idle, the memory foot print (Task Manager) went down.

 

I walked away from that experiment with the impression that there was a very small (in the old days 1K was not small!) amount of memory that was associated with each "Open".

 

Bottom Line:

There is memory associated with each open. Not a lot but it is there. If we are writing a cRIO app that has to run for years without a reboot, then we have to be aware that repeated open and closes will kill your memory eventually.

 

Form most application that are started run for a few days and then stopped, this entire post and point can be ignored.

 

That is my story and I am going to stick with it!

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 10 of 12
(3,787 Views)