Arithmetic overflow from ibdev32 (need new dll?)

[Woman Driver]

Hi -
We purchased a 3rd-party alignment system from Newport (Integra) that requires .NET, but it looks like most of the libraries they included are vB 6, including GPIB-32.dll (used by the prior Newport versions, called PCS). References to this library and interface code are in a module provided by Newport called macro_vbib32.

When I access a device with a call to ibdev (code in macro_vbib32), it bombs with an arithmetic overflow from the ConvertLongtoInt (actual line of code is ud = ConvertLongToInt(ibdev32(bdid,pad,sad,tmo,eot,eos). Looks like the value passed to ConvertLongtoInt is larger than expected (approximately 14 digits), such that when it subtracts 32767 it's still too long to convert.

Do I just need a new GPIB-32 library and if so, how do I get one (no response back from Newport!)? Or is the problem accessing the device, and I am getting back a bad descriptor?

Thanks!
Beth Karlin
bkarlin@teledyne.com

[Robert M]

Hi Beth,

I'm curious as to why that value is being converted.  ibdev32 returns a 32 bit integer.  What is ConvertLongToInt expecting?  Why does the value being returned by ibdev32 need to be converted?  If there is no valid instrument ibdev32 will return a -1.  How would ConvertLongToInt handle a -1?  These are questions probably better suited to Newport.  You may want to pass them on.

I don't think an updated version of the dll is going to change anything, but you are welcome to download the latest GPIB driver, which includes an updated dll.  The latest version in NI-488.2 2.4.

Hope this helps,

[Woman Driver]

Robert -
Thank you for your prompt response and pointer to new library. I will try it and see what happens. With respect to your question:
It looks like the GPIB code Newport provided is a high-level wrapper to insulate the unwary against direct NI calls. I thought they might be routines provided by NI, but your reponse make me think otherwise. The routine in question is called OpenGPIBDevice. It passes ud as a short to ibdev (your ibdev or Newports?). Ibdev checks for registered GPIB globals, calls ibdev32 from the dll, then uses ConvertLongtoInt to convert the resulting ud back to a short. ConvertLongtoInt (Newport's or NI's?) looks like the largest value it expects is 64K, as it subtracts 32768 and then ANDs the result with H8000.

Now, either the address returned back from ibdev32 is invalid (should this really be a 14-digit number??), I have something badly formatted in my call, I need the new library or ConvertLongtoInt is inappropriate for .NET.

I'm going to try bypassing the high-level entirely and just use ibdev32, ibwrt32 and ibrd32.

Any more thoughts/info would be appreciated.

Thanks!
Beth

[Robert M]

Beth,

ibdev and ibdev32 are National Instrument's and OpenGPIBDevice and ConvertLongtoInt are Newport's.  I'm not sure why ConvertLongtoInt subtracts 32768 and then ANDs it with H8000.  What do you mean by the parameter being returned from ibdev32 being a 14-digit number?  How many bits is it?

[Woman Driver]

Robert -
The value I got back from ibdev32 was, consistently,
8975933078237116952. I initialized ud before the call just to make sure I didn't have leftover garbage. Although I am now past the problem (see below), I am still curious as to whether this was a valid address to begin with, or an anomaly from the Newport call to ibdev.

I now have something that works! Once I realized from your email that the high-level stuff was Newport's, I searched for and found a National Instruments .NET directory with sample GPIB code for a power supply. It imports National Instruments.NI4882 and the dll langint.dll. It then directly calls ibdev, ibonl, ibwrt and ibrd, all of which work beautifully! I think Newport just did not provide complete .NET support, but I can't confirm since they have not responded to my voice or email messages for 2 weeks! Thank you, Robert, for being so responsive and helpful! You're a credit to National Instruments!

Once I got the code working locally (from the development studio), I found a back door to "force" the Newport Integra software to use the import and dll (if anyone else has this problem, the issue is that Integra controls the build, as user code runs as a single sequence under Integra. The sequence builder allows only a .vb source, not a solution. I found the build.bat that Integra creates, hardcoded the import and dll reference and manually built the exe).

Thanks again!
Beth