sr830 Fast transfer mode hangs up

[Ivan_Ryger]

Dear colleagues. I am preparing a software for noise measurement in Labview. I encounter this problem:

When I switch the instrument into FAST transfer mode for windows (the Instrument becomes a talker and host computer is a listerner), the instrument starts sending data over GPIB.

The short description of FAST mode is here SR830 FAST mode, and the data transfer is described in SR830 manual between pages 97-103.

However, at high data rates (>=128Hz) it hangs up even after few hundreds of samples taken, the number of samples vary.

I get the timeout error from VISA read. The VISA read function is set to synchronous reading. Without this setting, I cannot achieve higher data rate than 128Hz.

The cable between PC and Instrument is roughly 2 meters long, so I think this does not cause problem.

[BvanG]

Hi Ivan,

How many bytes of data do you need to read in at a time? Since you’re getting a VISA timeout error, I’m thinking that not all of the samples are being read. Lowering the number of bytes to read at a time may help.

Secondly, what version of the VISA driver are you using? The VISA Read VI inside the top while loop looks that it may be from an older version. Have you tried replacing the VISA Read VI?

[Ivan_Ryger]

Dear BvanG. 

I tried the VISA read taking only one sample (4bytes). It hang up even sooner, after few iterations. Taking block of 32 samples, it started ti be more reliable as the software has enough time to buffer them. 

Where can I found the version number of VISA? I am using Labview 2015. I did not see a newer version of VISA read routine in my list of functions. 

When talking about Visa read, I tried to replace it with GPIB read. It worked pretty much the same way. Hang up randomly after some iterations.

Thank you

Ivan

[BvanG]

Hi Ivan,

To find what version of VISA you have installed, you can open NI MAX, expand the software tree, and NI-VISA should be listed towards the bottom. My software reads “NI-VISA 15.0”, indicating I have VISA 15.0 installed.

What instrument are you using? Is LabVIEW hanging and becoming unresponsive, or are you just getting the timeout error? When the data is done being sent, is the instrument sending the proper termination characters so the computer knows it’s done?

[Ivan_Ryger]

Dear BvanG,

exactly, my VISA version is 15.0.  I am using Stanford Research SR830 Lockin amplifier. In the read loop, the host controller works as a listener and the Lockin is talker. Each time it gets a data sample, it should transfer it immediately to the host controller. When the communication hangs up, I get only timeout error. Labview does not stop. The instrument does not send any termination characters as it is set to the fast transfer binary mode. It is sending just data "packets" of constant length- 4bytes per sample.

The manual says:

"The FAST2 version uses the lock-in transmit queue to buffer the GPIB data being sent to the host. Since the transmit queue can buffer a maximum of 63 X and Y data pairs, the host can only be diverted for short periods of time (e.g. 120mS at 512Hz sample rate) without causing the lock-in to "time out" and abort the FAST mode data transfer. The values of X and Y are transferred as signed integers, 2 bytes long (16 bits). X is sent first followed by Y for a total of 4 bytes per sample. The values range from -32768 to 32767. The value ±30000 represents ±full scale (i.e. the sensitivity). Offsets and expands are included in the values of X and Y. The transferred values are (raw data - offset) x expand. The resulting value must still be a 16 bit integer. The value ±30000 now represents ±full scale divided by the expand factor. At fast sample rates, it is important that the receiving interface be able to keep up. If the SR830 finds that the interface is not ready to receive a point, then the fast transfer mode is turned off. The fast transfer mode may be turned off with the FAST0 command. The transfer mode should be turned on (using FAST1 or FAST 2) before a scan is started. Then use the STRD command (see below) to start a scan. After sending the STRD command, immediately make the SR830 a talker and the controlling interface a listener. Remember, the first transfer will occur with the first point in the scan. If the scan is started from the front panel or from a trigger, then make sure that the SR830 is a talker and the controlling interface a listener BEFORE the scan actually starts. STRD After using FAST1 or FAST 2 to turn on fast data transfer, use the STRD command to start the scan. STRD starts a scan after a delay of 0.5 sec. This delay allows the controlling interface to place itself in the read mode before the first data points are transmitted. "

I have PCI to GPIB card from NI installed.

It seems that the reading procedure is not able to keep up with the instrument sending the data.

[BvanG]

Hi Ivan,

I disagree with your last statement. If LabVIEW were unable to keep up with the instrument sending data, you would receive a buffer overflow error or would be missing samples. Typically, VISA Timeout errors only occur when VISA is expecting to read more data than it is receiving.

From the information you've provided, I think the instrument might be diverted, causing it to stop sending data, which then causes the VISA read error. If you believe there should be more data being sent after the VISA timeout is currently occuring, you can put an infinte timeout (-1) on the VISA Read VI. This will cause the VISA Read VI to never time out.

We have a driver for the Stanford Research 830 Lock-In Amplifier, linked below. This may provide more built-in functionality for your application, instead of using VISA commands.

Instrument Driver Network - Stanford Research 830: http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=1536

[Ivan_Ryger]

Dear BvanG, 

thank you for this link. However, I have already been using this driver. It does not contain FAST data transfer function.

[JÞB]

I hate to tell you this but, you are using FAST2 incorrectly.

Read smaller chunks of data.  (like 16 or 20) something divisible by 4 so yo get full XY pairs.

The internal buffer is 128 bytes so what you are doing is waiting for it to get full then dumping the whole thing.  if there is any delay you timeout the device FAST2 mode.  Reducing the reads to 16bytes will let the timing flucuate a little and catch-up when windows gets back to your thread.

EDIT: I got spoofed into a old thread  I'll split this.  

@ Ivan what does your code look like and what hardware do you have?