Amusing disable structure bug

When I say amusing I mean I took a few hours to find it and then laughed...
If you have a diagram disable structure without an 'enabled' case LabVIEW throws and error and won't run, flags the structure and tellins you to add an 'enabled' case. This happens even if the structure is empty. Fair enough.
If you a a diagram disable structure without an 'enabled' case in a disabled case of another diagram disable structure (with an enable case) then Labview won't run the vi but will only say : 'Labview needs more memory to compile vi', and won't flag the structure. It will then often crash...
This seems odd for several reasons:
1) I don't think this used to be the case - I found the bug importing an old .vi which used to work.
2) Logically an enable case isn't necessary - suppose I want to disable all the cases?
3) Why is code in a disabled case making any difference anyway?
Anyway - hope this saves somebody a few hours
Luke

Jester_v01 wrote:
When I say amusing I mean I took a few hours to find it and then laughed...
3) Why is code in a disabled case making any difference anyway?
Anyway - hope this saves somebody a few hours
Luke
Whay answer require somebodt sitting in that conference room when the decision were made but...
WHen the Disable structure was introduced a bug entered whenre "Source Distributions" would fail to take into concideration code in the disabled structure. Since the disabled structure was (?) intended (?) to affect if code got compiled or not but was not (?) intended (?) to influence if code was part of the Source Distribution this was called ab ug and I think fixed. Others have since realized the bugging behaviour was actually a bug and what they thought was a feature was really a bug.
So I suspect you have found another corner case not concidered in that conference room years ago.
Just my guess. If you have a better one please share.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Similar Messages

Another use for the disable structure (Bug or Feature?)

Hi,
I always use a lot of dynamic VI's in my projects, and sometimes I need to
pass parameters to them. I use Set Value methods.
One problem is that when you build an executable, the application builder
(AB) removes the panels by default, and the Set Value method will fail... I
know you can change the AB settings, but I was getting tired of that (and
had some free time). I also know you can change the VI properties so AB
won't remove the front panel...
But I started looking for things that tells the AB not to remove the front
panel.
I found out that the FP won't be removed when the VI has an event structure.
And it turns out that this works even if you put the event structure in a
disable case!
I'm pretty sure this isn't supposed to happen. I'm not so sure if it's
usefull since it might change over versions (I use 8.5.1), but I thought I'd
share it anyway...
Regards,
Wiebe.

Just today I had a problem with a VI with a diagram disable structure that would compile but the FP of the executable was mallformed and cause the whole app to crash.
So I stay away from diagram disable structures in execution code.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

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

LabVIEW Mac prompting me for dll's in conditional disable structure

I'm using LabVIEW 2014 Mac and I have several conditional disable structures which call user32.dll but only in the Default case whereas they do nothing in the TARGET_TYPE=Mac case. When loading my source code in LV Mac I get prompted to find "user32" and I have to Ignore All. Afterwords the code is open with no errors.
It seems to be a bug that this prompt is occuring? Is there a way to supress it?
Solved!
Go to Solution.

