New wire type, the Null wire

[Mark Yedinak]

With all of this talk about error wires and data flow it has made me think about a different type of wire and connector type that could be useful. There are times in code that certain tasks that don't really share data need to be sequenced. One way of doing this is to pass the error cluster through however the subVIs in question don't generate errors and will do no harm (other than wasting some CPU cycles) from running if an error was present. Another way of doing this is by using sequence frames. However in general sequence frames are not very desirable for many reasons. So I was thinking that a new wire and connector type could be useful for these type of situations. The wire type would be the Null wire (or some other name such as sequence wire) that doesn't actually pass data but rather only imparts a sequence flow on a set of VIs. This wire would be a semitransparent gray wire which would clearly indicate that there is no data present.

A good example of this would be where you want to time a given task. The "Get Time/Date In Seconds" VI only has a single output, the time. So in order to time a task we generally have to place a flat sequence frame down with the Get Time in the first and third frames and our task in the second one. This generally takes up quite a bit of diagram space. However if we could attach an arbitrary connector to any subVI we choose, we could impart the sequencing required to accomplish our task where no true data flow exists. The digram would be far less cluttered than the one with the bulky sequence frame as well. This would be useful in cases where no data dependencies exist and the value of creating a warpper subVI or enclosing sequence frame (which just looks ugly) or creating a separate state in a state machine just isn't warranted. This sequence wire would not require an actual connector on the connector pane as it could be arbitrayily atteached to a subVI.

Effectively this is the same as the flat sequence frame but much less obtrusive on the block diagram.

I would be interested in hearing what others think about this concept.

[Aristos Queue]

> However in general sequence frames are not very desirable for many reasons.

One of the reasons they are desirable is when there is a need for an order dependency and there isn't a dataflow dependency. As a matter of fact, this is exactly the *right* time to be using a sequence structure.

> So in order to time a task we generally have to place a flat sequence frame down

> with the Get Time in the first and third frames and our task in the second one.

And we like this because it makes for very legible timing diagrams. But, if you want to use less diagram space, put a sequence structure around the first timeing node, another around the second timing node, and thread the inputs to your code through the first structure and the outputs through the second structure. It's just a bit harder to identify exactly what nodes are being timed.

[jdunham]

QUOTE (Aristos Queue @ Feb 26 2009, 07:39 PM)

> However in general sequence frames are not very desirable for many reasons.

One of the reasons they are desirable is when there is a need for an order dependency and there isn't a dataflow dependency. As a matter of fact, this is exactly the *right* time to be using a sequence structure.

It would be cool if the sequence structure could be set to 'auto-shrink' around various VIs or globals to which you just want to add an order dependency (or for whatever reason).

Jason

[Mark Yedinak]

QUOTE (Aristos Queue @ Feb 26 2009, 09:39 PM)

> However in general sequence frames are not very desirable for many reasons.

One of the reasons they are desirable is when there is a need for an order dependency and there isn't a dataflow dependency. As a matter of fact, this is exactly the *right* time to be using a sequence structure.

> So in order to time a task we generally have to place a flat sequence frame down

> with the Get Time in the first and third frames and our task in the second one.

And we like this because it makes for very legible timing diagrams. But, if you want to use less diagram space, put a sequence structure around the first timeing node, another around the second timing node, and thread the inputs to your code through the first structure and the outputs through the second structure. It's just a bit harder to identify exactly what nodes are being timed.

I don't think you understand what I am saying though. The Null wire that I am suggesting replaces the sequence frames and allows you to impart data flow where none exists. Here is a picture of the concept. If you look at the image you can see that the diagram is very readable and the sequence is very clear because it appears as a standard data flow. The Null wire connectors are attached to a node and it is not part of the of the connector pane itself. Personally I find the Null wire suggestion to be cleaner looking and more consistent with the data flow aspect of LabVIEW.

[Louis Manfredi]

Hi Folks:

