How do I change precision of a number sent to a device in the NI drivers?

[Improbability]

Hi,

I was wondering if you guys could help me out. I have an HP 8648c signal generator that I'm interfacing with over GPIB and I'm interfacing the GPIB with the C/C++ drivers that NI has provided. Since I'm controlling multiple devices, I'm using generic GPIB driver files(ni488.h tgpib.c tgpib.h and the .obj file that was provided).

I want to send a value like 1.48001003 E +09 across to my device. However, the actual value that appears on the bus as captured by NI Spy is 1.48001 E +09

I'm wondering if there's any possible way to increase the number of decimal places sent across to my device.

Thanks in advance.

[Dennis_Knutson]

This is really a LabVIEW question and it depends on what function you are using to create the string. Number to Exponential String has a precision input and you just need to use the correct format string (i.e. %.8e) with the Format Into String.

All of this is explained in the LabVIEW help.

You'll want to first verify that the instrument will accept such precision.

Message Edited by Dennis Knutson on 06-10-2009 10:40 AM

[Improbability]

Yes I'm aware that this issue has come up before, typically in the LabView environment but I'm not using LabView.

In C++ I am simply putting together a string, which I have verified through the debugger that it does contain the values that I want to send.

To write to GPIB, I call the function ibwrt.

The command string that I pass to ibwrt appears as:

FREQ:CW 1550.0005 MHz

Now in NI Spy this appears as:

FREQ:CW 1550 MHz

If I type my command string into MAX, it will work. So the device does accept that precision. There is just some difference between MAX and my c++ code that I can't find buried in the NI driver code.

[Dennis_Knutson]

Sorry, I missed the fact that you were using C++. Are you using the driver or directly calling ibwrt?

[Improbability]

I'm directly calling ibwrt.

Bit of a messy issue isn't it?

I've looked in ni488.h but I couldn't find anything that I could distinguish as the problematic value.

To my knowledge, the drivers for my equipment do not exist.

Message Edited by Improbability on 06-10-2009 03:00 PM

[Dennis_Knutson]

Well, a driver exists for the a model. I don't know how much you can use.

Since MAX calls ibwrt and your program calls ibwrt, I don't understand where the problem could be. I'm going to assume that you are determining the byte count count correctly.

[Improbability]

I went and checked to make sure that there were no issues with the byte count or the command string having space characters in it. Everything checks out perfectly.

There's something going on behind the scenes and I don't know what. Somewhere my command is being reparsed. I just don't know where.

I checked out the drivers for the 8648a but I don't have access to LabView or Lab Windows right now so any files just appeared as jibberish. Unless I can get some source code out of those files with the propper program, I don't think they'd be of much use anyways.

[Dennis_Knutson]

You're correct about the driver. I did not open the zip file and did not notice that it does not include the dll that is typically created.

I wish I could be of more help. I really don't understand why the same function would work differently.

[Steven_T]

Hello Improbability,

I would recommend getting a spy capture of both the working (MAX) interaction as well as the non-working (non-MAX) interaction.  Please post the actual spy file.  By checking the buffer of both captures, we should be able to determine what is actually being passed to the ibwrt function.  There are no places below this ibwrt call where code is being reparsed.

This would actually implicate that the string being sent to the ibwrt is actually changed somewhere in your code.

I hope this helps,

Steven T.

[Improbability]

Hi Steven,

I've attached my Spy capture files. Included in the capture of the call made by MAX are the details of the device from the IDN query...might be useful.

However, I believe I've solved the problem by fluke. I ramped up the precision on my conversion to a double value from 9 to 12...you would think 9 would be enough but I guess not.

I guess seeing how people solved this problem by changing a value in the NI device driver sort of put me on to thinking that there was something somewhere in my generic driver that i had to change.

Anyways, thanks for all your help guys.