LabVIEW 2018 SP1 f2 Crashes when changing constant units to blank

[pauldavey]

When changing a constant's unit string to blank, LabVIEW 2018 SP1 f2 crashes. This is repeatable for me with the attached VI. It does not happen with a control/indicator (so I can use that as a workaround).

--Edit--

This is LabVIEW 32bit, Windows 10 64bit

[RavensFan]

What specifically did you do to change the unit string to blank?  I tried by double-clicking on the unit until the "m" was highlighted, hitting the delete key, then clicking elsewhere.  It did not crash.  However, I do not have SP1 installed,  My LV About says 18.0f2.  So f2 patch, but on the initial LV 18 release.

Second question.  Why are you working with units?  I have never really found a good reason to use them, and the only time I ever hear about them is in the context of someone having problems with them.

[pauldavey]

I double clicked and deleted as you did.

I find units useful in a number of occasions - working with time+sampling rates is one, and working with time/distance/mass and mechanics formulae to get the right units out.  They are good with prefixes (milli,micro,kilo etc).

[billko]

---

@RavensFan wrote:

What specifically did you do to change the unit string to blank?  I tried by double-clicking on the unit until the "m" was highlighted, hitting the delete key, then clicking elsewhere.  It did not crash.  However, I do not have SP1 installed,  My LV About says 18.0f2.  So f2 patch, but on the initial LV 18 release.

Second question.  Why are you working with units?  I have never really found a good reason to use them, and the only time I ever hear about them is in the context of someone having problems with them.

---

Sometimes data from different sources are expressed differently - e.g., one source returns values in Volts, another in mV.  Let's say I want to add 0.05 mV + 2 Volts.  Much easier for me to convert them both to Volts and do a straight add.  Then re-convert into a pure number.  I don't know if I'd trust units for anything much more complicated, though.

[RavensFan]

That all sounds good on paper.  But like I've said, the only time I hear units mentioned are in conjunction with them not working properly.  So I just don't trust them.  I'd rather explicitly do the math in code to convert different data sources to a common value before doing the calculations.

[billko]

---

@RavensFan wrote:

That all sounds good on paper.  But like I've said, the only time I hear units mentioned are in conjunction with them not working properly.  So I just don't trust them.  I'd rather explicitly do the math in code to convert different data sources to a common value before doing the calculations.

---

Sure.  We just have different trust levels.  You're just a bit further down the "paranoid" scale than I am.

To add to your point, I've never heard of "units" being offered as a solution to a problem, either.  Which is probably even more profound.

[pauldavey · Accepted solution]

This has been fixed in LabVIEW 2018 SP1 f3

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

728099 - In some cases, LabVIEW crashes when deleting unit labels from constants.

[Hooovahh]

---

@billko wrote:

---

---

Sure.  We just have different trust levels.  You're just a bit further down the "paranoid" scale than I am.

---

I get what you are saying but I think paranoid isn't quite the right word.  More like historical cautiousness combined with past experience.  I too avoid units in every application I've ever done other than in basics when they taught it.  Why?  Because not every function supports them and doing some operations in the past would do weird things to the units.  I just checked and you can do one thing which I don't believe you could before which is square a value, then square root it.  Still you can't do the opposite which is square root a value then square it.  You also can't use formula nodes, and NI's formula evaluator stuff doesn't work with it. 

I just see it as work to manage the units, and then manage turning them back to non units to use these functions, then convert them back into units.  I see it much easier to manage if you just work with everything in SI units, and then on the UI have explicit conversions as needed.