Replace Diagram Disable Structure by Case structure?

I may be missing something but at least in LV 2010, it appears only possible to replace a "Diagram Disable Structure" by a "Conditional Diagram Disable Structure".
I don't see why it is not possible to replace it by a case structure... The content is very similar and I have faced occurences where I would toy around between different versions of my code and eventually decided that I wanted to offer the user the possibility to choose between them using an enumerated control (or Boolean). Currently you have to rewrite the code in a newly dropped case structure, which is a waste of time. I guess I could stop using Diagram Disable structures altogether, but I most of the time use them for their intended use, so that would be a step backward in functionality if I forced myself to use case structures "in case" I would later want to offer these different cases to the user (which is something that I can't always predict).
Solved!
Go to Solution.

You are not alone.
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-the-ability-to-replace-a-disable-structure-with-a-...

Similar Messages

Event structure vs case structure?

I am developing an application that is fairly user input based... lots of boolean control buttons to do different things.
In the past, I have avoided "value change" event structures, and instead went with a while loop, stacked sequence, and series of case structures. After having done it, I decided this was a terrible idea. This time, I intend to build an array from the booleans, convert it to a number, and feed it in to a single case structure. This will give me the option to add cases for different combinations of the booleans being pressed.
I guess the question is: What is the best method for doing something like this? Does one have advantages over the other?
Edit: I wasn't that clear. I would like a comparison between the "value change" event structure method, and just feeding everything in to an array -> case structure. I also am worried that with the bool array -> case structure that I will run in to problems where I end up with too many control variables, and the value of the resulting number gets ugly very quickly. The application has several buttons... next, last, save, load, several different configure setup buttons etc.
Thanks!
Solved!
Go to Solution.

Aalenox wrote:
I am developing an application that is fairly user input based... lots of boolean control buttons to do different things.
In the past, I have avoided "value change" event structures, and instead went with a while loop, stacked sequence, and series of case structures. After having done it, I decided this was a terrible idea. This time, I intend to build an array from the booleans, convert it to a number, and feed it in to a single case structure. This will give me the option to add cases for different combinations of the booleans being pressed.
I guess the question is: What is the best method for doing something like this? Does one have advantages over the other?
Edit: I wasn't that clear. I would like a comparison between the "value change" event structure method, and just feeding everything in to an array -> case structure. I also am worried that with the bool array -> case structure that I will run in to problems where I end up with too many control variables, and the value of the resulting number gets ugly very quickly. The application has several buttons... next, last, save, load, several different configure setup buttons etc.
Thanks!
Event structure. Among other things, it will allow your loop to "sleep." then wake up when an event happens. With a case structure it's going to be constantly polling. Event structure is pretty much always the right way to go in newer versions of LabVIEW that have it available. I assure you, your first solution was aboslutely wrong and you noticed that, your second is better and was common the way before event structures existed, now that event structures exist, you should go with those.
CLA, LabVIEW Versions 2010-2013

Event structure or case structure