Seems to me that the vast majority of times I do stuff that needs execution order without data dependency, it is i/o with file system or hardware of some sort... most often things that can pop up with some kind of unexpected fault I'd like to detect.

It also seems like there have been many times I've designed code using the error cluster for purely execution order purposes only to discover later that I want to trap some condition and flag it as an error later, and been glad the wiring of the cluster was already done.

So I sort of think the error cluster is fine for establishing execution order, and no new wire type for that is needed. (Though if you want, you could always use a U8 or something as a proxy for a null wire, if you really want one.)

On the other hand, not at all sure I'd design the error cluster just the way its used in modern LV, but that's a whole different topic...

my 2c, Best regards, Louis

[ooth]

Mark, I understand what you mean by a Null wire controlling data flow. In the example you posted which subtracts the two times, I like to use the OpenG Get Date/Time to Seconds because you can use the error cluster. I know it's not a Null wire but it does control the flow.

[Mark Yedinak]

QUOTE (ooth @ Mar 5 2009, 07:54 AM)

Mark, I understand what you mean by a Null wire controlling data flow. In the example you posted which subtracts the two times, I like to use the OpenG Get Date/Time to Seconds because you can use the error cluster. I know it's not a Null wire but it does control the flow.

http://lavag.org/old_files/monthly_03_2009/post-858-1236261193.png' target="_blank">

I think the point that folks are missing is that I am not suggesting somethat that can't be done today. There are always ways around this and using the error cluster is one way of doing it. However, if you are working with subVI's that don't have an error cluster you either need to wrap this and add nothing but the error cluster, or some other arbitrary wire, or use a flat sequence frame. I know that there are ways to accomplish this and nothing new is required. I am making this suggestion because I believe it is an improvement over the sequence frame in that it produces cleaner looking and less cluttered code. Also I don't like the idea of wrapping VI's simply to create an arbitrary data dependency.

The lack of this new feature would not be the end of the world. However I do think its inclusion would produce cleaner looking code in the long run. And in the end, isn't that what we are trying to accomplish?

[crelf]

I think a null wire is a great idea.

[Aristos Queue]

QUOTE (Mark Yedinak @ Mar 5 2009, 09:47 AM)

I do think its inclusion would produce cleaner looking code in the long run. And in the end, isn't that what we are trying to accomplish?

I agree with the goal of cleaner looking code. I just don't buy that something that looks like a wire but isn't and something that doesn't look like a terminal but is contributes to the cleanliness of the diagram, especially when the functionality, as you noted, is available today through existing mechanisms. Going further, your primary case is doing timing on a block of code, having to drop down a flat sequence structure. I think that is extremely clean code. It clearly identifies what code is included in the timing AND it is instantly recognizable visually that you are doing timing ("I see Get Milliseconds in one frame, then a frame of code, then Get Milliseconds in the final frame. Oh, that's a benchmark pattern.") I don't see how having a NULL wire that could wander all over the place -- including branching off to stuff that is not included in the timing -- would be any cleaner.

[jaegen]

I have to agree with AQ. I would support changing the sequence structure to have a (much) thinner border, but I think the null wire concept just opens up a whole bucket of confusion.

You could always create a null class, with a thin light-grey wire. (I realize that still means you have to create actual connector pane terminals for it).

Jaegen

[bsvingen]

I think the backward compatibility ghost plays a major role here, and probably hardwiring to the front panel? along with hard resistance from the "Wire Nazis" and tons of patents, copyrights and other corporate stuff, plus no competition. The LV "editor" hasn't changed practically speaking since LV 1.0, that is over 20 years. When looking at how even the most basic modern software handles charts, flow diagrams etc (for instance the freely available yEd ), I think it is safe to say that the LV editor is stone aged in comparison. Still, there are addons and toolkits from NI that incorporate some modern things and more sensible layouts, but nothing of that makes its way down to the basic editor.

