New wire type, the Null wire

[crelf]

QUOTE (Jim Kring @ Mar 14 2009, 05:06 PM)

Agilent VEE has a feature like this and I never really understood or liked it.

What's not to understand? It's a new method of forcing and dsiplaying execution order when we can't use dataflow (easily or neatly).

QUOTE (Yair @ Mar 14 2009, 12:12 PM)

I think this is a terrible idea and would create a huge potential for wiring bugs for people who won't notice the border or know what it is. I'm guessing that you just want the users of the NI forums to have more threads they'll need to respond to.

I'm not married to the visual implementation.

QUOTE (Yair @ Mar 14 2009, 12:12 PM)

You would essentially have to wire to every data flow "start" and "end" points within the tested piece of code.

Just like we currently do with dataflow?

QUOTE (Yair @ Mar 14 2009, 12:12 PM)

If you guys don't like the sequence structure because of its size, all you need to do is use the diagram disable structure which has a much thinner border and which I believe can have a single frame.

Yuk! That'd be unintuative - people looking at code like that would see a diagram disable structure. Sure, there are ways around this issue, but we're discussing an intuative new feature.

[Mark Yedinak]

I agree that using the disable structure is not the right way to go since it will lead to greater confusion because the structure is being used in abnormal ways. Crelf's suggestion or the Null wire suggestion both have specific meaning. They impart sequence flow where there is no inherent data flow. Either method replaces the need to wrap subVIs and introduce artificial data flow by passing an error cluster or some other data through it that is not actually used or using the very large sequence frames to accomplish the same thing.

[Yair]

QUOTE (crelf @ Mar 15 2009, 03:56 AM)

Just like we currently do with dataflow?

Not exactly, since people seem to want to avoid "artificial" data flow and you would usually want to scope a block of code.

Here's a challenge - create a sample graphic which has several nodes and shows how this is easier and more readble.

QUOTE

Yuk! That'd be unintuative

Probably. I didn't say it was a good solution.

[crelf]

QUOTE (Yair @ Mar 15 2009, 12:59 PM)

Here's a challenge - create a sample graphic which has several nodes and shows how this is easier and more readble.

I thought I'd already done that - can you help me to understand what you're looking for?

[Yair]

Your example has no code and the border wraps each node individually.

What I'm essentially getting at is this - Either the code you're scoping has internal dataflow dependencies and then it can have an external dataflow connection easily added, even today (e.g. by using the OpenG tick count wrapper), or it doesn't have internal dataflow, in which case you would need to force it or wrap all the code in a single structure to make it clearer that you're profiling all of it together.

I simply fail to see the big advantage in having a "special" wire and I do see potential for problems.

P.S. I'm not even sure that making sequences smaller is even a good idea. Narrow borders are great, but we need to be able to easily tell the different structures apart. I think we would have to see an example of a thinner sequence to know whether it's worth it or not.

[crelf]

QUOTE (Yair @ Mar 15 2009, 02:15 PM)

Your example has no code and the border wraps each node individually... Either the code you're scoping has internal dataflow dependencies... or it doesn't have internal dataflow, in which case you would need to force it or wrap all the code in a single structure to make it clearer that you're profiling all of it together.

Ohhh - I see what you're saying now - you're saying that you'd want something that you could put multiple subVIs/primatives in, and in that case I agree that using a one page sequence structure is the way to go. What I was suggesting was never meant to replace that behaviour.

QUOTE (Yair @ Mar 15 2009, 02:15 PM)

I simply fail to see the big advantage in having a "special" wire and I do see potential for problems.

For the record, I'm not crazy about the special wire either, and that's why I suggested the "Visible Items > Sequence Container".

[thawkins]

Just came to this discussion via a link from a comment here and wanted to register my vote against the 'null wire' idea, sorry. I don't see the huge advantage over sequence structures for the relatively small number of use cases and it introduces not only a new bit of visual language which new users have to learn before they can understand other people's LabVIEW code, but also a new functionality that new users (or programmers coming from text languages) are quite likely to misapply in order to force linear code into LabVIEW instead of learning to think in dataflow.

I believe if NI introduced this, we'd all regret it pretty soon ;-)

[crelf]

Update: idea added to the NI Idea Exchange here.

[crelf]

...new functionality that new users (or programmers coming from text languages) are quite likely to misapply in order to force linear code into LabVIEW instead of learning to think in dataflow.

I agree that's a valid conern - and it certainly should be considered for every feature addition/change/deletion, but IMHO I don't think it's a strong enough reason to not introduce new functionality. If that was NI's policy, I don't think we'd have any features like LVOOP.

[Mark Yedinak]

Update: idea added to the NI Idea Exchange here.

Thanks for posting the suggestion on the Idea Exchange.

[crelf]

Thanks for posting the suggestion on the Idea Exchange.

No worries - I'd have done it earlier, but I thought it was already there for some reason. Hopefully it'll get some good exposure over there.