Strange behavior executing LabVIEW 7.1 VI in LabVIEW 2013

[billko]

---

@Darin.K wrote:

The original VI is messed up.  The default numeric value for the control is '5'.  Prior to LV9 this was being coereced to the closest value (1=Auto) and that is why it "seemed" to work.  Beginning in LV9 this value was being coerced to 0.

Go to LV7, Type Cast a U16 numeric 5 to the manual/auto enum and wire to the case structure.  You will get 'auto' since it is coerced to Auto.

Go to Lv9+, Type Cast the same U16  to the enum and wire to the case structure.  You will get 'manual' since it is now coerced to Manual.

---

If any one person knew everything about the LabVIEW underpinnings, it would be you.  🙂

[Darin.K]

---

@billko wrote:

---

@Darin.K wrote:

The original VI is messed up.  The default numeric value for the control is '5'.  Prior to LV9 this was being coereced to the closest value (1=Auto) and that is why it "seemed" to work.  Beginning in LV9 this value was being coerced to 0.

Go to LV7, Type Cast a U16 numeric 5 to the manual/auto enum and wire to the case structure.  You will get 'auto' since it is coerced to Auto.

Go to Lv9+, Type Cast the same U16  to the enum and wire to the case structure.  You will get 'manual' since it is now coerced to Manual.

---

If any one person knew everything about the LabVIEW underpinnings, it would be you.  🙂

---

Well, most of what I have learned was via being bitten in the arse.  As to how much trouble I have sitting these days, I'll leave that to others to decide.... 

[Darin.K]

As often happens when you deal with oddities like this, things are never as simple as they seem.  While exploring ways to recreate this behavior, my simple Type Cast test started showing the same work once oddities with the control. 

I'd fix that sucker in LV7 if it were me.  Once you get the Express business out of your face it is actually a pretty solid version of LV.

[chembo]

---

@Darin.K wrote:

The original VI is messed up.  The default numeric value for the control is '5'.  Prior to LV9 this was being coereced to the closest value (1=Auto) and that is why it "seemed" to work.  Beginning in LV9 this value was being coerced to 0.

Go to LV7, Type Cast a U16 numeric 5 to the manual/auto enum and wire to the case structure.  You will get 'auto' since it is coerced to Auto.

Go to Lv9+, Type Cast the same U16  to the enum and wire to the case structure.  You will get 'manual' since it is now coerced to Manual.

---

Thanks, this explains what happens. But there is some inconsistency:

• When 'mode' is type casted to U16 we get numeric 5
• The probe on this same wire shows value of 1, i.e. Auto. Maybe it should show ? similar to highlighted mode

[Darin.K]

---

@chembo wrote:

---

@Darin.K wrote:

The original VI is messed up.  The default numeric value for the control is '5'.  Prior to LV9 this was being coereced to the closest value (1=Auto) and that is why it "seemed" to work.  Beginning in LV9 this value was being coerced to 0.

Go to LV7, Type Cast a U16 numeric 5 to the manual/auto enum and wire to the case structure.  You will get 'auto' since it is coerced to Auto.

Go to Lv9+, Type Cast the same U16  to the enum and wire to the case structure.  You will get 'manual' since it is now coerced to Manual.

---

Thanks, this explains what happens. But there is some inconsistency:

• When 'mode' is type casted to U16 we get numeric 5
• The probe on this same wire shows value of 1, i.e. Auto. Maybe it should show ? similar to highlighted mode

---

As I replied, even the casting test got a bit weird as I dug around with that control floating around.  When I recreated from scratch, the U16 -> enum type casting was similar between LV7 and LV12.  When I used the original control in the type casting it was different at first and then became the same.  Hate those kind of bugs...

Two pieces of information are stored for the default value of the enum:  the text displayed in the control and the numeric value.  LV just assumes they match since there should be no way for them not to.  Except you found a way.  How the different versions react seems to have changed.

I always have two conficting feelings at junctures like this:  morbid curiosity and the strong urge to purge the demon from my hard drive.  More than once a curiosity such as this has managed to infect other code.

[chembo]

---

@RavensFan wrote:

If you have a process already for programmatically running these VI's, what happens if you add to that and do something like a Set Vale on the controls programmatically before executing the VI.

---

This seems to be nice workaround. It works!. When I confirm, i.e. set the 'mode' value to 1, via control reference and property node from the automation VI, and then execute the VI, it works properly.

[Yamaeda]

---

@Darin.K wrote:

Well, most of what I have learned was via being bitten in the arse.  As to how much trouble I have sitting these days, I'll leave that to others to decide.... 

---

Well i heard it's healthy to stand at your desk ...

/Y