Hello Thomas,
It sounds like the user32.dll is being loaded along with your LabVIEW code on launch instead of being loaded when called. What you can do is encapsulate the function that is making the user32.dll call in a subVI (if you haven't already done this), right-click the subVI and go to Call Setup. From this window, choose Load and Retain on First Call. This should make sure the user32.dll is only loaded when you reach the Default case in your Conditional Disable structure, and not search for it every time the code is loaded into LabVIEW.
Hope this helps,
Siana A.
Application Engineering
National Instruments

Diagram Disable Structure doesn't remove all objects it contains after deleting the structure.

I have programmed in side of a while loop a Stop from "Application Control", later I used disable structure around that "Stop". It was working fine, but after removing disabled structure containing the disabled "Stop" my application stops even there was no reason to stop. Later I have experienced that removing the disabled structure leaves hidden object in the code and some how they get executed and it is no way debugging due the objects are invisible.
I am worried that this is a bug in Labview !
(Edi)
Solved!
Go to Solution.

The Stop was in the disabled case in a frame and after removing the complete "disable structure" the software stopped randomly at the location where the disabled structure containing the Stop was already removed. Unfortunatally the code is to complex to post. I am working on a demo, but sofar doesn't prove my point yet. But I realized Labview was pointing on left over items from the disabled structure after its removal. The compiler was high lighten the hidden objects in the same shape of the object but without any visible object in the high lighted position in the graph.
(Edi)

Diagram Disable cosmetic bug ?

Start from here (attached VI):
switch to the Enabled case and wire the top tunnel to the right tunnel:
Oops! While is the wire misaligned?
The strange thing is that this problem does not occur if you wire from right to top.
Tested in LV 2011.
Attachments:
Diagram Disable Cosmetic Bug.vi ‏4 KB

Actually, this also occurs with For Loops as well:
(you need to first connect the array to the Loop border. Then in a second step, connect the autoindex thingy to the other side - I know this is not what you would do normally, but this is just illustrating the bug).
Oddly enough, this does not appear to be the case from below:
...for the For Loop. The Disable Structure does that from below:

What are the valid values for CPU in conditional disable structure config?

After diggin' around for some time (but to no avail)...
Does somebody know the valid values for the CPU (symbol) in the conditional disable structure configuration or where I can find this information?
Best regards,
Horst

Not sure but you can try this:
http://zone.ni.com/reference/en-XX/help/371361E-01/lvprop/app_apptarget_cpu/
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

Is code in a disable structure included in an executable?

I have a LabVIEW 8.6 VI that I would like to build into an executable. This code includes several PXI drivers for motion control and power supply control. I have a hardware simulation mode built into the code that will allow me to run the front panel regardless of whether the software is running with hardware or not. There are case structures around each of the hardware driver VIs in the software. If I am running the code normally, the cases with the hardware driver VIs will be called and they will operate the connected hardware. If I am running the code in hardware simulation mode, the cases with VIs that fake hardware will be called. All of this works as I intended. The problem comes when I try to build the code into an executable and distribute it to people who I know don't have the hardware, and probably don't even have LabVIEW installed. The problem is that these people will have to install the NI runtime support (which I am perfectly fine with) but they will also have to install the drivers for the hardware that they don't have.
I am wondering if I were to change the case structures to conditional disable structures and disable the drivers, would that code still be included in the executable and require someone to install unused drivers to run the simulated code?
Eric C
Systems Integrator, National Technical Systems
Certified LabVIEW Architect

Hi Eric C,
Good Morning and I hope your well today.
Thanks for your interesting post!
I would like to highlight one aspect of the help file, " ..Has one or more subdiagrams, exactly one of which LabVIEW uses for the duration
of execution,..". To me, this suggests at run time only one case will be valid. Thus, I don't believe this will act as you wish. Secondly, I am under the impression that this can't be used in an executable (compiled form - I got an error 1 when trying to). This maybe because the exe can't decide what case to use. Due to the above, I feel we should look at this issue from a different angle.
To make it clearer, once the code is deployed there is no longer the conditional structure OR the code in the other frames. (There are however if your making a source distribution).
I am guessing your driver would be calling third party dlls, and the exe will load these at the beginning. So this is likely to generate the browse window is the driver isn't installed. In your documentation you could include that this means you need to install the driver. If your user was then to run the code you could use a case structure and test that the file has been created by the installer for the driver (I.e. no install directory no driver). This would then prevent the end user running the application without the driver.
Thus, if you feel its not ideal the customer sees the browse window then you could run the installer for the driver at the end of the NI installer, which you could include when you distribute your application.
Please let me know your thoughts,
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

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

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

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 .

IPhoto 09 folder structure bug

Let me start by saying that I am a big Apple fan. I have a Macbook Pro (end 2006) running 10.6 with a 30 inch Cinema Display, a 23 inch iMac (mid 2007), and an iPhone 3G and a Nano 5th G. I am an Apple Certified Systems Administrator and was also the first person in Japan to be certified on OS X 10.5 as an Apple Certified Support Professional, however I am primarily an Windows Active Directory/Exchange Server engineer.
I have been using iPhoto since version 06 (end of 2006). I upgraded to 08 as soon as it was released then last year I upgraded to 09. Until recently I had about 18,000 photos in my iPhoto library, but due to the issue listed below I have now switched to Windows Live Photo Gallery on Windows 7 for managing my photos (these are synced using Windows Live Sync to my Mac's Photo folder where I then use Picasa for Mac. Sounds complicated but actually not and it means I can import my photos on my Mac or PC and they are synced both ways. Anyway...
I posted the following Bug Report to: http://www.apple.com/feedback/iphoto.html
If you use iPhoto and don't want to spend days/weeks fixing your folder names and reorganizing photos into correct folders if your library becomes corrupt or you ever want to move your photos out of iPhoto then please provide feedback to Apple so that they know that we are not happy about this.
Bug Report.
The problem with iPhoto 09 is that the the folder structure inside the iPhoto Library package no longer matches the event names in iPhoto.
Previously in iPhoto 08, when renaming an event in iPhoto the folder structure would also be updated. Additionally splitting or merging events would move the files in the iPhoto Library package's folder structure. This is a major problem for me and many other users on the Apple.com iPhoto 09 discussion forums, and this issue has existed since the beginning of 2009!
I need my photo's folders named correctly for the following reasons:
1). Incase I should ever need to move photos out of iPhoto and to another application or platform, I would' have to spend days or even weeks renaming all the folders.
2). If my iPhoto library ever become corrupt and I needed to recreate it then I would loose ALL my event names (hence the details) if iPhoto doesn't keep the folder names the same as the events.
I have recently spent many hours migrating my photos out of iPhoto and renaming the folders manually. iPhoto really was all I ever needed in a photo management application but with this underling bug/issue I can't trust all my photos to it's library format of storage, but I do hope this gets fixed so that I can migrate back to iPhoto in the near future. Might I suggest that the best way forward for the future would be change iPhoto so that it can monitor folders (the same way Picasa does so, this is open and then gives customers the choice of using multiple apps for accessing their photos).
Regards,
Andrew

