LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

BUG Workaround: SI notation "m" refuses to display "mm", change annotation to "m "

Title says it all.

 

Helpful logic gone awry. If you add a space to the end of the "m" annotation, it will accept mm and it will still show up in the control without the space. Hopefully, devs will fix it in the next release.

Message 1 of 9
(2,701 Views)

This bug is a little worse... In addition to hiding the mm annotation, if you fix it with a space, regular or non-breaking (Alt+255 for a non-breaking space) it will not register a new value if the sign is the only thing changed. You can change it to m¹ (Alt+0185), and it will workaround both helpful logic bugs...

 

While on the subject of Si notations, maybe the helpful dev can add a power property. This way we can have proper conversion from m² to mm² and m³ to mm³

0 Kudos
Message 2 of 9
(2,620 Views)

Hi simple,

 


@simple_logic wrote:

While on the subject of Si notations, maybe the helpful dev can add a power property. This way we can have proper conversion from m² to mm² and m³ to mm³


The proper power notation is m^2 (cm^2, mm^2, m^3…) - as described in the LabVIEW help…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 9
(2,597 Views)

It sounds like the control is set to display SI, so that "m" would mean "milli".  But it also sounds like the control is not set for any units, where "m" would be meters.

 

I don't mess with units as they are more trouble than they are worth, but "mm" would mean "millimeters" in which case it would have to be SI and units enabled.

 

If the OP is trying to say "mm" is supposed to be meters squared, then that is just wrong and I've never seen meters squared represented that way in the real world.

0 Kudos
Message 4 of 9
(2,558 Views)

From the tag, you seem to be using LabVIEW NXG. Do you see the same problem in classic LabVIEW?

 

This is really not something that we can judge by just reading an ambiguous paragraph, so please attach some code that demonstrates the behavior.

 

I assume that you are talking about a numeric indicator. What are the format settings? Units? What exactly are you entering, what do you get and what do you expect.

 

(Controls understand entered SI prefixes, for example 1k -> 1000, 1m -> 0.001, etc.)

0 Kudos
Message 5 of 9
(2,521 Views)

It is as bad as it sounds... 

Just drop a numeric control, set display format to Si notation, and annotation to "m" and now type in 1m, 1mm, 1 mm, 1 m and it will not pick it up as mm. Type in 1cm and it goes to 10m. Vi does not need to run for the bug to occur, and running the gvi will not change the behavior. I'm using NXG 3.1

0 Kudos
Message 6 of 9
(2,359 Views)

Do you know if units have been implemented in NXG?

 

They were a late addition to LabVIEW.  Not many people use them.  A few people swear they are useful, many others have found issues with the math surrounding controls and constants with units in them and avoid them.  I would not be surprised if NI does not port units over to NXG, or will only do it at a much later date.

 

You will still have to show us a file and ideally a screenshot of the issue you describe.  Many of the regulars on the forums have not made the jumps to NXG so you may not get as much advice as you would if you were using classic LabVIEW.

0 Kudos
Message 7 of 9
(2,326 Views)

@RavensFan wrote:

Do you know if units have been implemented in NXG?

 

They were a late addition to LabVIEW.  Not many people use them.  A few people swear they are useful, many others have found issues with the math surrounding controls and constants with units in them and avoid them.  I would not be surprised if NI does not port units over to NXG, or will only do it at a much later date.


They were actually an ealy addition to LabVIEW! They are around since at least LabVIEW 4.0 or so over 25 years ago. I agree with the rest. The Units in LabVIEW were an interesting idea and worked reasonably well when they came out but there always existed a few bugs in respect to them. For some reason they did only receive minor work after the initial release and many of those little pesky bugs never ever got squashed.

In my perception there were two problems with the way Units work in LabVIEW. One is a fundamental one as even the SI system isn't always completely consistent so pressing that into a software algorithme is a nasty feat to do, although not as nasty as trying to make calender functions work!

And it seemed to me like the code involving Units was written by someone who had a pet peevee with Units and at some point he or she left the LabVIEW team and there was nobody else who even dared to touch the code anymore, just as many other areas in LabVIEW where the code base hasn't been touched even with asbestos gloves out of fear to burn their hands on! 😀 PArt of that may be also different code style. I suppose the original LabVIEW code is in terms of modern style rules a tricky thing to understand and its actual implementation was often dictated by the hardware constraints of those days where a few kB of extra memory here and there meant the difference between running on average user hardware or limiting the execution to pure high end super beasts of computers.

 

I would be extremely surprised if they even tried to take the Unit implementation from LabVIEW CG into NXG considering the many little troubles it is riddled with.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 9
(2,243 Views)

@RavensFan wrote:

I would not be surprised if NI does not port units over to NXG, or will only do it at a much later date.


IIRC, it's on the 'never going to happen in NXG' list...

 

Units have their use cases.

 

I actually don't use the units, but I do use the quantifiers of the units. When getting\setting GUI values from a file\DB by references, specifying a (any) unit as u, m, K, M, G has the effect of scaling the value from the file in the GUI. So it's easy to display a value in meters as mm, or grams as Kg.


Using units for this is a hack. I'd like to see a offset\multiplier property for numerics instead, just like the graph scales.

0 Kudos
Message 9 of 9
(2,169 Views)