LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Enum constant changing value at runtime LV 2011

Solved!
Go to solution

@testingHotAir wrote:

Ben,

 

A1:  Yes, the VI goes to the wrong state when the probe shows the constant changing.  Happens with no probe too.

 

A2:  I searched all instances and verified that are only as many instances in the list as appear in the VI.

 

A3:  I don't have access to an older version so I can't be sure.

 

A4:  No CAR yet.

 

I agree on this being a show stopper.  Hope it's just something I did! 🙂


 

With all due respect, I hope so as well.

 

Can you pass the code to NI so they can confirm the bug?

 

You could reference the SR number I posted above.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 11 of 43
(1,502 Views)

I'll see if I can reduce the code to a more managable size that still displays the problem, but the whole project is probably a bit much to send.

 

A thought I had:

 

The VI uses DVRs to pass around LVObjects.  The particular class that I'm using in this VI is inside a packed project library and contains a typedef'd enum with the same name (States.ctl) as the enum constant that is changing value at run time.  I may be completely off base, but could the compiler be trying to point back to "MainApplication.lvproj : States.ctl" and finding the "LVObject.lvclass : States.ctl" instead?

CLAD
0 Kudos
Message 12 of 43
(1,467 Views)

Hi testingHotAir,

 

We are very interested in taking a look at your code, particularly in a manageable state. This behavior should have been corrected by LabVIEW 2011. So, if we can reproduce the issue in-house, we can quickly file a CAR and get the issue addressed.

 

Thanks,

 

Matt J - NI Tools Network
0 Kudos
Message 13 of 43
(1,442 Views)

@Matt-J wrote:

Hi testingHotAir,

 

We are very interested in taking a look at your code, particularly in a manageable state. This behavior should have been corrected by LabVIEW 2011. So, if we can reproduce the issue in-house, we can quickly file a CAR and get the issue addressed.

 

Thanks,

 


 

Hi Matt,

 

concidering the complexity of HotAirs code and the lack of a previous report of this type, I am leaning toward the issue (if it what it sounds like) is due to the complexity.

 

So dumbing it down may lose the eveidence and any chance to reproduce.

 

Fo large apps I have posted zips to the NI incoming FTP site (it is safe hotAir, only NI can pull code down).

 

So if HotAir can't carve it down to something simple and reproduce the code I would encorage you to let him post the whole thing. Judging by what he showed us, the app may be complex but the code does not look terrible.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 14 of 43
(1,437 Views)

Before we go all hog wild.  I've seen this one before.  Run VI analizer any hidden tunnels?


"Should be" isn't "Is" -Jay
Message 15 of 43
(1,407 Views)

@Jeff Bohrer wrote:

Before we go all hog wild.  I've seen this one before.  Run VI analizer any hidden tunnels?


 

Excellent.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 16 of 43
(1,401 Views)

@Ben wrote:

@Jeff Bohrer wrote:

Before we go all hog wild.  I've seen this one before.  Run VI analizer any hidden tunnels?


 

Excellent.

 

Ben

 



Pain is an effective teacher.  I see nothing in the jpg to indicate overlapped tunnels but, pain IS an effective teacher.  If my Magic 8-Ball is going wonky on this the other tests may still bring out the Velma Dinkey in us. "Jinkeys- A Clue!"

 

If the recient tune up on the 8-Ball was spot on I'll expect the OP to post a link to the IEX post "Don't Let Tunnels Overlap! $%^&$%-it"

 

If you really want to look at something gone insane that blows my mind check out here (Please)


"Should be" isn't "Is" -Jay
0 Kudos
Message 17 of 43
(1,395 Views)




@Jeff Bohrer wrote:

If the recient tune up on the 8-Ball was spot on I'll expect the OP to post a link to the IEX post "Don't Let Tunnels Overlap! $%^&$%-it"



I see no good reason to wait. Here it is with all its glory and 22 votes - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Save-us-from-ourselves/idi-p/1518518

 

Sigh. 😞


___________________
Try to take over the world!
0 Kudos
Message 18 of 43
(1,371 Views)

Ran VI analyzer...nothing unexpected came up; specifically no overlapping tunnels.

 

This same issue occurred in two VIs in the same project.  I'm trying to get a version of it that doesn't require database connections to run.  Stay tuned!

CLAD
0 Kudos
Message 19 of 43
(1,354 Views)

Well I wasn't able to simplify it at all and still produce the problem, so I went back to make sure there problem was still there in the original VIs and...I can't get it to do it.  I think I can upload the whole ball of wax along with the config files and it should work you guys would still like to take a look.  What's the best way to do that?

 

While I was trying to build a simplified version that produced the error I did run into one odd issue: I created a Called Class that contained a typedef'd enum called States.ctl, and a seperate project (Calling Project) that called that class which also had a typedef'd enum called States.ctl.  I built the Called Class into a packed library and included it in the Calling Project, then tried to go back and add a method to the Called Class which made use of the enum.  When I dropped the enum constant into the new method, I got an error saying that the master copy of the typedef was not found.  I had to remove the class from the project and add it back in to get that to go away, but I still had a coercion dot from the enum constant to the enum indicator.

CLAD
0 Kudos
Message 20 of 43
(1,343 Views)