VIM and units

[X___]

I understand that NXG dropped units, is bug free and makes programming easy for those who will still need to program when it will be finally ready.

Not that I could care less, but VIM, which were introduced in ODG (old gen) are challenged by them (this is of course not the only problem with units, but VIM being recent, this problem is).

Take the scalar to string.vim that comes within vi.lib\Utility\Debug Log.

If you feed it a numeric, it will work fine and spit out a string reflecting the value fed in.

If you feed it a numeric with unit, it spits out garbage, as the cases in the VIM do not know how to handle units.

Instead of treating the culprit as a "all other types not handled by the first few cases", it recognizes is as... a timestamp:

 

The point is not so much that scalar to string.vim doesn't work as expected, but that you need to take this into account if you are writing VIMs and plan on using them with scalars with units (or any structure containing those), as they will not be recognized by the cases you will have written for scalars (which is how I discovered the problem).

Some will say: well, obviously, since a scalar with unit is a different type than a scalar without. Shall the all-knowing among us be praised!

I will argue that:

- since VIM will in general have a garbage collection case, a scalar with unit might look like it is treated correctly by a VIM you do not check the internals of, but in fact will spit out garbage. Could be tricky to debug.

- units are part of ODG, and the current VIM concept doesn't make it easy to handle them generically. Is it an easy thing to do? Maybe not.

Anyway, programmer beware.

[Darin]

VIMs are not the actual culprit here, rather the Type Assertions (or lack thereof).  A double with units will fail the Assert Floating-Point Assertion test.  This may or may not be a bug.  In the absence of a separate assertion for floats with units, it probably is.  

The second assertion failure occurs in the Scalar to String.vim itself.  A double, with or without units is a perfectly acceptable input for a timestamp format string.  Unless you add an assertion in the timestamp case, there will be no broken wires, and voila, your DBL with units is interpreted as a timestamp.  I see no reason not to Assert that value is a Timestamp in the Timestamp case, since you already preferentially decide that DBLs should be handled with Number to Fractional String.

A little Edwin Starr:

Units, huh, good God
What is it good for
Absolutely nothing, listen to me…

[crossrulz]

So what I am gathering here is that the Assert Floating-Point Numeric Type.vim does not work with units.  Otherwise, it does look like the timestamp case for the Scaler To String.vim is the first one that would work with a numeric, even with units (just feeds into a Format Into String).

 

I'm so glad I gave up on using units ~13 years ago...

 

EDIT: Daren posted right when I was about to hit "Submit".

Edited January 9, 2020 by crossrulz

[X___]

These comments are all right. Most users will only see the VIM though, which is what my warning was about. Feed a unit-scalar to a VIM? Better check whether the different cases in the VIM are equipped to handle it properly.

[hooovahh]

On 1/9/2020 at 12:42 PM, X___ said:

Not that I could care less, but VIM, which were introduced in ODG (old gen) are challenged by them 

You can call the non-NXG LabVIEW IDE what you'd like since NI just refers to it as "LabVIEW" but the designator I've seen most commonly used is Current Gen (CG).  But maybe ODG would be better since, well some day it won't be current gen...unless NXG is always going to be coming next.

Anyway I hate units too and have left them behind.  I feel bad for those that do use them as it is an official real documented feature of LabVIEW, but just has too many places it doesn't work as expected.  It's a feature I feel like the majority of NI and LabVIEW users have forgotten about.

[X___]

I do like units for UI. If my users want to use MHz rather than kHz, or ps rather than ns, I do not have to worry about any fancy UI gimmick. It works (it even will not let the users change the dimensionality of the unit of a control at run time, which saves me the headache to fight against mischievous or distracted typers).

They are clearly out, for the worse in my opinion. As we all know, units have never been an issue in major earth-based engineering projects... As for why the x^2 and Quotient and Remainder, etc., "incompatibilities" were never fixed, NI has always had the convenient excuse that they were understaffed, had other priorities, etc. I wouldn't be surprised if the same pattern reproduced itself with NXG.

[crossrulz]

On 1/10/2020 at 2:03 PM, X___ said:

I do like units for UI. If my users want to use MHz rather than kHz, or ps rather than ns, I do not have to worry about any fancy UI gimmick. It works (it even will not let the users change the dimensionality of the unit of a control at run time, which saves me the headache to fight against mischievous or distracted typers).

I just set the display for my controls to something like "%#pHz".  The %p sets the display mode to SI Notation, which uses the prefix.

[X___]

Try typing s^-1 in your control...

Or mi/s/Hz...

