Defining own units

[Malin]

Hi

Is there a possibility to define your own units in LabView 6i?
I'm need of using "VAr" as a unit, but it's not a SI unit so I guess it's
why it won't work.

/Malin

[Jim_Kring]

No you can't do that.

A suggestion - Don't use units in your LabVIEW code unless you really have to. I have used LabVIEW for about 6 years and have never found any advantage to using "units" that outweighed their inconvenience. In fact when I use constants, like "c", I remove their units prior to using them in my code. I have found them to be much more trouble than they are worth. I heard from a LabVIEW developer that the only reason LabVIEW still has "units" is for backwards compatability. It isn't really a value-adding feature.

That's just my opinion, I could be wrong!

-Jim

[LYNN POWELL]

"Jim Kring" wrote...
> I heard from a LabVIEW developer that the only reason
> LabVIEW still has "units" is for backwards compatability. It isn't
> really a value-adding feature.
>
> That's just my opinion, I could be wrong!

I can happily refute that the only reason we have units is for
backwards compatiblity. I can believe there might be a misguided LabVIEW
developer who would tell you that, though...
Granted, they have problems, but to say it's not value-adding is kind
of harsh. (And no, I'm not the author of units--Jeff K is.) I've written a
few apps that would have been really annoying without LabVIEW's builtin
units. For example, one of my hobbies is photography, and I wrote a
depth-of-field calculator in LabVIEW. This is a fa
irly simple formula
involving millimeters (e.g., for focal length and the "circle of confusion")
and feet (for focus distance). LabVIEW makes it so much easier in a case
like this.
But, writing these apps points out some problems that I think we'll try
to address quickly, such as better documentation and programmatic control of
the unit label. There are also some harder projects that I think we must
consider, such as user-defined units and non-linear units. There's also a
whole area of confusion about imprecise terminology (BTU? Which BTU? There
are several. Horsepower? Same thing.) and imprecise conversions (e.g.,
Liters to UK or US gallons. There are also conversion factors that are
legislated, and the legislation changes over time!).
I'm open to your suggestions on how to improve units in future versions
of LabVIEW. Contact me at the address below with your ideas. It's time to
stop bashing them and make them better.


Brian Powell
Sr. Group Manager
LabVIEW R&D
br
ian@ni.com

[Nitrof]

Thousans of an inch is missing.  In the insdustries, it is : mil

Or it could be min for mili inch?!?

Any way il will have to find a work around for this one.

A good thing about units.  They add a constrain to the data types.  Suppose you have a instrument which return a length measurement.  If you add unit to the output, the programmer has no need to care about, is it in meter, milimeter?

[NIquist]

Yup, min = milli-inch = mil.  I don't use the physical units in LabVIEW often but they do have their uses.

BTW, this thread is over a decade old in case you didn't notice...

[Nitrof]

Ok, right, it is quite old. But thousand of an inch do not exist yet in LabVIEW 2012.

Any solution?

[NIquist]

---

@Nitrof wrote:

Or it could be min for mili inch?!?

---

I was agreeing with this.  The min in LabVIEW units is the same as a US mil.  Both mean 1000th of an inch.

[Alexander_Sobolev]

>>  It's time to stop bashing them and make them better

Bug removing (LV 2011)?

1) Block diagram constant: show units, enter mm. Try to enter 10 - value will automatically change to 0.01 (of base unit - meters). The only way to have 10 with mm unit label: 1) set m as a unit. 2) enter 0.01. 3) change unit to mm.

2) Numeric indicators on block diagram do not have unit labels.

Not bugs, but inconveniences and problems I see with units:
1) No-unit units (radians, degrees, dB) will be treated manually anyway. LabVIEW will never know what should it get if divide 3.14 meters by 2000 mm? 1.57 or 1.57 radians or 90 degrees? 

2) LabVIEW is a general purpose system - it should have all units. But every application requires a small, often non system set of units. The same abbreviation can mean different units. (SI does not have samples, so instead of s for seconds it is common to use sec). Setting up a system of custom units for every application for different customer? NO.

3) Not all functions that are compatible with LabVIEW support units. Not to mention 3-d party drivers. You will have to manually remove units before such functions and reenter them afterwards.

4) Functions and subVIs should have variant units ability, linking input and output: For example: Sine wave amplitude units should determine output units. X and period inputs should support the same type of units: I want to use the same subVI for generating different oscillations - in time, space, frequency...

5) I do not like when the system is smarter than it should be. It will (I am extrapolating its future a bit) automatically convert units to scaled type: It is not nice to see 0.0012 m instead of 1.2 mm, but not in all cases. So unit system requires display setup tools: autoscale unit or not, what units to use or skip (Angstroms are not very good for distance measurements - sometimes!).

6) Units should have superscripts and advanced formatting. User interface is a very important part of the program. if you do not use units there, why should you use them anywhere else?

IMHO, units is a minor enhancement that requires plenty of efforts from NI to make it usable and later from a developer to use them.

[Jeffrey_Zola]

@NIquist wrote:

---

@Nitrof wrote:

Or it could be min for mili inch?!?

---

I was agreeing with this.  The min in LabVIEW units is the same as a US mil.  Both mean 1000th of an inch.

---

So....  What is the LabVIEW unit for one sixtieth of an hour?!?