repeating cases with duplicating contents

[CFAMS Brad]

Hi everyone,

This is probably a dumb beginner question:

I have a case structure that alternatively switches some controls to constants as to cut off user intervention (an interlock).  When I create the first case of the structure, all are controls.  Then I tell it to duplicate the case, and I change some to constants....etc.  You get the point.  However, that second case creates a new set of controls on the front panel.  I want to keep working with the same set of controls originally created, just changing a select few to constants depending on the particular case.  Am I missing something obvious?

Thanks,
Brad

[smercurio_fc]

No, you're not missing anything obvious - that's just the way LabVIEW works when duplicating a case. You're asking it to duplicate the contents of a case, and it's doing exactly what you told it to do.

It's not clear what you're doing with the constants, as you didn't explain the rest of the code, but perhaps another approach that you should consider is to enable/disable the controls with property nodes. With property nodes inside the case items you don't get duplication of controls when duplicating a case. Using a local variable also prevents duplicatio of the control.

[CFAMS Brad]

Thanks for the tip, Mercurio, but I was trying to get by without using property nodes because of other threads I have read and other advice I've recieved.  The reason I want to change from controls to constants is because in certain cases I need to close certain valves when there is a leak and I don't want the user to be able to open the valves unless he/she overrides the interlock.  In actuality, it is not simply changing to a constant, but changing to a value and not allowing the user to change back until the problem that set off the interlok is remedied.  So in certain cases, I change the controls to false constants. 

I will try with property nodes and I am sure I can make it work this way, but if anyone has any different ideas, please let me know. 

brad

[smercurio_fc]

Well, I can understand the objective, but your architecture implementation is still not clear to me. Do you have an event-driven program? It sounds like when you're in some specific state, then you don't want to be able to let the user fiddle with some controls. That, to me, sounds like you want to enable/disable the controls, and not take the approach to change to a constant since at the user interface level it seems to imply to the user that they can still mess around with those controls. You're just overriding the value in code. Like I said, I'm just guessing here because I can't really see your architecture. However, if you were to access the controls via local variables as I mentioned in my first response, you then would not have the issue of the controls duplicating when you duplicate the case. My mention of the property nodes had to do with enabling/disabling the controls.

In general, property nodes are not evil. It's simply that sometimes they can get misused. For example, you should never use a property node to accomplish what you can do with a local variable or just a wire. For example, I've often seen a lot of code written by inexperienced LabVIEW programmers that use the "Value" property to set the value of a control. Usually these folks come from a VB/C++ background. In this case it is far more efficient to use a local variable. However, there are some things that can only be done with a property node.

[altenbach]

Maybe your controls don't belong inside the case, place them in front of the case structure, then wire them up. 🙂

[smercurio_fc]

I thought of that as well, altenbach, but as I said, I can't quite figure out the architecture of the program, so I opted on the minimum impact to his code approach tied into his original question of what happens when you duplicate cases.

[CFAMS Brad]

Okay, maybe I am going about the whole concept improperly.  I've attached a simulator for what I want to do.  In this little VI, you can open and close valves freely as long as the simulated pressure is under 10.  If there is a leak in the system and the pressure increases above that threshold, the valves lose functionality AND go to the closed state.  It is important that they do both, and this works for this simple case.  Now, in real life, I have about 9 scenarios where different valves need to be closed while others maintain functionality.  If you take my small VI and try to add those controls to each scenario (or even if you just try to copy one of the scenarios to a new case and change a constant to a control) you end up with an unwanted control on the front panel. 

I think this states more clearly what I want to do and why, hopefully there will be some good suggestions.  sorry about the late reply - I am currently taking Basics 1 and II from LabVIEW (but very impatient!). 

Thanks, Brad

[altenbach]

As I said before, the control terminals need to be in front of the case structure! 🙂

(Also place a small wait in the loop and use "built array" instead of the scenic route via a cluster. ;))

[smercurio_fc]

OK, now I see waht you're doing... I agree with altenbach.

Message Edited by smercurio_fc on 04-26-2006 01:27 PM

[CFAMS Brad]

Thanks for the tips.  I have posted the bettre code below.  It wasn't clear that having controls wired into the case structure and constants wired into it would work.  I thought that that would leave me with a broken arrow.  But it works (and with less processor use), so thank you.

Brad