Insufficient system resources error

[REash]

napview, yes, Dennis and I both did get confused...we just said so...we got confused by you.  Your answers do not make sense...they are not coherent and you seem to go back on what you say.  And Dennis' answer on the driver DID help.   Dennis did not lose track at all of the issue I raised...trust me...his answer are all helping tremendously.  And he was not the one that was concerned over the size of the program...that was someone else that answered, if you look back.  Thank you for your attempt at helping, but I don't understand much of what you're trying to get across to us.  And like I said, the last known problem was corrected.  I will found out on Monday if it occurs again further in the program.  It is possible that all is solved now.  Like I said before, I'll let you know.

Thanks,
Ryan

[REash]

Just to let you guys know, all of what I did throughout this thread fixed my problem.  I no longer have the "insufficient system resources" error.  It was little bit of a combination of a few things that appeared to cause the problems in my program.  But that darn agn330xa IVI driver for the Agilent N3301A Electronic Load appears to be very finicky, compared to drivers for any other instrument I've ever used so far.

Dennis, thank you for all the help.

Ryan

[cfyao]

Hi,

I also got "Insufficient system resource" error and I understand that this is caused by a lot of VISA sessions left unclosed. I checked my VIs, each instrument I initialized, which will eventually call VISA open in a sub-VI developed by other people, I close it, which will call a sub-VI that calls VISA close. Although the numer of open and close are balanced, the "insufficient system resource" error occurs after run my LabVIEW test software several hours. In order to pingpoint the problem, with each call to VISA open I write VISA resource name into a log file, and with each call to VISA close, I write VISA resource name to another log file. After deleting the common resource names in two files, each remaining resource name in open VISA log file has one or more corresponding names in close VISA log file. For example,

    Resource name in open VISA log file: GPIB0::13

    Resource names in close VISA log file: GPIB0::13 3, GPIB0::13 5, GPIB0::13 7, GPIB0::13 9, GPIB0::13 11, .... GPIB0::49.

This probably tells me that there are a lot of unsuccessful closes. But how come the resource names change when closing VISA session? What do the last numbers (3, 5, 7...)  mean? Strange enough, all these extra numbers are odd numbers. But for other instruments I also got even extra numbers in resource names.

Looking into the sub-VIs that calls VISA open and VISA close, I found that after a VISA session is opened, the sub-VI convers VISA session refnum to an unsigned integer by calling "Refnum to session" VI and this is further converted to a long integer and saved to a cluster. Before VISA close is called, this long integer in the cluster is first converted to unsigned integer and then to VISA session refnum by calling "Session to refnum" VI, which is the input of VISA close VI. The resource names in my close VISA log file come from here. Is it possible that these conversions cause the problem?

Two log files with common resource names removed are attached.

Thank you very much for any help!

MB

[Dennis_Knutson]

The Refnum to session is a VI that comes with TestStand. Is that what you are using? If so, could you possibly post and example sequence and the VIs that you are calling? The number after the GPIB resource name is the VISA session number to the same resource. So it does look like you not doing a close correctly but it would help to see your code.

[cfyao]

Dennis,

In TestStand there is a container custom data type defined which contains informations of an instrument. IO Refnum is a field in the container. Teststand sequence retrieves a database to fill the container, but IO Refnum does not come from the database and is never used in Teststand sequence. LabVIEW VI gets the instrument information from the TestStand container and fills a cluster. In the VIs I attached, the cluster is defined in IO Cluster.ctl. There is a field named IO Refnum in this cluster. I VIs I attached, the top level VI is IO_Class_GPIB.vi, which I simplified a lot so that you see open and close VISA session cases only. One thing worth paying attention to is that in VISA IO Open.vi the VISA Open sub-VI is called with "duplicate session" input being TRUE. I saw a post in this forum some people said that this parameter should be FALSE. Because these VIs were written by othere people, I don't know the purpose of setting this input to TRUE.

There are five VIs to be attached. Since only three attachments are allowed, I'll attach three of them in this post and other two in the following post.

MB

[cfyao]

Two more VIs attached.

MB

[Dennis_Knutson]

Well, I have no idea why someone would need duplicate sessions intead of just reusing an existing one but there's where all of the duplicates are coming from. Also, In the VISA IO Open there's a while loop with retries (!). If there is an error condition, a new session is created and the old one never gets closed. I don't understand the need for the while loop either.

[cfyao]

Hi, Dennis,

You are right. If a new session is opened, the old one is never closed because the new session refnum overwrites the old session refnum stored in the cluster. Thank you very much!

MB