LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange behavior executing LabVIEW 7.1 VI in LabVIEW 2013

Solved!
Go to solution

I am trying to extract some hard coded data from old LabVIEW 7.1 code and decided to write a small program in LabVIEW 2013. The program opens a reference to a 7.1 VI, searches for some enums and calls it by reference with all combinations of the enums.

 

Actually pretty simple, but then I noticed that something is no working as expected. The old VIs have this enum called mode (0 = Manual, 1 = Auto), which is not wired to any connector and has a default value of 1 = Auto.

 

In LabVIEW 7.1 everything works as expected, but when I load this VI in LabVIEW 2013 and run it, without saving the file, it executes the 'Manual' case instead of 'Auto'. I used even a probe to check the mode value in LabVIEW 2013 and the value is 1 = Auto, but it goes through the 0 = Manual case.

 

Below is just a simplified version of the VIs, but the behavior is absolutely the same. The VI (LabVIEW 7.1) is attached. Try to load it in LabVIEW 2013 and run it. I don't have 2014 on my PC.

 

test_enum_vi.png

 

Screenshot of the execution in 7.1 and 2013

 

test_enum_vi_execution.png

 

Any ideas? Does this happen because of any strange settings on my LabVIEW 2013 installation? Can you reproduce this?

 

 

0 Kudos
Message 1 of 17
(4,044 Views)

The same happens with 2012 SP1 version. Might be some inconsistency when opening an earlier version? I am curious to know the reason behind this.

-----

The best solution is the one you find it by yourself
0 Kudos
Message 2 of 17
(4,035 Views)

Very interesting.  I see it in LV 2014 also.

 

If you go and change the enum, or actually just click on it and pick auto, it executes properly from then on.

 

But if you do a Ctrl-Run to force a recompile without touching the enum first, it does not help.

0 Kudos
Message 3 of 17
(4,022 Views)

it works properly if you make "Auto" the default case.   Looks like somehow "Auto" is not getting matched properly to the case, though I can't see why.

0 Kudos
Message 4 of 17
(4,015 Views)

Does it work correctly after saving the file? In that case it's not a breaking bug, if annoying.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 17
(3,994 Views)
Not even saving just when we change the control value it works as expected. The issue happens when we just open and Run the code.
-----

The best solution is the one you find it by yourself
0 Kudos
Message 6 of 17
(3,992 Views)

@Yamaeda wrote:

Does it work correctly after saving the file? In that case it's not a breaking bug, if annoying.

/Y


Saving in the newer LabVIEW version makes it work. Also any other changes, as all others here mentioned.

 

In this case I am just trying to have an automated process and run these VIs in order to extract some data, so I prefer to do it without any changes of the existing VI. When I call the VI it goes in that 'manual' mode and expects user input, so the automation is gone 🙂

Luckily the old VIs don't have any dependencies, so I can just save them as temporary files and get the job done. But if I was dealing with more complicated code, it will be really annoying.

0 Kudos
Message 7 of 17
(3,962 Views)
Solution
Accepted by topic author chembo

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.

 

Message 8 of 17
(3,942 Views)

With execution highlighting on the enum terminal output is "?"

Capture.PNG

Not a deadly bug but definately an unexpected consequence

 

If I remember my history.  the Allow no selection property was added in 7.1 perhaps with a little side effect.

 

Interesting documentation.  No resemblance to reality


"Should be" isn't "Is" -Jay
Message 9 of 17
(3,927 Views)
Solution
Accepted by topic author chembo

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.

Message 10 of 17
(3,920 Views)