The "de-spaghettify" function in 8.6 certainly is a huge step in the right direction.

I'm not sure about the null-wire though, basically because I think adding yet another wire that doesn't really do anything, is IMO a step in the wrong direction. I would rather have a less intrusive sequence structure border.

[crelf]

QUOTE (bsvingen @ Mar 6 2009, 02:20 AM)

I'm not sure about the null-wire though, basically because I think adding yet another wire that doesn't really do anything, is IMO a step in the wrong direction.

...but it does - it forces execution order.

QUOTE (bsvingen @ Mar 6 2009, 02:20 AM)

I would rather have a less intrusive sequence structure border.

I don't think anyone's suggesting that current methods (like a sequence structure border) go away. Personally, I like to link up error clusters for the error handling and because it gives me a convienient method forcing of flow. I like the idea of a null wire because it allows me to force flow. Sure, there are other ways to do it, but that doesn't mean that this idea is wrong. In fact, I'd hope that the implementation of the null wire would act just like putting seqeunce structures areound stuff - maybe that's what could actually happen in th back ground. A first step could be a null wire that only worked between seqeuence structures - then we could have the flow without the data (although, we'd need to be able to define the source end of the wire).

[Dan DeFriese]

This is exactly what the sequence structures are for... I fail to see how disguising a flow control construct with a something resembling a wire would make the code more readable. Of course, I was appalled when they changed the color of the error terminal and wire.

[shoneill]

QUOTE (Dan DeFriese @ Mar 10 2009, 03:17 AM)

This is exactly what the sequence structures are for... I fail to see how disguising a flow control construct with a something resembling a wire would make the code more readable. Of course, I was appalled when they changed the color of the error terminal and wire.

I could see two advantages here.....

1) A null wire would most likely take up less screen space. Whenever I DO need a sequence structure (I needed one yesterday for instance) I find myself wishing for a 30" display so that all that screen real-estate I just lost wouldn't annoy me so much.

2) A null wire could link only those functions which are required to run sequentially while leaving all around them to run in parallel. Sometimes there are only a couple of things which are supposed to be serialised by a sequence structure but you kind of need to pack everything in so that the code is in some way readable. By interspersing normal code with some sequential code (linked by null wire) I think we have more finely-grained control over exactly which functions are being forced into serial execution.

I also think a null wire should NOT connect to a connector pane, but should connect to a container which contains the VI in question. Sequences of these containers (Use the current Sequence structure for example) can then be linked by null wire, forcing further sequential execution. This would then give a natural connection to existing sequential structures in LV. Like a modular flat sequence structure where the individual frames are linked by wire instead of being glued together.....

Will this introduce complexity into the LV IDE? Yes.

Will it be complicated at the beginning? Yes.

Can the same thing be achieved with sequence structures as they currently exist? Yes.

Will most people use it? No.

I don't know if it's worth the time required to implement it, but I think the idea in itself has merit.

Shane.

[TG]

Why not just make the border of the sequence structure to be much thinner.

This way sequencing (when needed) is very clear and it does not clutter up

the block diagram.

To me making a completely new wire type (even a Null one)

introduce possibility for yet more bugs.

[crelf]

QUOTE (TG @ Mar 12 2009, 12:06 PM)

Why not just make the border of the sequence structure to be much thinner.

That's a good idea - or maybe you could right-click on a VI/primitive and select "Visible Items > Sequence Container" which would add a 3 pixel border around the VI/primitive that we can wire any datatype to. Then it'd be obvious which wires are for dataflow only and which ones are connected to the connector pane.

[shoneill]

QUOTE (crelf @ Mar 12 2009, 09:25 PM)

That's a good idea - or maybe you could right-click on a VI/primitive and select "Visible Items > Seqeunce Container" which would add a 3 pixel border around the VI/primitive that we can wire any datatype to. Then it'd be obvious which wires are for dataflow only and which ones are connected to the connector pane.

