sr830 Fast transfer mode hangs up

[weitong]

Anybody solved this problem? I am struggling on the fast reading SR830, too. I wish to have 200 or more readings per second from SR830 to computer.

WT

LV2013

[JÞB]

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

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

[weitong]

Thanks for reply.

I am using NI USB-GPIB-HS to access Lock-in SR830.

Here is my code snapshot. Attached please find the vi file by LV2013.

By chance, now I can continously take data with the 256Hz sample rate setting for a while. With 512Hz sample rate setting, the program corrupts very quickly.

The second thing is: In the production program, I have two parallel loops. One is for taking data from SR830 through GPIB, the other is for taking data from a device xxx through TCP/IP.  If there is only the device xxx reading loop running, its data tranfer speed can go up to 200 readings per second. Once the SR830 reading loop and the device xxx reading loop run simutaneously, the device xxx reading speed drops down very much (less than 50 readings per second), while the  SR830 reading loop keeps reading speed, say 256 readings per second. 

My PC is running Win7 32bit with i5-3470 CPU.

WT

LV2013

[JÞB]

Thats an easy fix

"FAST\s2" defaults to FAST1  remove the space so you actually have a buffer.  Then start using it by reading 32 or 64 bytes at a time.

[Minions]

Why are you only reading 4 characters per reading?  How many are expected to be in the buffer?  You could read all buffer data then split it accordingly.  Also, try to perform all math functions outside of a loop if they are not dependent on the loop.  Try other functions as some may work better for your application.

[JÞB]

---

@Minions wrote:

Why are you only reading 4 characters per reading?  How many are expected to be in the buffer?  You could read all buffer data then split it accordingly.  Also, try to perform all math functions outside of a loop if they are not dependent on the loop.  Try other functions as some may work better for your application.

---

With the Typo in the string constant- there is no buffer (FAST1 mode) 4 bytes at a time is the only way it could transfer anything

[weitong]

Sorry, I cannot get what you are talking about the 4 bytes  reading. I am reading 4 characters per reading because they are one pair of XY values. Why am I not reading 16 or more bytes once? Because my silly thought was to get Lock-in (XY) values pairing with magnetic field reading for plotting.  Each time one field reading and one Lock-in (XY) reading. If I get a bunch of XY per reading, then I don't know which XY corresponding to which field.

I have field reading loop parallel with Lock-in (XY) reading. I don't know why the field reading loop  gets slow when I start Lock-in (XY) reading simultaneously.

I tested "FAST2" and "FAST 2", they seems to have no difference on my reading. Still corrupt with "timeout expired" error. Does this error mean I am reading too fast or too slow?

Thanks!

WT

LV2013

[IvanRyger]

According to people from Standford Research we had an issue with speed of iteration of my VI (very similar code, though). If the host PC is diverted for a very short period of time, the SR830 automatically turns off the FAST2 transfer mode and the instrument again listens on the bus.

When I shut down the Ethernet communication (basically, computer unplugged from the network) the problem disappeared. However, speeds about 128 samples per second were challenging. You have to set the highest priority to the VI containing the comm loop.

In my code I had two concurrent loops and instead of taking only 4 bytes at a time I took a chunk of 32 bytes (4 four-byte measurement samples) passing the data to the second loop through FIFO. Reading a larger amount of data at once will give your computer more room to keep the critical loop timing.

The second loop was reading FIFO with minimal post-processing and immediate data saving into binary file. This allowed me to go past 256 samples per second. However, reliability is questionable, since we finally did not use such a high transfer rates.

remark: as far as I remember, the maximal internal buffer size of SR830 is either 63 bytes or 63 measurements

One thing I did not try was to put all the time critical operations into one VI with time critical priority, passing the data to some slave VI through a FIFO queue.

[JÞB]

Inline the vi.

Automatic Debugging can really mess with compiler optimisations.  Once all those debugging hooks are gone, performance can seriously improve.

[weitong]

What is Automatic Debugging?

---Thanks to all of you. I will try more later when I finish the other work in hand.