The Diagram Disable Structure causes bugs

Posted on Sunday 11 May 2008

One LabVIEW features that I both love and hate is the Diagram Disable Structure.  I love the fact that you can comment out code, especially broken or stub (unfinished) code.  However, I hate the fact that output tunnels of the Diagram Disable Structure are set to "Use Default if Unwired", because it causes buggy code.  Here's an example...

Let's say that we have the block of code and want to comment out a VI.

before commenting out code

So, we wrap the VI in a Diagram Disable Structure.

after commenting out code

Everything is good, now, right?  The VI's "Run Arrow" (Run Arrow) button is not broken, so surely everything must be OK.


If we show the "Enabled" frame of the Diagram Disable Structure, we can see that we're not passing though the DAQmx task reference and the error cluster.  Our code won't work.

I broke the dataflow

To fix this problem we have to manually wire the DAQmx task reference and the error cluster.

I fixed the dataflow

Now, we're good.  But, we could have avoided this whole problem if the Diagram Disable Structure didn't set all the output tunnels to "Use Default if Unwired".

Presumably, this "feature" (although I like to think of it as a bug) was chosen because users's code doesn't break (at least not at edit time) when they wrap a block of code in a Diagram Disable Structure. Personally, I'd happily accept broken code at edit time to avoid code with bugs -- the choice is obvious to me.

A good solution would be for the LabVIEW designers to make the Diagram Disable Structure intelligent enough to automatically wire any output tunnels to input tunnels that are of the same data type and vertical position.  Now, that would be cool! :)

13 Comments for 'The Diagram Disable Structure causes bugs'

    Ton Plomp
    May 12, 2008 | 4:41 am

    Good point!
    While we are ranting over structures:
    If I have a boolean case structure, and change it to a string case structure, why is there a ‘True’ case and a “‘False’,Default” case, this is silly and dumb.
    I find the diagram disable structure limited, looking into the ‘Conditional disable structure’ is far more interesting (and suffers from the ‘unwired defaults bug’)


    May 12, 2008 | 4:53 am

    I’m a big fan of both diagram disable structures – they have made rapid prototyping even more rapid, and that’s a good thing :) I agree that setting output tunnels to propegate default values by default isn’t the way to go (I assume that would be a relatively easy change, NI?)

    That said, I don’t think that wiring inputs to putputs automatically is the answer. It would work pretty well in your example, but it would fail (or, even worse, wire up the wrong tunnel pairs) when you have more than one of a type and/or have unbalanced inputs and outputs (2 strings in, 1 string out – what to do? Or imagine 1 string in, 2 strings out – wire up one, the other, or both? :) ) Yes, it would be cool if it could read our minds, but I’d prefer that it didn’t even try rather than getting it wrong as that would lead to the same issue as using default outputs.

    Rick Beauchaine
    May 12, 2008 | 9:21 am

    Actually, unless I am mistaken, I have seen three modes of behavior from the diagram disable node using LV 8.2.1

    1. behavior as described above
    2. An error cluster constant containing F/0/empty string
    3. I *think* I have seen it wire my error cluster for me on occasion

    Maybe I will try to re-create 2 and 3 and see if I can describe conditions.


    May 12, 2008 | 9:43 am

    Ton: I agree about the True/False case. There was a similar issue when converting to an Error Case. NI eventually gets around to fixing these usability issues, but only after much complaining from us :)

    crelf : I think that auto-wiring should be optional and very intelligent. I’m pretty sure that we could come up with a rule-set for auto-wiring that would work in a majority of situations. Also, the auto-wiring output tunnels would be MUCH safer than outputting default values.

    Rick: I’m curious to see if you can reproduce the wiring of the error cluster issue — that’s spooky.

    May 12, 2008 | 9:56 am

    Jim: I’m not so sure: the reason I don’t like default outputs is that they don’t break the code and make me wire them up to something intelligent – won’t autowiring have the same issue (it’ll wire something up, which might or might not be wrong) and not break the code. I don’t see the difference (other than it *might* get it right, but sometimes a default response it right too…)

    May 12, 2008 | 10:26 am

    Chris: Here are my thoughts on this….

    There are two reasons that you might want to comment out a block of code:

    1) You don’t want to execute a block of code

    2) You want to execute a different block of code, instead of an original block of code (but you don’t want to delete the original block of code — only comment it out, and put the new block in the enabled frame of a DDS).

    In case #1, I think that it is acceptable to auto-wire an output to an input that is exactly the same data type and vertical position as the input. If a reference, path, error, or other “chained” data input and output are not the exact same vertical position, I consider this to by a style bug in the user’s code. The worst possible thing that could happen is that some input argument is the same vertical position and data type as an output argument and you don’t want to auto-wire them. This has a small chance of causing problems. Perhaps it would be good to limit the data types that we allow to be auto-wired to error cluster, path, refnum (i.e., object, VISA, datalog refnum, DAQmx, etc). Also, if a simply commenting out a block of code (and making no changes to it, other than auto-wiring chained data) will not prevent the parent code from executing, then I can only imagine a couple situations where it might be bad to have a non-chained input argument accidentally auto-wired to an output return value.

    In case #2, auto-wiring doesn’t hurt, because you’re going to edit the newly created, enable frame and will likely make significant changes, anyhow.

    And, if one’s worried, they can disable (or not enable) the feature in the options :)

    May 12, 2008 | 11:40 am

    Jim wrote: “I think that it is acceptable to auto-wire an output to an input that is exactly the same data type and vertical position as the input”

    Sure – now that you’ve made those qualifications, I think that use case is absolutely valid.

    PS: :)

    May 12, 2008 | 11:41 am

    :) Does that Smiley look a tlittle evil to you? I think it’s because of his eyebrows…

    May 12, 2008 | 11:54 am

    Crelf: I made those qualifications in my original statement (in the article) ;)

    May 12, 2008 | 11:55 am

    Crelf: Yes, that is an evil-looking smiley. I hope it doesn’t lead to any hostility, here :)

    May 12, 2008 | 12:25 pm

    Grrrrrrr :) Yeah – he’s cool.

    Well, if you must make it obvious that I didn’t completely read your original article :o Sorry – I’d just skimmed – you’re absolutely right – as always… :p

    May 12, 2008 | 12:31 pm

    Crelf: Sorry, I assumed that you’d actually read the article :p

    May 12, 2008 | 1:00 pm

    Jim: Where’s the (mooning) emoticon?

Leave a comment



Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.

RSS feed for comments on this post |


Bad Behavior has blocked 772 access attempts in the last 7 days.