Chris, that's almost exactly what I was thinking but I wasn't able to come up with a decent description and I'm too lazy to do a mock-up in a drawing program. I like the idea of a "node-specific" container indeed......

Shane.

[Mark Yedinak]

QUOTE (crelf @ Mar 12 2009, 03:25 PM)

That's a good idea - or maybe you could right-click on a VI/primitive and select "Visible Items > Sequence Container" which would add a 3 pixel border around the VI/primitive that we can wire any datatype to. Then it'd be obvious which wires are for dataflow only and which ones are connected to the connector pane.

This is basically what I have been suggesting with the Null wire. The Null wire would simply connect to a VI without being required to be connected to the connector pane. Essentially we are both suggesting the same thing with the exception that your suggestion would allow you to use any wire to control the sequence whereas mine would require the Null wire. Either way I don't think anyone in this discussion would disagree that we could improve upon the current sequence frame.

[Mark Yedinak]

QUOTE (crelf @ Mar 12 2009, 03:45 PM)

How about this:

http://lavag.org/old_files/monthly_03_2009/post-181-1236890714.png' target="_blank">

I like it. This would be a nice addition and it would eliminate a special wire type.

[crelf]

QUOTE (shoneill @ Mar 12 2009, 03:28 PM)

Chris, that's almost exactly what I was thinking but I wasn't able to come up with a decent description and I'm too lazy to do a mock-up in a drawing program.

How about this:

QUOTE (Mark Yedinak @ Mar 12 2009, 03:35 PM)

Essentially we are both suggesting the same thing with the exception that your suggestion would allow you to use any wire to control the sequence whereas mine would require the Null wire.

Right. Would this other idea preclude the existance of the null wire? (As long as every VI/primitave has at least one output to be able to control dataflow...) ...and I'm sure the NI R&D legends would be able to make optimizations in the compiler that strip out the data from such a wire if they detect that it's only sinks are these sequencing containers (maybe that's the way it already works with sequence structures? If not, it might be a good idea )

[TG]

QUOTE (crelf @ Mar 12 2009, 09:25 PM)

That's a good idea - or maybe you could right-click on a VI/primitive and select "Visible Items > Sequence Container" which would add a 3 pixel border around the VI/primitive that we can wire any datatype to. Then it'd be obvious which wires are for dataflow only and which ones are connected to the connector pane.

Thats even better crelf

Thanks for the that tip!

I'll have to try it out myself

[Mark Yedinak]

QUOTE (TG @ Mar 12 2009, 07:25 PM)

Thats even better crelf

Thanks for the that tip!

I'll have to try it out myself

Unfortunately you'll have to wait until NI implements it though. Crelf was merely making a suggestion for an alternative to the null wire concept.

[Yair]

QUOTE (crelf @ Mar 12 2009, 10:48 PM)

http://lavag.org/old_files/monthly_03_2009/post-181-1236890714.png' target="_blank">

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.

Additionally, I fail to see how this scopes the tested code. You would essentially have to wire to every data flow "start" and "end" points within the tested piece of code. It seems to me that scoping using a sequence or an an explicit error wire coming out of the timer is much clearer. Hmm, maybe this would work if you could expand that border around more than one node? I wonder, what does that sound like?

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.

[shoneill]

QUOTE (Yair @ Mar 14 2009, 06: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.

Followed by:

QUOTE (Yair @ Mar 14 2009, 06: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.

seems self-contradictory but I think I see what you mean. I really think using the diagram disable structure instead of a sequence structure is perhaps not the most transparent solution.

I suppose we could always wire up single sequence structures with some random wire ourselves to mimig what we've been talking about here....... The only difference would be the wire which seems too small a difference to warrant NI doing any real work on it.

Funnily, I never actually thought of doing it like this before......

Shane.

[Jim Kring]

Since (I think) nobody has mentioned it, yet, Agilent VEE has a feature like this and I never really understood or liked it.