Enum constant changing value at runtime LV 2011

[JÞB]

well,

running the VI analizer was still informative.  At least we know it isn't a hidden tunnel.  (Gotta get that 8-Ball back to the shop)

---

  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.

---

the project should be resolving the name but just out of curiosity-  try renaming those enums.

[testingHotAir]

I renamed the enums in my real project yesterday and now can't get the error to come back. Perhaps that was the root?

[Ben]

Could be.

Go to your back up and check it.

In theory nane-mangling should avoid confilts but when it fails .... shudder.

I may be ieasy to send NI the hwol ething complete with the DB.

They are smart they can figure it out.

Ben

[testingHotAir]

Ok I added another bit to the project and I've got the problem again.  Where can I upload this pile of VIs so that you all can see it?

[JÞB]

Check your PM for the FTP site link

You'll want to have customer support on the phone to walk you through it (and so they can find it)

[testingHotAir]

Ok I've got a SR and am working with an engineer on this.  Here's the latest place where this problem is cropping up:

The "problem display" image is the block diagram and front panel of the display that is displaying the problem.  The "main app" image is the same display loaded dynamically from a packed library and inserted in a subpanel.  Note the iterations indicator and the State In indicator.  The State In should never read "Initialize" as there are no constants with that value in the BD.  The iterations going over 10000 means the VI is stuck in the Initialize state.

[testingHotAir]

Additional info:

I disconnected the enums in that VI from the typedef and the problem went away.

[JÞB]

OMG!

Dynamic events inside a state machine! 

You do know that once regesirted those events WILL queue up, waiting for the chance to be acted on IF the event structure is in an active case?  (if The ES is NOT ready to run, the events will still queue up- and those events are ready to GO when the event structure CAN execute.)

And , are you also aware that Your_Class is on a tunnel, with no change to the class private data in the event shown being fed out to the class via the IPE shown?  Yup, you did not change the data in the class being fed into the loop!

have you looked at the option to show loop invarient constants?  those "squiggly" wires will help straighten this out!

[testingHotAir]

Yes, I'm aware that events will queue up.  In this case I'm ok with that, even though it's not a particularly good choice for all applications.

I'm not sure I follow your second comment.  The class private data in the DVR is changing when that IPE executes, which is all I care about.  In the end, that DVR is deleted by the main UI application, which produces an object of the top-level class that I then serialize and write to disk. 

I have not looked at the option to show loop invariant constants.  What's that?

Thanks everyone for the help so far!

[testingHotAir]

Remember that VI where I disconnected the enums from the typedef and the problem went away?  Well it's back.  The enums are constants, non-typedef, and the value at runtime is equal to zero regardless of the value dropped on the diagram.