Let's say that we have the block of code and want to comment out a VI.
So, we wrap the VI in a Diagram Disable Structure.
Everything is good, now, right? The VI's "Run Arrow" (
)
button is not broken, so surely everything must be OK.WRONG!!!
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.
To fix this problem we have to manually wire the DAQmx task reference and the error cluster.
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!
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’)
Ton
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.
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.
Rick
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.
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…)
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
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:
:) Does that Smiley look a tlittle evil to you? I think it’s because of his eyebrows…
Crelf: I made those qualifications in my original statement (in the article)
Crelf: Yes, that is an evil-looking smiley. I hope it doesn’t lead to any hostility, here
Grrrrrrr
Yeah - he’s cool.
Well, if you must make it obvious that I didn’t completely read your original article
Sorry - I’d just skimmed - you’re absolutely right - as always… :p
Crelf: Sorry, I assumed that you’d actually read the article :p
Jim: Where’s the (mooning) emoticon?