NI Home > Community > NI Discussion Forums

LabVIEW

Showing results for 
Search instead for 
Do you mean 
Reply
Knight of NI
Knight of NI
Ben
Posts: 16,158
0 Kudos

Re: Enum constant changing value at runtime LV 2011


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! :smileyhappy:


 

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

 

Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Member
testingHotAir
Posts: 135
0 Kudos

Re: Enum constant changing value at runtime LV 2011

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
Member
Matt-J
Posts: 59
0 Kudos

Re: Enum constant changing value at runtime LV 2011

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.
Knight of NI
Knight of NI
Ben
Posts: 16,158
0 Kudos

Re: Enum constant changing value at runtime LV 2011


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

 

Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Proven Zealot
Jeff·Þ·Bohrer
Posts: 8,282

Re: Enum constant changing value at runtime LV 2011

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

8-Ball Consulting advertising banner

Solving Mining's Toughest Challenges
Knight of NI
Knight of NI
Ben
Posts: 16,158
0 Kudos

Re: Enum constant changing value at runtime LV 2011


Jeff Bohrer wrote:

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


 

Excellent.

 

Ben

 

Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Proven Zealot
Jeff·Þ·Bohrer
Posts: 8,282
0 Kudos

Re: Enum constant changing value at runtime LV 2011

[ Edited ]

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)

8-Ball Consulting advertising banner

Solving Mining's Toughest Challenges
Knight of NI
Knight of NI
tst
Posts: 10,924
0 Kudos

Re: Enum constant changing value at runtime LV 2011





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. :smileysad:


___________________
Try to take over the world!
Member
testingHotAir
Posts: 135
0 Kudos

Re: Enum constant changing value at runtime LV 2011

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
Member
testingHotAir
Posts: 135
0 Kudos

Re: Enum constant changing value at runtime LV 2011

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