How to read the configuration of a FXP number via property nodes or other methods.

[AristosQueue (NI)]

---

Alias name here wrote:Am I asking too much ?

---

Even if we had the scripting API, I do not think it would help you at all.

I think you are asking too much *unless* you have a *single* fixed-point data type that you're wanting to store/retrieve.

If you are wanting to store a single type, then flatten to string/unflatten from string works to preserve your data. The string does not record anything other than the value, but that's ok because you're only working with one bitness/encoding/etc, so there's no need to write that stuff down (at least as I understand FXP).

But I think you're wanting to store an arbitrary FXP data type, presumably coming from one of several different front panel that are all different FXP configurations, and then load that data into a single panel that you reconfigure for the bitness/etc that you read from the file. That's how I've modeled your question in my head. Even if the scripting API existed, I don't think it would serve your purposes. You wouldn't be able to use it in any deployed applications (built EXEs, real-time targets, that sort of thing). Changing the data type of a control requires recompiling the VI. You could not change the type of a VI that was already running. What it sounds like you're attempting to write is something that would handle these values in a highly generic-not-specific-to-any-single-FXP-format way, and LV just doesn't do that kind of loose typing.

If all you need to do is display the data then you can use Flatten To String to save the data and then unflatten it *as a string* not as a numeric. But if you want to manipulate it, I cannot think of a way to help you.

[nathand]

---

Alias name here wrote:

The simplest way to do this is to store the number plainly as FXP and then display the FXP...Am I asking too much ?

---

I'm really trying to understand what you're hoping to do here.  Is there some situation in which you expect to use one fixed-point format when you write the value, and a different format when you read it?  Otherwise, I can't see the issue with a direct conversion to a string.  You'll supply the appropriate type as the default value when you read it, and it will work.  The only risk is that you don't write it out with enough precision.  If I've misunderstood somehow, though, could you try to clarify?

[nathand]

---

Alias name here wrote:

There are several very specific type of FXP and converting without corruption is not simple. Read this NI white paper:

http://www.ni.com/white-paper/9221/en

 

Regards (been programming in LV for +23 years)

---

Might be time to teach the old dog some new tricks, then   That white paper says nothing about losing precision when converting from fixed to floating point, and in fact provides the algorithm for doing the conversion correctly (although LabVIEW already provides built-in functions for this).

A single-precision float has a precision of 24 bits and an exponent of 8 bits, so any unsigned fixed-point value of 24-bits (or signed value of 25 bits) or less can be precisely represented as a single-precision value so long as the number of integer bits is between 128 and -125 (if I'm not mistaken, this range does not extend through -127 due to the definition of Not a Number values).  It is completely valid to have a fixed-point value that has negative integer bits, or more integer bits than the width of the value.  You can compute similar limits for a double-precision float which has a precision of 53 bits and an exponent of 11 bits.  Within these limits the conversion between fixed-point and floating-point is both simple and safe.

Now, as far as reading that value back into a fixed-point: you MUST know the fixed-point representation at the time you read or convert it, because LabVIEW is strictly-typed.  There's no getting around this.  Knowing the format in which the value was stored at the time it was written will let you confirm that you're reading the same type that you wrote, if for some reason that's necessary, but the result of the conversion (I'm thinking here from a fractional/exponent string since that's a human-readable representation of a fixed-point value) will be whatever representation you provided as a default value.