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:

Similar Messages

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

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

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

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!

Adobe Reader X cosmetic bug - browser integration scrollbars do not move

There appears to be a cosmetic bug in Adobe Reader X (10.0.0) browser integration. When you open a PDF in a browser window, the scroll bar remains at the top of the window when you scroll the PDF using page up / page down, or the mousewheel. If you mouse over the scroll bar, it moves to the correct place in the PDF.
This bug is consistent across IE 8, Chrome 7.0.517.44, and Mozilla Firefox 3.6.12 (running on Windows 7 Enterprise x86).

*PUSH*
Please fix this. Its just ridiculus to provide a plugin like _THE_ Adobe Acrobat Reader and not be able to implement a proper scroll behavior. Come on it can't be _that_ hard .
Thanks

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 .

Diagram Disable produces "-17502 System Level Exception" with TS 4.2 + LVRTE 8.6.1

I had a labview VI that had a diagram disable structure on it. TestStand loaded it all right, but threw a -17502; System Level Exception at runtime.
TS 4.2, using labview 8.6.1 RTEW adapter.

Jed -
Could you please attach files that reproduce this behavior?
Manooch H.
National Instruments

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 .

Menu cosmetic Bug

There is a text cosmetic bug in AirPort utiility version 5.5 (550.29) in the Internet - DHCP section at the LDAP Server/DHCP Reservation lines.

Welcome to the discussions!
As you know, this is a forum of end users and it appears that you are addressing your post to Apple.
They may or may not even read these boards, so if you want to speak directly to them, why not do so with AirPort Extreme Feedback.

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)

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)

Why Is the Block Diagram Disabled?

What did I do now? Please look at the attached image. A VI that I am using as a subVI in various different programs suddenly started looking like I had used application builder to create an exe file out of it (But I didn't!!). The only options are Start and Run Continuously, and the block diagram is disabled. What did I do to get myself in this mess? How do I undo whatever I did, so I can edit the block diagram again? Any help or suggestions would be greatly appreciated.
Thanks!
Solved!
Go to Solution.
Attachments:
Disabled Block Diagram.png ‏259 KB

Did you ever built a source distribution with the option set to remove the diagrams? In this case, the original must still be around somewhere.
Since LabVIEW 8 you can no longer simply save without block diagram and you would not be able to upgrade such a VI to LabVIEW 2011, which it is now. (details)
Of course it is possible that there is some corruption, but looking at the memory usage, the block diagram is blanked out.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
NoBlockDiagram.png ‏38 KB

Diagram Disable cosmetic bug ?

Similar Messages

Maybe you are looking for