Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

RegisterGpibGlobalsForThread and debug error on Windows 7 (64-bit) using vb.NET (2010)

Solved!
Go to solution

Hi!

 

I'm currently writing code in vb.net (2010 version) to control various pieces of equipment with my NI PCI-GPIB card.

 

I believe I have the latest drivers (see attached screen shot of my Measurement and Automation screen).

 

What happens is that when I step through OR execute the program hangs at the RegisterGpibGlobalsForThread call    (this looks to be a function in the gpib-32.dll).  It gets called from my vbib-32.vb module, which I ported from the vbib-32.bas VB6 module that seems to be the only thing available at the moment.

 

I've tried a number of the solutions, from reinstalling drivers to building the entire solution, and each time I hang at the point where one of those gpib-32.dll functions get called.

 

I'm worried that the combination of VB.NET and Windows 7 in 64 bit are a little too new to be supported yet, especially since most of the test and measurement software that is developed previously doesn't seem to be an issue.

 

Any help would be most appreciated!

 

Thanks!

Jordan

 

 

 

0 Kudos
Message 1 of 14
(10,149 Views)

Slight update:

 

During debug I get the following message in VB.NET console:

 

"A first chance exception of type 'System.AccessViolationException' occurred in AnalysisRealTime.exe"

 

From what I can tell, this is most likely an API issue; my guess is the use of the gpib-32.dll or lack of 64 bit version.  But, I'll wait to hear back if anyone has seen this particular issue yet, or has any ideas on how to proceed!

 

Thanks in advance!

0 Kudos
Message 2 of 14
(10,143 Views)

Uninstalled every bit of NI software  and reinstalled with the latest Ni 4882 installation (version 3.0).

 

Still running into this crash when the gpib-32.dll RegisterGpibGlobalsForThread function is called.

 

It loooks like I'm passing null references into the arguments (code posted below) which may be the issue. 

 

First bit of code is where I start calling vbib-32 functions.  Yes, most of it is pulled from the example files.  The SendIFC function call is where the problem begins.

 

Private Sub scanGPIB()
        'Initialize bus and make the GPIB board the controller in charge (CIC)

        '  Your board needs to be the Controller-In-Charge in order to find all
        '  listeners on the GPIB.  To accomplish this, the subroutine SendIFC
        '  is called.  If the error bit EERR is set in ibsta, call GpibErr with
        '  an error message.
        Me.txtStatus.Text = "Initializing GPIB board"

        Call SendIFC(cstBoardAddress)
        If (ibsta And EERR) Then
            GpibErr("Error sending IFC.")
        End If

        Me.txtStatus.Text = "GPIB board Initialized."
        'Call and Listen to find devices on the bus
        Call FindDevices(cstBoardAddress)

    End Sub

The second part of code is the SendIFC call from the latest vbib-32 file, which I call in the first function above:

 

 Sub SendIFC(ByVal boardID As Integer)
        ' Check to see if GPIB Global variables are registered
        If (GPIBglobalsRegistered = 0) Then
            Call RegisterGPIBGlobals()
        End If

        ' Call the 32-bit DLL.
        Call SendIFC32(boardID)

        Call copy_ibvars()
    End Sub

Thirdly comes the RegisterGPIBGlobals function (also in the vbib-32 file):
 

Public Sub RegisterGPIBGlobals()
        Dim rc As Long

        rc = RegisterGpibGlobalsForThread(Longibsta, Longiberr, Longibcnt, ibcntl)
        If (rc = 0) Then
            GPIBglobalsRegistered = 1
        ElseIf (rc = 1) Then
            rc = UnregisterGpibGlobalsForThread
            rc = RegisterGpibGlobalsForThread(Longibsta, Longiberr, Longibcnt, ibcntl)
            GPIBglobalsRegistered = 1
        ElseIf (rc = 2) Then
            rc = UnregisterGpibGlobalsForThread
            ibsta = &H8000
            iberr = EDVR
            ibcntl = &HDEAD37F0
        ElseIf (rc = 3) Then
            rc = UnregisterGpibGlobalsForThread
            ibsta = &H8000
            iberr = EDVR
            ibcntl = &HDEAD37F0
        Else
            ibsta = &H8000
            iberr = EDVR
            ibcntl = &HDEAD37F0
        End If
    End Sub

The crash occurs at the line:

 

rc = RegisterGpibGlobalsForThread(Longibsta, Longiberr, Longibcnt, ibcntl)

Values for the arguments seem to be normally NULL when I begin, but I can't tell if the function can handle NULL or not.  I tried manually coding those to 0, with the same problem.  This may be part of the problem, just not sure how to isolate it from here.

 

Hopefully this will help someone tell me what is broken!  🙂

 


0 Kudos
Message 3 of 14
(10,137 Views)

And just to note, there are some differences in the syntax between the vbib-32.bas file and what I'm using, since I had to port it over to vb.net 2010 syntax before vb would compile the project.

0 Kudos
Message 4 of 14
(10,137 Views)

Well I should have realized the differences in data types when I tried to port.  Long in 64 bit systems is a 64 bit data width, where as in 32 bit sytems it is 32.

 

My guess at this point is that my conversion of the vbib-32.bas file was half baked; the data types are a much bigger issue than I expected.  I'll have to figure out a bandaid approach to handle data type discrepancies in the code rather than expect the gpib-32.dll to handle it.

 

Unless there is a 64 bit version coming out soon?  Hmmm.  All I hear are crickets... 🙂 

0 Kudos
Message 5 of 14
(10,135 Views)

