bf
New Member
Posts: 3
|
Post by bf on Apr 7, 2021 6:16:24 GMT -5
Hi Folks, I just received a F71 for tests. I communicate via ethernet in "C++", no problems so far. To read the field I use 'FETCH:DC? ALL", and parse the answer int B_abs and the 3 components. The issue is if I read too fast (repeatedly) I have around 4-6 strictly identical readings, before it sends a new one. I understand that there is a N x 10ms averaging, thus within 10ms I have the same reading. I did deal with some voltmeters, which make a distinction between "fetch" and "read". The latest makes sure you have a new reading, while fetch just fetches the buffer. Is there a way doing so with the F71 other than programming a wait? ( wait is not too elegant, it will depend what was programmed for the averaging window and the exact timing...)
Thanks in advance to point me in the right direction.
BTW: the SENSe:AVERage:COUNt? returns me "1" while the manual states the default 20. I do send a *RST at startup but it stays at 1.
|
|
bf
New Member
Posts: 3
|
Post by bf on Apr 9, 2021 2:48:23 GMT -5
Anybody here from LakeShore? I have only 2 weeks to test this gaussmeter, after we need to decide to buy or return...
BTW I tried to add *OPC? at the end of reading but did not change anything...and I do get the answer "1" from *OPC? I also tried to clear the buffer with FETCh:BUFFer:CLEar, but again no effect...
|
|
|
Post by Lake Shore Jeff M on Apr 9, 2021 6:55:09 GMT -5
The value retrieved by the fetch command is not updated at the same rate as the averaging window as it is not intended for high time resolution data acquisition. For applications that require high data rates we created the data streaming feature. A good app note featuring the data streaming feature can be found here: www.lakeshore.com/docs/default-source/product-downloads/fast-magnetic-field-mapping-with-fp-series-teslameters.pdf. Since you are programming in C++ you will need to do some work to parse the string returned by the FETCh:BUFFer:DC? query. There is an example of how to do this in our public python driver repository: github.com/lakeshorecryotronics/python-driver/blob/b650f810afc5ab45801caa1d01b793c0739fb41c/lakeshore/teslameter.py#L107. Note that the data streaming buffer will store up to 128 points. The shorter the averaging window the more often the streaming buffer must be queried to avoid losing data. For example the buffer should be queried about every 0.5 second if the averaging window is 10 ms but only needs to be queried every 5-10 seconds if the averaging window is 100 ms. I’m not sure why the *RST command is not resetting the averaging window. This may be a bug on our end. I would recommend you try using the SYSTem:PRESet command for now.
|
|
bf
New Member
Posts: 3
|
Post by bf on Apr 9, 2021 9:37:46 GMT -5
Hi Jeff, thanks for the answer! This explains. I have seen the buffer reading feature, no problem to parse the answer, and I also read a previous discussion on it on this forum.
If I can still profit of your knowledge, do I have mean to figure out how frequently can I call FETCH:DC? ALL to make sure it has a new reading? (I can read the averaging window setting if it depends on it..)
To explain what I am after: Sometimes we would like a more smooth, stable reading, thus I can make say N readings and average it after. This is not intended for high speed reading to see time dependence. We mostly deal with very stable Dc field in current driven coils. It is rather to have the most noise free reading possible.
all the bests
Bela
|
|