This is the power of units. Not mentioning a convenient way to check the dimensionality of a formula (but that's because complex formulas in G tend to explode into spider webs quite quickly, unless - as one should do - one switches to the text alternatives where G does a poor job of visualization).

[Aristos Queue]

On 1/9/2020 at 12:24 PM, Darin said:

A double, with or without units is a perfectly acceptable input for a timestamp format string.

Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp?

 

As for the units thing... I didn’t even test that VI with units. Didn’t think of it as a test case.

 

I’ll investigate both and make lv 2020 either send units to default (by fixing timestamp) or to double (by fixing the assert) or to their own case (if I can find a way to distinguish).

[Aristos Queue]

On 1/10/2020 at 11:15 AM, hooovahh said:

the designator I've seen most commonly used is Current Gen (CG).

I am authorized to use “LabVIEW 20xx” if I absolutely must differentiate... which I generally feel I must do for any sane discussion. 😉 

[Neil Pate]

5 hours ago, Aristos Queue said:

Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp?

This has been around for years! I think it is number of seconds since the epoch in 1970 or something like that.

[LogMAN]

5 hours ago, Aristos Queue said:

Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp?

http://www.ni.com/product-documentation/7900/en/

"LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today.  Representing time as a DBL was not ideal since it did not meet industry requirements."

[Aristos Queue]

Well, thanks for the education. Clearly, I should've know about the double-to-timestamp behavior... the change was during my era.

[Aristos Queue]

Attached modified VI is saved in LV 2018.

I reordered the TSS frames to move integers and fixed point earlier in the list. Then I added Cast Base Units nodes to the floating and complex cases. And I added an Assert Type Match node to the timestamp case.

 

Please let me know if you see further issues. If not, I'll include this in LV 2020.

Scalar To String.vim

[X___]

Seems to work except that it will basically strip the unit from the number, which probably should be documented. I would "expect" a "united" numeric to result in a string with the unit label appended.

<OT>

I had to check what "Cast Unit Bases" does, as I never used it before. The help is quite unique in its warning:

Essentially, if no unit is provided (as is the case in the new Scalar to String.vim), it takes the input and drops the unit (after conversion to the SI unit). The conversion is weird, as illustrated in the attached VI (Control with unit to Cast Unit Bases): I copied the first control and changed its unit: the result after Cast Unit Bases appears the same... ?????

But it also allows you to transform a value in oz/min into one in liter... assuming that you have an indicator with the proper unit to collect the output.

 I am kind of at a loss as to what this was designed for (turns out to be useful for the VIM, bit other than that?).

</OT>

Control with unit to Cast Unit Bases.vi

Edited January 14, 2020 by X___
Corrected a misinterpretation of the function. Edits in red

[X___]

11 hours ago, LogMAN said:

http://www.ni.com/product-documentation/7900/en/

"LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today.  Representing time as a DBL was not ideal since it did not meet industry requirements."

What happens after December 31, 3000 at 4 PM though? (timestamp value 34618060800 = x80F65B000 = b100000001111011001011011000000000000)?

[Darin]

22 hours ago, X___ said:

Seems to work except that it will basically strip the unit from the number, which probably should be documented. I would "expect" a "united" numeric to result in a string with the unit label appended.

In fact I would strip the units only to check the type, but pass the original value into the string format.  Taking it one step further, for a real floating point value with units I would cleanup the string by using SI units and then a little regex action.  Complex values with units are just too far out there to worry much about so I just use the default format.

Scalar To String.vim

[X___]

Works nicely, except that if I input 3 lb/min, I get 22.679618 ms^-1 kg.

ms is not a SI unit.

[Darin]

Reason number Avagadro's Number + 1 why units annoy me.....

Too many corner cases here to worry about pretty printing.  I'd simplify things and simply pass the original value (not the output of the Assert Floating-Point Numeric.vim) to a Format to String function (not Fract/Exp String to Number) and use the default formatting.  You'll get base units everywhere, but for debugging and something that has to be robust enough to ship, probably as good as you'll get.

[Aristos Queue]

17 hours ago, Darin said:

In fact I would strip the units only to check the type, but pass the original value into the string format.  Taking it one step further, for a real floating point value with units I would cleanup the string by using SI units and then a little regex action.  Complex values with units are just too far out there to worry much about so I just use the default format.

Scalar To String.vim 84.04 kB · 5 downloads

That is better. I'll fix it. 

[Rolf Kalbermatter]

On 1/14/2020 at 11:48 AM, LogMAN said:

http://www.ni.com/product-documentation/7900/en/

"LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today.  Representing time as a DBL was not ideal since it did not meet industry requirements."

Quite a bit late to the party but that information is only partly correct! 😀

LabVIEW 2.x and I believe even 3.x used actually an unsigned 32-bit integer for timestamps. Yes it had no fractional seconds and that was a legacy from the Macintosh API.

Edited April 11, 2023 by Rolf Kalbermatter