Continuing this saga...  my apologies NI for seemingly turning this into a blog about my troubles writing code for vb.net 2010 and 64 bit Windows 7 🙂

 

So I resolved the 64 versus 32 bit issue, it seems, but am now running into some dll issues.

 

First, the 64b vs 32 bit issue resolution:

 

Since I'm using Windows 7 64-bit AND MS Visual Basic 2010 Express edition, I had to set the project to compile for 32-bit and 64 bit environments.  Windows 7 determines during runtime whether to run it as 64 bit or as 32.

 

To do this in VB 2010 Express, you have to:

 

1.  Go to Build > Configuration Manager > and set the Active Solution Platform to 'Any CPU'.  

 

If the Configuration Manager is not in the Build Menu, then you first have to go to Tools > Options > Projects And Solutions > and then click the checkbox for "Show advanced build configurations".   Configuration Manager should now show up under the 'Build' menu.

 

In the Configuration Menu, if 'Any CPU' is not available, you need to add a new platform.  Click on 'New' in the drop down box and the select 'Any CPU' from the drop down.

 

Rebuilding and running the program got rid of the first issue it seems; at the very least I'm getting a different error message now!  Can I call that progress? 🙂  So now the issue that is occuring seems related to a number of other boards on this forum, but it seems I'm stuck after trying a number of things suggested.  

 

Firstly, the error message is now a "A first chance exception of type 'System.DllNotFoundException' occurred in AnalysisRealTime.exe".

 

This happens at the same call, where the gpib-32.dll functions are called.  I've tried a number of things at this point, such as regsvr for the drivers (where I get a third error message (see attached file since MS won't let me highlight error messages to cut and paste).  Trying to add a reference to the gpib-32.dll file gives me errors, although I would have thought the ni4882 reference component would handle it.  

 

The worst part is that the Measurement and Automation software seems to be working perfectly!  Not sure exactly what that means, since it should indicate the NI drivers are working properly.

 

I'm wondering if somehow I have an old vbib-32.bas or niglobal.bas file, despite uninstalling and reinstalling the NI software a number of times.

 

0 Kudos
Message 6 of 14
(10,123 Views)

Jordan,

 

I see you have been busy. Sorry I did not catch this post earlier. I have a few points that may clear some things up here then we can move forward from there.

 

The gpib-32.dll is a 32-bit only DLL (hence the title). So you cannot build a 64-bit application using it. I .NET you have the option of choosing Any CPU which, like you said, determines it's bitness at runtime. This should allow your program to work on a 32-bit system, but not a 64-bit system (assuming it lets you compile, I'm not sure if Visual Studio will notice you are using a 32-bit library). So instead you have a few options:

 

  1. Compile your application as x86 so that it will always run as a 32-bit application, even on a 64-bit system. This should be the simplest method if you are trying to port your existing app because it won't require any code chanes.
  2. Switch to the ni4882.dll instead of gpib-32.dll. This is the newer driver API that includes support for 64-bit applications. This will require some, but little code change.
  3. Switch the the NationalInstruments.NI4882.dll assembly which contains the .NET API. This is probably the best approach for .NET because it is a simpler API to use. However, it will require significant code change because it is using a class library instead of the standard C style library. This is also 64-bit and 32-bit compatible.

The other advantage is to switching to the newer APIs is that they provide better help and examples.

 

Also note that some NI GPIB devices are not supported on 64-bit. Namely our PCMCIA and legacy TNT devices. See the NI-488.2 Readmen for more details.

National Instruments
Message 7 of 14
(10,121 Views)

Hi D!

 

Thanks for the response; it is much appreciated.

 

When using the ni4882.dll, do I need to make changes in the vbib32.bas file (or in my case the vbib32.vb)?  I know it specifically calls out the gpib-32.dll in the function declarations, hence my exercise following the gpib-32.dll down into the rabbit hole.

 

I had called out the .NET references within the project, but it didn't seem to make any difference.  I was also compiling for x86 in the beginning but changed over to the Any CPU setting.  However, now it makes sense that I can't compile it for running on 64 bit with it.

 

I'll try starting over again tomorrow from scratch using the ni.4882.dll assembly again and read through the API documentation more thoroughly in preparation (if you have the best link to this information please post it; I seem to find all sorts of neat stuff and later find out it doesn't apply or is out of date).  

 

Thanks again for the help; hopefully I get unstuck tomorrow. 🙂

0 Kudos
Message 8 of 14
(10,119 Views)

Si vbib32.vb your application? If so, yes you will likely need to make code changes. It may be as simple as replacing the GPIB function calls, or it may require architecture changes depending on what your project looks like. I would start by looking at the examples that ship with the driver. There is also some valuable information contained in the Measurement Studio Help.

 

Here is a KB article that explains a little more about some of the options for .NET.

http://digital.ni.com/public.nsf/websearch/4043FBAE3E3CBD3386256D9600538319?OpenDocument

 

National Instruments
0 Kudos
Message 9 of 14
(10,110 Views)


Hi D,

 

No, actually the vbib32.vb is a port of your vbib32.bas file since it won't compile in .net 2010 without errors.

 

I guess the question is, how do I call the NI4882.dll functions from within my VB program, if the gpib-32.dll module is not the latest and greatest?

 

Also, what version of the 4882 driver should I install?  I've tried 3.0.0 and 2.8.1 installation files, but they all still reference the niglobal.bas and vbib32.bas files, which in turn need the gpib-32.dll in order to function correctly....

 

Best Regards,

Jordan

0 Kudos
Message 10 of 14
(10,107 Views)