LV8.5 upgrade totally screwed up my calculator express vi's !?

[Anthony_de_Vries]

Running an older program on my new Labview 8.5 system, I noticed that my frequency sweep suddenly wasn't working properly anymore...   In stead of properly spaced frequency points, I got only a bunch at minimum, and a some at maximum, and nothing in between.

I checked the code, and found this:

I don't think this express VI complies to the Labview wiring guides !

Not only is the wiring screwed up... it also doesn't work properly anymore.  I'm not a big fan of express vi's anyway, but this is scary...

I don't know exactly when this happened.  Presumably during the upgrade, but I'm not sure.  Had been working on new parts of the code, and hadn't checked this.  (As I hadn't changed anything in it...)

Message Edited by Anthony de Vries on 10-22-2007 05:27 PM

[Ben]

Anthony wrote "...but this is scary... ".

Well if it is at all reassuring the LabVIEW Champions were not able to name a single Express VI !

Ben

[altenbach]

---

@Anthony de Vries wrote:

I don't know exactly when this happened.  Presumably during the upgrade, but I'm not sure. 

---

I think there is something wrong with this express VI in 8.5 in general, does not seem to be an upgrade issue. The connectors get screwed up even if I place a new such express VI and then change the style to subVI.

Does it work properly if you display it as express VI instead of a subVI? (right-click...icon style).

[Anthony_de_Vries]

You're right, this behaviour seems to occur all the time.   I'll write a bug report about it.

The other problem is that when the input is integer, the output also limits to integer. Which is what screwed up the calculation.   It didn't use to do that.        Works again when I put a DBL conversion into one of the inputs.

Can't remember why I used an express vi anyway...   I think I was too lazy to make a calculator icon myself.    Won't make that mistake again! 

[SFK]

---

@Anthony de Vries wrote:

You're right, this behaviour seems to occur all the time.   I'll write a bug report about it.

The other problem is that when the input is integer, the output also limits to integer. Which is what screwed up the calculation.   It didn't use to do that.        Works again when I put a DBL conversion into one of the inputs.

---

I have verified the strange behavior of LabVIEW 8.5. The crude wiring issue is already known (CAR 4A6A828P), for the 'Result' terminal representation I have just filed CAR 4EM6ISWQ.

If there are any updates on these issues, I will post them here.

Best regards,
Sebastian

[JeffBoettcher]

There was a small typo in the first CAR Sebastian mentioned, it should be 4A6A8P28.

Also, I thought I'd share some info on the Formula Express VI changes, particularly pertaining to the output type change.  It was revised largely due to performance.  It used to use the Dynamic Datatype (DDT) for all of its inputs and outputs.  Existing instances of the Formula Express VI should load and still use the DDT, thereby producing exactly the same result as they used to.

New instances, however, will adapt to other types at edit time, thereby greatly improving the run-time speed.  Currently, if all the inputs are integers, the output will be an integer.  This is the way it was designed, for maximum performance.  If you want the output to be a double to avoid losing fractional data in your results, at least one of your inputs must be a double.  I mean, we could always make the output a DDT regardless of the input types, but that would kill some of the performance gain we were striving for.

As such, I'm not sure I consider the second CAR filed by Sebastian a bug, but I would be interested in people's feedback regarding what you'd expect to happen in a situation like this.

[altenbach]

Jeff, thanks for the explanation.

I am always a sucker for performance so I welcome this change (of course I typically don't use express VIs if performace is an issue, but that's a different discussion ;)).

There are two issues that might need to be addressed:

1. It is not good if upgrading changes results, as we have here. Maybe we need some legacy VIs for backwards compatibility or an upgrade dialog about changed behavior (maybe there is already?).
2. In spirit of the regular numeric operations, it should be somewhat sensitive to the operations performed. For example a division between integers always gives a DBL, so if the express VI performs a division or contains any fancy FP function (log, sin, etc.), the output should be DBL.

Of course I just recently discovered the rather undocumented (?) 8.5 feature of output coercion (psst?), so maybe we'll have more control over all of this down the road.

[Anthony_de_Vries]

Thanks for the extra info Jeff,

From what you tell, and seeing how it now behaves, I do like the changes to the express VI. It seems more general in its use, and it's always good if it's faster.  Good improvement.  

However:

Existing instances of the Formula Express VI should load and still use the DDT, thereby producing exactly the same result as they used to.

Unfortunately, they don't. Check the vi that I included in the first post.  It's the original vi without changes.  (except the mandatory save during upgrade).  The express vi used to output DDT, which I then immediately converted to DBL. As you can see, the existing instance now outputs integer...

The way you describe it, with the new instances using the new behaviour, and the old instances keeping the old behaviour, would be absolutely perfect. But it doesn't seem to do that in practice... 

[Matthew_Kelton]

Jeff,

I think the original poster said that the output was changed to an integer from a double during the upgrade process, which seems to contradict the behavior it should follow, as this was an existing express VI.

[JeffBoettcher]

Anthony - do you have a copy of the VI attached to your original post that is saved in 8.2 or earlier?  If so, please attach it to a reply, thanks.