A bug can be an error or fault in the software but it can also be a design flaw which IMO this is.
No it can't. A design flaw is just that. A bug is when the software fails to works as designed. iPhoto is working as designed. You may prefer it work another way, but that's your preference. Remember you can always use a different product for managing your photos. You're not required to use iPhoto, you know.
Exporting dumps all the photos into a single folder which again doesn't solve either points 1 or 2 that I made.
Yes - if you export the entire Library at once.
If, however, you export each Event in turn (an process that can be automated with either Automator or AppleScript) then it will export to appropriately named folders.
And, as to any issue of corruption, the simple fact is that backing up is the ultimate protection.
What you want will possibly preserve your Event names. But that's all. It won't preserve albums, slideshows, metadata, the relationship between original and modified versions, the non-destructive editing and so on and so forth. All you'll get will be some folder names.
Now that's both your points answered. For the second time.
I'm not sure why there are so many Apple apologists on these forums.
I see, so someone who explains to you that you have misunderstood something, explains to you a better way of doing what you want to do is an "apologist"? Just like your definition of "bug" it's a mite idiosyncratic. And rude.
I am pretty sure that at some point there will be many users who will want to migrate out of iPhoto and when they do they won't be very happy when they realize that they are locked in.
Nobody, I repeat nobody, is locked into iPhoto. That statement is a falsehood. File -> Export and off you go.
we can either sit back and just accept these limitations, anti-competative vender lockins and design flaws or we can voice our concerns to Apple and get things changed for the better of everyone.
Every software has limitations. What you have failed to show is that any of the matters that concern you are actually "limitations". There are no
anti-competative (sic) vender (sic) lockins (sic)
iPhoto works with entirely standard formats. All your files and metadata are easily accessible throughout the OS and can be easily exported.
Regards
TD

Disable commands BUG under Sun-Solaris 10 ?

If you execute a disable commands while another user is justdoing a "force restructure",you got no error and the command "display application"shows the command-flag with false. But every user can still execute a "force restructer",even if the user log in later. This behaviour occurs under OS=Sun Solaris with essbase Version9.2.0.1,under windows with essbase version 9.2 Build 082 it worksfine. Is this a known BUG ?

I can't help you solaris tuning, but some things to look at.
1. Is the Essbase.cfg file the same on both servers? You might have parallel calculation turned on in one and not the other. Caches could also be set differently
2. Are the database caches set the same? This could impact performance as well
3. Are you doing an apples to apples comparison? Is one database loaded and recalculated many times while the other is not (or restructured or reloaded)

Menu Ring disabled update bug

Currently still on Labview 2011 (upgrading within a few weeks to 2012 SP1) I have the following bug:
If a Menu Ring is disabled and has a "normal" (non-empty) value it will keep its contents (meaning: shown text will remain) when you overwrite StringsAndValues[] with an empty array.
I was unable to find anything about it either officially fixed / known or on this forum, meaning it will probably still be there in the latest version.
Can someone please verify to see if this bug indeed (still) exists in the latest Labview version?
Solved!
Go to Solution.

Thanks, though I fail to see why a Menu Ring can not be empty. Imo there should NOT be an error message, but just a plain empty control (or indicator).
I use the Menu Ring to show and allow (if there are other types available) to change a subtype of an electronic product. The control typically does so for released products, meaning I filter out products (and subtypes) still under development (or still undefined). The list can thus be empty. People busy with development have a setting available to also show (and change to / from) these new or (as of yet) unknown types and products. When there are no elements (in this case: subtypes) or only one the control is disabled.
I looked further into this and at no point does Labview mention, force or coerce a user to have at least one element in a (Menu) Ring.

Amusing disable structure bug

Similar Messages

Maybe you are looking for