While running a .net 3.5 application it always has a "System.OutOfMemoryException" error and it appears to be an ni488.2 problem. Any ideas?

[cmseguin]

Ok, will do. Thanks.

[Anna_K.]

You mention that you are now using VB2010, that version is actually not supported by 488.2.2.8 (latest GPIB driver) . The readme is below, VB 6.0 is the latest supported. That may very well be the cause the strange behavior

NI-488.2 2.8

[cmseguin]

Hmmmm. I actually pulled the references and code from your website. I found it in the examples found after installing ni488.2.

You can find the example here:

C:\Documents and Settings\All Users\Documents\National Instruments\NI-488.2\Examples\DotNET2.0\SimpleReadWrite\vb

[Anna_K.]

Yeah that is a good example for Visual Basic within .NET Framework 2.0, but that does not have anything to do with the version of VB language that is supported by VISA.

I expect we will develop support for newer versions however it is up to our R&D to decide on a time frame for that.

[gpibtester · Accepted solution]

I have not been able to recreate the errors that you are seeing. I have no explanation for why the ibdev and the subsequent calls fail with EPWR error if the computer never hibernated or went to sleep. Nor do I know why you are getting an Out of Memory Exception error.

However, in looking over the code snippets and NISpy report, one of the things that I am wondering about is in the subroutine Send - it instantiates a new Device every time it is called. Does your application communicate with more than one instrument?

If not, an application only needs to call ibdev (the call to New Device) once at the beginning of the application and then call ibonl (the call to Dispose) to take the handle offline before the application exits. So in Spy, any calls made to the instrument (except for ibdev) would show up with a Unit Descriptor called UD0.

In the bitmap, SystemMemoryError_RuntimeFailureSnapshot1.JPG, on Line 1652365 of the Spy capture, it shows the Unit Descriptor of UD73, which would imply that there are 74 instruments that the application is communicating with, which seems like a lot of instruments.

My only suggestion is for you to try is to change your application so that a call to New Device is only done once at the beginning of the application and that Dispose is called before the application exits. I've modified and attached the Simple Read/Write example to illustrate how to accomplish that. This is a list of the order of operations:

1. After selecting Board ID and the Primary and Secondary Addresses of the instrument, click on the Open button. This opens a handle to the instrument with the call to New Device.
2. The Write Read Loop button loops for 100 times doing the IDN query where it gets the identification information from the instrument.
3. The Close button takes the handle to the instrument offline (before you exit the application).

Hopefully this might help with the problems you are having, but then again, they might not as I haven't run into the problems myself.

gpibtester

[cmseguin]

Gpibtester,

You have found the same problem I found.  I was creating many "gpibDevices" unnecessarily. I did suround the portion of code with a using block and it worked great but doubled my cycletime. Your approach of creating the object once is better. I will do that.  Thanks for your help.

Chris.

[cmseguin]

GpibTester,

I tried to create objects only once for the pieces of equipment I use. I have 5 pieces of equipment so i made 5 new objects, ud0 through ud4. The problem is that there is no association with the ud and the GPIB address associated with the object/equipment. Your approach would work if I called the correct ud/GPIB combination but I'm not sure how to control that. I make hundreds of send/receives and the ud needs to match or the call will go to the wrong device, i think. 

An example:

create new objects

ud0 = gpibaddr1

ud1 = gpibaddr2

ud2 = gpibaddr3

send(gpibaddr1, command)  this makes another object and calls it a different ud#. Somehow I need to have an association between ud and GPIB. Can I explicitely address a ud#?

[gpibtester]

Chris,

With VB.NET, rather than passing in GPIB Addresses to your Send and Receive subroutines, you need to pass the GPIB object that was created with the call to New Device.

In the code snippet below, two different devices are created by calling New Device:

GpibDevice1 = New Device(0, 1, 0)

GpibDevice2 = New Device(0, 2, 0)

In the next set of code snippets, it shows how you can pass the GPIB object to the Send and Receive subroutines:

Send(GpibDevice1, "*idn?")
Receive(GpibDevice1)

Send(GpibDevice2, "*idn?")
Receive(GpibDevice2)

Here is an example of a Send subroutine that uses the GPIB object that was passed in to call the specified Device:

Private Sub Send(ByRef GpibDev As Device, ByVal str As String)

   Try
      GpibDev.Write(str)
   Catch ex As Exception
      MessageBox.Show(ex.Message)
   End Try

End Sub

Here is an example of a Receive subroutine that uses the GPIB object that was passed in to call the specified Device:

Private Sub Receive(ByRef GpibDev As Device)

   Try
      MessageBox.Show(GpibDev.ReadString())
   Catch ex As Exception
      MessageBox.Show(ex.Message)
   End Try

End Sub

Hope these code snippets are helpful.

gpibtester

[cmseguin]

Gpibtester,

Thanks. I ended up building 8 GPIBDevices only once and then calling them as required. This fixed the problem. Great idea.

Your input really helped me fix the issue. Again, Thanks.

Chris.

[gpibtester]

Chris,

Glad to hear that the calls worked for you! Continued good luck with programming your GPIB Devices!

gpibtester