05-23-2014 04:03 PM
Hello all,
We are trying to do a short-term frequency measurement using the SR620 (Frequency Counter) via a GPIB-USB connector. We are trying to understand how the GPIB commands work, and it seems that normally you send a query and then ask it to read what the instrument is saying. However, since we are trying to do a short-term frequency stability measurement, we are using the Binary Dump (BDMP - explained in the manual, link below) command. To read this data, you do not use the standard read function, you use this process called Direct Memory Access (DMA). The maual talks about DMA, and the example code in the maual seems to use DMA to read the resulting data.
We have been able to trigger the "binary output" display on the instrument using both LabVIEW and the Interactive Control through NI-MAX. The question now is: How do we implement DMA using LabVIEW? More specifically, how do we implement DMA reading from the SR620. There does not seem to be anything close to it in the LabVEIW included code. There are examples that use DMA with IVIs, but we have had difficulties modifying them to work with the SR620 code.
Useful links:
Manual for SR620: http://www.thinksrs.com/downloads/PDFs/Manuals/SR620m.pdf
Possible DMA example??: https://decibel.ni.com/content/docs/DOC-9893
DMA explination: http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgaconcepts/fpga_dma_how_it_works/
Way to make DMA: http://www.ni.com/white-paper/4534/en/
Note: When we haven't gotten past step 1 because we have issues adding a new FPBA Target because there are "<no items found>"
Solved! Go to Solution.
05-23-2014 04:13 PM
05-25-2014 02:55 PM - edited 05-25-2014 02:56 PM
Yeah, back in '89, you probably did need to use a DMA to store the data quick enough. Things have gotten a lot faster in 25 years. What I have done for somehting similar is save the data to a file as it is being read. If you need further performance, use a Producer/Consumer.
05-26-2014 10:18 AM
Thank you both!
Crossrulz, that fixed the DMA issue nicely.
Now I just need to format and convince the freq counter that I wants to tell me everything it knows. 😛
05-27-2014 02:57 PM
In further looking into this operation, I have found that (especially for larger dumps), there is a significant change in runtime that depends on the byte count you input to the VISA Read function. I am not entirely convinced that we are not missing data with this operation, but there is no good way to check. There is a 256 bit buffer that is present, even for binary dump. Here is the data I took.
Parameters, Same for all runs | |||||
Timeout (ms) | 180000 | ||||
Number dump points | 65535 | ||||
Gate Time (s) | 1.00E-06 | ||||
Byte count for VISA Read | 4194240 | 50000 | 500 | ||
Elapsed time (ms) | 301,989 | 420,846 | 427,352 | ||
Note: tick count was placed on the error wire directly before and after the while loop, and the elapsed time is the difference between the tick counter |
I have attached code for my testing setup as well as a suggested alternative that involves calculating the number of bytes that need to be read exactly.
05-27-2014 03:44 PM
One thing you should do to speed up your loop function is to preallocate your array. Use Initialize Array with the data type a U8 and the number of elements set to the number of requested readings multiplied by 8 (64 bits per reading). Then inside of the loop, use Replace Array Subset. This will keep you from constantly allocating memory to expand your array.
05-27-2014 03:47 PM
Would looping and reading the data in smaller bits (assuming I preallocate the array) be faster than reading it with one command?
05-27-2014 07:34 PM
If the buffer and timeout can handle it, go with the single call. I'd be surprised if the buffer can handle it though.