Who do contact about a specific Labview Driver (Stanford Research SR785)

[jeff_scharpf]

Hello,
I'm not sure if this is the right place to go, but how would one find out more about a specific Labview driver if the manufacture doesn't provide support?
In my case, I have a Labview 8 driver for a Stanford Research SRS785. The driver works great except for one thing, and I'm trying to make sure I'm using it correctly. When I contact Stanford Research, they inform me that they cannot provide support as they did not write the driver.

How would I find out where the driver came from, where I can get more information, etc.?

Just for your information, the driver works in every method except for one. If I want to use the "Upload Capture Buffer" (GPIB command is "CGET") it doesn't seem to work and I'm not sure why. No matter how many data points I've captured (In my case, 2 channels at 64,000 points each), when I call the "Upload Capture Buffer" VI, it returns 256,000 values of what appears to be random numbers, but exactly the same for both channels.  Sorry for giving too many details.
All other driver functions appear to work just fine, as I've used it for other things.

I'm just wondering, from any LV developers, how you would go about finding the author and asking questions about a driver such as this?

Regards,

Jeff

[Dennis_Knutson]

I'm assuming you are talking about the driver that is available on NI's site? Then the author is someone at NI. At the download page, there is a 'Comments' link. The best forum for discussing drivers is the Instrument Control one. I'm not familiar with the instrument but if you wanted to try a little troubleshooting on your own, you might want to see what the programming manual has to say about the CGET command and what else may need to done prior to getting any valid data. The command being issued by the driver is CGET? channel#,mode and assuming that the channel number and mode are correct, the VI is returning something so it just may be a matter of doing some other inititialization to get valid data. A good way to debug instrument communication is with MAX. There you can experiment with the different commands and queries.

Just to add a little more, Stanford Research may not provide any support for the driver but they should support the instrument and remote programming. If you say you issue the command CGET? 0,0 and get garbage data, they should be able to tell you why. You don't even need to mention LabVIEW. The commands are the same with whatever programming language you use.

Message Edited by Dennis Knutson on 07-07-2006 07:48 AM

[jeff_scharpf]

Thanks Dennis,

Right now it does appear to be something with the SRS. When I use the CGET command even though I have the SRS configured for 64000 points, the response from the SRS is always that I have 262000 points. So it appears to be a firmware issue with the unit, but I'm just guessing. I will be contacting SRS.

It was strange, though, that the Labview driver tries to read 100,000 points at a time, until the buffer is empty.  I don't know if this causes errors when the buffer has less that 100,000 points.

Jeff

[Dennis_Knutson]

It's not strange at all. A VISA or GPIB read will automatically terminate when the instrument sends EOI and 488.2 specifies that an instrument will send this at the end of a message string. So, instead of trying to determine exactly how many bytes each response might return, it is normal to just specify a high number of bytes to read. The only time it would pose a problem is if the instrument does not assert EOI but you would see problems with all reads if that were the case.

[jeff_scharpf]

Thanks Dennis,

Yes I see now what you're saying. I've spent the day playing around with it and I think I have a temporary solution. The Labview driver works as it should. It brings the binary data in from this instrument. I wrote a short program to simply write that data to a file. Then I open up a program provided by the SRS company that reads the file and graphs/exports it.

My next goal is to try to eliminate the step of having to write to a file, and use another program to interpret the data.

All I have to do is remove the header from the data (I believe it's the first 77 bytes), then take the remaining array, and 4 bytes at time convert this to decimal numbers from the IEEE 754 standard. ( I am searching for a LV function for this but not sure if it exists to convert a 32 bit binary IEEE754 number into a float).

Thanks again for the help!

Jeff

[thehobbs]

Removing the header and formatting the data is typically something that the driver should do for you.  It is possible that this is not being handled properly in the driver, or that an instrument firmware change caused the data returned to be different, thereby breaking the driver code that formats it.  You should be able to remove the header youself and do the necessary formatting within the driver without needing to save the data to file.  You should look at some VIs in that driver to look for how similar instrument data is being handled.

If you find a fix, please submit it to to us at instrument.drivers@ni.com.  If you can't find a fix, let us know and we can try to assit you further.

[jeff_scharpf]

The driver in this case simply does what the SRS command specifies. The command is "CGET? x,x".  The first x is the channel number, the second x is a variable to determine which data, but is not important.

The instrument then replies with a 4 byte integer, which is the total count (number of bytes that must be read from the instrument). 
The labview driver sends this command, reads the # of bytes, then goes out to the GPIB and reads bytes until the buffer is empty, filling an array.

That's all it does. It does not do anything with headers. I see how it could. The data that comes in is all bytes. The first 77 bytes appear to be header information (after some experimentation). The driver doesn't care about this, it just returns everything. So in my opinion the driver is working fine.

My problem is interpreting the data bytes, trying to understand why I can't get the same number out of 4 contigous bytes that should represent a floating point number (IEEE754).

But this is not an issue with LV or the drivers.

Jeff

[Dennis_Knutson]

Have you looked at the Query Display Data VI? I don't know if the data returned is the same but that VI converts the bytes in the data string to DBLs. You might want to see whether the format of the data from the DSPB? query is the same as CGET?

[jeff_scharpf]

Yes, the Querey Display Data VI (and the command) reads the data from the display (what the instrument shows) not the capture buffer. The problem is that the display only shows a portion of the total buffer.

Jeff

[Dennis_Knutson]

I understand that. What I was pointing out was the Display Data function does a conversion from binary to floating point and you might be able to take hat part of the code and use it to convert the data from the capture buffer.