I have some case structures wired to buttons. When each button is true, code inside the corresponding case structure executes. `What are the advantages/disadvantages of using an event structure instead of a case structure?
Ron Deavers, CLD

Place an indicator for the iteration terminal of the main loop to see an obvious difference
Your case structures must be in a loop that constanty runs. If you don't put a delay in the loop, it consumes all CPU, but if your delay is too long, it takes a moment to react to the button changes. The loop spins all the time, no matter if you press buttons or not.
Your event structure also sits in a loop, but nothing happens until you press a button. Now the event structure triggers IMMEDIATELY, executes the event case, and then waits for the next event. The loop does not spin unless needed.
You can even mix the functions by using a timeout event. Code in the timeout event occurs at regular intervals, but at any time, any of the other events can take over.
LabVIEW Champion . Do more with less code and in less time .

Case structure with more than 200 cases, slower lab view app

Problem Description :
i am currently making a vi which compose of a simple case structures, a case structure with more than 200 cases, what i noticed is that the more i added cases the slower the labview reacts, it takes time for me to route wire on each of the cases.
i dont know if there are any setting in the labview environment that i can increase the buffer size? i dont know... but its getting slow (only on the
vi with more cases in a case structure)
mytestautomation.com
...unleashed the power, explore and share ideas on power supply testing
nissanskyline.org
...your alternative nissan skyline information site

Can you clarify what you mean by "slow". Does it run more slowly or does it feel sluggish during editing?
Could you attach the actual VI?
Overall, I agree with the notion of local variable overuse. For example, you read the same local variable twice in the same case. Is there a need for this? Is there a chance that it varies between the two reads? Typically, you would place the terminal in front of the case structure and wire to all the locations where you need the value. This ensures that the data is consistent. Still, this should not cause any slowdown problem.
(On a sidenote, the code in the upper left corner is inefficient. You convert the same data to lower case with each iteration, so you might want to place this before the loop and do it only once (well, if you are lucky, LabVIEW will fold the operation, but still....). Also your "index array" operation can be replaced by autoidenxing of the 2D array on the outer loop boundary.)
LabVIEW Champion . Do more with less code and in less time .

Case Structure Sub Label bug ?

Searching the forum I could not find a post related to this.
Whenever something changes in the diagram LV marks the VI as not saved (yet).
However, when the Sub diagram label of a Case Structure is changed, text and/or visibility, LV does not mark the VI as not saved.
I think this is a bug.
Kees
Solved!
Go to Solution.

CAR 438528 discussed in this thread was fixed in LabVIEW 2014. For a more complete list of bugs fixed in LabVIEW 2014, check the LabVIEW 2014 Bug Fixes. You can download an evaluation copy of LabVIEW 2014 at http://www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.
Regards,
Jeff Peacock
Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect

Disable labview changing a constant that was wired to a Case structure

Hi,
When upgrading from Labview 7.1 to 8.2 I get the following warning:
- LabVIEW 8.2 changed a constant that was wired to a Case structure to a hidden control to maintain compatibility with LabVIEW 7.1 and earlier.
I have read the post describing why this happens:
http://forums.ni.com/ni/board/message?board.id=170&message.id=258528&query.id=18820
Typically I have used a constant wired to case structures to comment out code, and therefore don't really care if the compiler doesn't load into memory.
Is there anyway to stop Labview 8.2 converting constants wired to case structures into hidden controls? E.g. As an import option?
Thanks in advance

I don't think there is a way to disable that upgrade feature, but it does not really matter, because the function remains the same. Just ignore the upgrade note.
To disable code, you should now use the "diagram disable structure". It has the big advantage over your solution that the disabled code can be broken and the VI is still runnable.
LabVIEW Champion . Do more with less code and in less time .

Editor bug if you drag a case structure over an index/replace elements node on a in place structure

To reproduce:
Drag a case structure over a index/replace array node
You'll end up with this train wreck. Autocleanup no longer works
Interestingly, you can still get it to compile but setting the boolean to true doesn't run the true case. Warning: dragging the below snippet onto your block diagram will probably crash LabVIEW
Select all that and drag it into a new VI. Run autocleanup and the development environment will crash: Exception: Noncontinuable exception (0xC0000025) at EIP=0x00000000
Running LabVIEW 2014 SP1 with nothing special.

To quote Obi-Wan
This is not the bug you are looking for..........
Now search for "Clear as mud"
Having a Wired treminal inside an IPE driving conditional code should break the snot out of that code and cause the compiler to puke all over! The lack of check for that insanity is causing the crash! Don't do it! Just think of how you are abusing the poor IPE. What if you had a breakpoint on the Inplace Boundary and changed the boolean? That would necessatate a copy inside an inplace structure....... NO!!!!
Or, more to the point as best I understand: (Add duct tape adound head as needed)
An IPE must exist in one "Clump" Terminal Reads exisist in their own "Clump" (although you can read many terminals in one clump) So you require a clump to read the boolean terminal inside another clump. Clumps cannot reside in clumps since clumps are clumps that stand apart from each other by definition. The run arrow should be broken but is not- hence LabVIEW crashes. Makes sence to me except the clumping algorythm didn't catch the insanity and the run arrow wasn't broken. so the next edit caused all hell to break loose.
(If I missed domething here I am going to learn something today)
Jeff

Diagram Disable Structure and Asynchronous SubVI Bug?

In this diagram, the boolean value won't arrive at the Boolean 2 indicator until ASYNC has completed running.
Without the Diagram Disable Structure, it does not wait for ASYNC to complete.
I always believed the Diagram Disable structure would compile the Enabled case as if the structure weren't there, but that is clearly not the case.
Is this a bug?
Solved!
Go to Solution.

I don't think I agree with you here. The flat sequence structure would behave exactly the same, no matter if it is internally implemented as a node or not. This is how LabVIEW dataflow has worked since the inception of LabVIEW and I see no reason why it should change.
The border of a structure is a border that has well defined behaviour. The structure will not start before all its inputs are satisfied and the output tunnels will not be passed on until everything inside the structure has finished execution. If you want to have Boolean2 update while Async VI is still executing you have to place its terminal inside the DSS (or (Flat) Sequence Structure). This has been so since I first started to work in LabVIEW in version 2.2.1 and better stays so as long as LabVIEW wants to stay dataflow driven.
All text code programming I know of wouldn't behave differently although there you don't have dataflow anyhow so the point is really mute as the sequential flow of the code is all that matters there.
Inlined code is a special case. If they wouldn't do that you could get all kinds of very difficult to debug issues, because your code executes different depending on the inline status and may cause side effects that cause different results because of that.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Diagram disable structure not really disabling?

I have a VI in which I had put a diagram disable structure (not the conditional one) around a section of code containing the Time Delay VI (this is the only place where I have the Time Delay VI). I built an executable containing this VI. When I start the executable I get an error that esssentially says it can't find the Time Delay VI. I removed the diagram disable structure (and the code inside it) and I no longer get the error. I thought the code inside the diagram disable structure wasn't supposed to get compiled. Right?
George

I just made a test built with a diagram disable structure containing an odd subVI in the disabled case and cannot reproduce this error. Are you sure that the relevant case is set to disabled?
Can you attach a simple VI that shows the problem?
LabVIEW Champion . Do more with less code and in less time .

Program won't build if a broken vi is included in a diagram disable structure

I develop code that can run on both PXI and Compact RIO devices.
To allow for the different DAq methods I have a target specific child object that I tried putting in a conditional disable diagram.
I found that even if it was disable, the build would still fail.
When you build rio code on a pxi target, you et problems But I didn't expect them if the class was diagram disabled
In fact it won't build if it is in the project at all.
Posted as a bitter lesson for others to avoid.
iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT

I just made a test built with a diagram disable structure containing an odd subVI in the disabled case and cannot reproduce this error. Are you sure that the relevant case is set to disabled?
Can you attach a simple VI that shows the problem?
LabVIEW Champion . Do more with less code and in less time .

Generating a report w/ block diagram & programatically specified case structure?

Hi,
I am trying to generate a report that shows the block diagram for a programatically specific case structure.
The case structure has ~90 cases and is selected by a custom control.
I'm on Labview 8.5
I've found with the Append Block Diagram to VI, I can print out all of the cases (setting hidden frames to true), or just one case. However, I cannot select which case it shows, it always prints out whatever case has been manually selected on the block diagram, but I want to be able to programatically select it.
I've tried to do the same thing by opening a vi reference, and using BD.Get Image Scaled, and cannot get that working as desired either. I've also tried setting the value of the control before getting the image, but that doesn't help.
Any thoughts?

Probably.
This VI is backsaved to 8.5 and has the basic functionality. I don't know if the traverse VI shipped with 8.5, but hopefully this should be enough. If not, LAVA has info on how to access the scripting features in older versions (although less between 8.0 and 8.6).
Try to take over the world!
Attachments:
Visible Frame.vi ‏10 KB

LV8: Diagram Disable Structure

I am converting my test code from the use of traditional DAQ to DAQmx. In a couple of my test VIs I have the Traditional DAQ VI for Port Config. if I put those in a disable structure marked as disabled will it cause any issues when running using DAQmx drivers? I don't think it should since it does not get executed but I wanted to confirm.
Once I verify my DAQmx changes work, I will remove it.
Thanks
Jeff D.
OS: Win 7 Ultimate
LabVIEW Version: 2011,2010,2009 installed
Certified LabVIEW Architect

Hi Jeff,
That's right, any code in the disabled state of a Diagram Disable Structure does not get compiled or linked to by the owning VI. You should be safe.
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Disable&gray a case of case structure

Hi!
I'm using 2 case structure to choose if I want a "Create Channel" or not. I don't know if it is the best way to do it but... It´s ok if I use this kind of control to choose the case? and... How can I disable and gray the items in the not selected case?
Thank's
TXL
Solved!
Go to Solution.

Sorry I forgot to post it!! That I want is to use 2 or more cases, but when I am in the position "Case 2" I would like that the controls on the front panel to be grayed (or something like this...)
Attachments:
Case 1.jpg ‏41 KB
Case 2.jpg ‏31 KB

Diagram disable adds overhead in certain cases

I was doing some timing tests of two ways to do the same thing – a typecast and flatten to string. Well, in the process I saw a discrepancy when a diagram disable structure was wrapped around a typecast. Without the diagram disable, 1000000 iterations took 274 msec. With a diagram disable around the same thing, it took 1485 msec.
This scared me a bit, because technically the diagram disable case should be no different (ok, maybe a small overhead). It further scared me, because the same overhead is invisible with flatten to string. Inconsistent behavior…
The vi that clearly shows the “bug” in 8.0.1 is attached.
This is not a show stopper, but says “use the diagram disable structure with caution”.
Thoughts?
Attachments:
Diagram Disable Bug.vi ‏24 KB

Apparently that wasn't the only case where Diagram Disable behaves differently than just having the code inline. I also was investigating the performance of certain VIs, because I wanted to know if variant operations were faster than flatten/unflatten to/from string.
In the following snippet, I set the number of loop iterations to 100 and ran the VI, resulting in an Elapsed Time of ~50ms. I then moved the 'To Variant' VI inside the Enabled structure for both cases (Disabled and Enabled), and running the VI again resulted in an elapsed time of over 2 seconds! The source code should be identical in both cases, but it appears as though there is some optimization occuring in the first case that is not occurring in the 2nd case. It's as though in the first case, the compiler is smart enough to realize that the loop output does not change from iteration to iteration, but in the 2nd case it gets stupid.
So continue to beware of the Diagram Disable structure...
Attachments:
benchmark.png ‏71 KB

Can I use a formula node to start the execution of a case structure?

Hi,
I am working on editing a VI to make it much easier to understand (for colleagues and non LV users). For one reason or another, the VI's creators did not fully make use of the power of case structures and other structure types. In the application we need it for, the instrument cycles and repeats measurements on several objects. We are interested in measuring the motor currents for several motors in the system. As it stands now, for each sample object's run, there is a separate sub-vi diagram which displays its waveform trace and several indicators such as max current, time at max, etc. That code was contained within a T/F case structure and copied and pasted 20 plus times.... Obviously the vi became extrememly cluttered and needed a huge screen to see. The trigger for the current case structures is an EQUALS comparison between one input (which is the sample object counter; and this part I will likely leave unchanged since it makes a lot of sense already) and a constant which was defined 1 through 20+ for case.
I have since made one case structure and 20+ instances of that case and have labeled them (at the top selection box near the detent arrows) "1", "2", 3, etc. I am wondering if I can use a formula node to act as the "trigger" which sets each case structure running? I believe that a simple IF statement should work. Please see a snippet of my attempt at making this in C below.
For the node, I defined X as the input and Y as the output. The input to the node, X, is connected to the sample object counter. The output, Y, is connected to the case selector of the case structure. My attempt at the code is below:
int32 y
For(x == 1)
y = "1";
For(x == 2)
y = "2";
etc, etc.
Is that above code snippet correct? Do i need something like "ENDIF" or "end if" at the end? Does "y" have to be defined as "int32" or can it be something else?
Thanks for the help!

Is your formula node doing anything else besides what is shown?
Why don't you just wire the value that is going into it at X directly into the selector of the case structure?
Attachments:
Example_VI_BD.png ‏2 KB

Replace Diagram Disable Structure by Case structure?

Similar Messages

Maybe you are looking for