Labview 2012 compound arithmetic function breaks VI using units

[KeithTK]

After updating from LV2011 to LV2012 many simple VIs doing only basic calculations are broken.

The problem centers around using units and the compound arithmetic function.  Where before units carried through that function just fine, now they get broken down into their base SI units and do not recombine into the original units causing wire breaks even though the units are consistent.

The problem becomes worse if the input units are changed.  In that case the output units seem to have some memory of previous units and multiply them into the updated units creating totally incorrect and inconsistent units.

This seems like a major bug but I cannot find mention of it online anywhere.  Is there any fix or is the compound arithmetic function no longer supporting units at all?

[Darin.K]

I have had a love/hate relationship with units since I first discovered them n days ago. Loved them for 1 day, hated them for n-1 days. This is especially disturbing since it seems like units are moving from quirky and annoying to showstoppingly buggy. I do not have LV12 to verify, I can hope it is pilot error (no offense 🙂 ), but it sounds to me like you found a nasty bug. I have probably posted this before, but here is a short list of things I use more often than units: Globals, locals, flat sequences, stacked sequences, Value PNs, occurrences, Always Copy, you get the idea.

[Ben]

I am in a similar camp as Darin mentioned.

Years ago when I was a wee-G-babe, I discovered the draw-backs of using global when I went the the global VI and ctrl-e (show BD) did not work. Since I could not control the way globals acted I was furstrated with trying to fix them.

Similarly with units, we can not fix them when they are wrong.

My experiments with using units did not survive my first app and I "dusted off my feet" and walked away from them.

Ben

[Matthew_Kelton]

You didn't give an example, but I have deifinitely seen an issue in a basic test.

Addition seems to work fine.  But, multiplication is not.  I did a simple test.  The VI is attached.

I did three distance measurements and multiplied them together to get a volume measurement.  I did this using compound and basic multiply elements.

In LV2011, everything works as expected.

But in 2012, the VI is broken.  To get it to not be broken, I had to change the output from in^3 to in^4.  On top of that, the result is wrong.  Basic multiply elements works fine.

So, it looks like your only workaround is to either insert Convert Unit primitives or to use the basic math primitives.

[Matthew_Kelton]

Looking at it further, it appears in my example an extra 100 cm is being multiplied, which explains the difference in result and units.  100 cm is approx. 39.3701 in. which is the factor difference in the 122047 and 3100.01 results.  If I change my inputs, I am still off my the same factor.

If I change my units to grams, I see an extra 1000g being multiplied.

It appears that whatever the NI default unit is for a particular physical attribute, they are multiplying the result by an additional 1 unit.  So, 1m, 1kg, etc.

It may be this bug exists for non-unit multiplication as well, but when you are multiplying by 1 without units, you will still get the right result.

[Marcus_Körner]

Thanks for that Topic.

I just updated to 2012 and have the same problem.

It must be a bug withe the compund arithmetic function.

Is it possible to fix that problem in a easy way?

[dan_u]

I'm on the same page as Darin. We used units for a while several years ago, but there were just too many bugs. Some have been fixed, but the fact that the simple square function bug (output unit is the same as input unit, not squared, see here) is still not fixed in LV2012 keeps me from even starting to use units again.

[KeithTK]

I agree with Darin, Ben, Dan and many other users.  Units WOULD be a great feature if they worked properly and I avoid them in most cases (still sometimes useful for user input followed by an immediate convert unit).

My main problem with this bug is that it removes existing functionality and breaks VIs that should transfer from 2011 to 2012 with no issue. Scrubbing legacy code to remove units or replace compound arithmetic with basic primitives should not be necessary just to move ONE version forward.

It also makes me wary that there may be some cases where units and compound arithmetic are being used but didn't throw a broken wire when transfered and now could be computing incorrect values without an easy way to track them down.

And thanks to Matthew for putting up an example that I was too lazy to make myself.  😉

[Matthew_Kelton]

No one is saying this is not an issue.  This is definitely a bug introduced into LV2012.  I'm curious how it ever made it there, but doubt I will ever know the answer.  I reported it in the bug thread.  Hopefully NI will see the thread (or Ben will make sure someone will see it) and a CAR will get generated, so it is placed on the bug list.  So, your legacy code should have upgraded with no issue.

If we're lucky, it will be fixed in a patch or SP.  Unfortunately, if you are looking for a quick fix, you'll have to do the workaround or revert back to LV2011.

Another workaround would be to add another node and divide by 1 default unit to get it back to the proper units.

These types of things are why I end up avoiding a new version of LV when it first comes out.  NI had to release a patch 1 week after release to address some issues.  I posted in another thread why I don't participate in the Beta program, and I don't like participating in the post Beta program either.  Sometimes, a customer dictates I have to, but often, I avoid new versions for a couple of months as people find these issues.

[KeithTK]

Ok, this is getting ridiculous.

Scrubbing old code for this bug I came across this:

A simple velocity multiplied by a unitless number yields units of... Gy?  I had to check what a Gy even was!  Somehow velocity = radiation??  That is just sad NI.