is it a bug or just a typo in Agilent 532XX Series\Public\Data\Low Level\Fetch Measurement (Single).vi?

[CQ_Li]

Hi, All

I am using Agilent 532XX Series driver to read data from a frequency counter. In the low level subVi : \Public\Data\Low Level\Fetch Measurement (Single).vi, "Scan From String"  is used to convert the data.

however, if I check the error of this function, it always show me a error with current format string "%.;%g;". after I changed it to "%;%g", I don't get the error anymore. 

If anyone use this funtion, please check the error out of that fuction and see what you get. 

Regards

[ChrisStrykesAgain]

I don't have the instrument, so I can't reproduce it completely, but I've done some research and if there is an error I don't think it's in the string conversion itself. I say this because:

From what I can gather, a typical output string would be the following: +4.27150000E-03

I took just a "scan from string" node and gave it that string as a string input and %.;%g; as the format specifier string. This yielded a numeric value of 0.0042715

So, as far as actually finding the root of the problem, there could be a few things going on. My first thought is some form corruption causing the data received to not be valid for conversion. There are two ways of testing this:

Open up a test panel in MAX and perform a loopback test, as described here: http://www.ni.com/white-paper/3450/en/#toc4

-or-

Install and open NI IO Trace and view the bus traffic as detailed here: http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9

If the loopback tests works properly, go ahead and run the IO trace and post the results here.

[Dennis_Knutson]

The period is there to force the conversion to use a period as the decimal separator instead of whatever the local setting is. Simple as that.

[ChrisStrykesAgain]

Just in case you were wondering about any of the syntax in the format specifier string other than that period, this document explains it in detail:

http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/format_specifier_syntax/

[JÞB]

---

@Dennis_Knutson wrote:
The period is there to force the conversion to use a period as the decimal separator instead of whatever the local setting is. Simple as that.

---

So, since the silly boys over at Agilent went and allowed the FORMat:DATA command. what you have is a bug and you should use this vi only when FORM:DATA? returns "ASCii,15"

Luckilly a *RST will put the device in that default condition.