"Sequence Containers" to force execution flow without data dependancies

[crelf]

Discussed here: http://lavag.org/topic/9570-new-wire-type-the-null-wire/

Summary: a right click menu option "Visible Items -> Sequence Container" on all VIs, prims, etc (almost anything on the diagram) to allow us to wire force flow control, without having to wire into/out of the actual node.

[lvABC]

“The Null Wire” WoW!

Just one note though, “The Null Wire” should stand out visibly, so it can be easily identify in the code without clicking on it.

[JackDunaway]

Aristos shares my sentiment on this topic: "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."

Instead, how about a more compact, lower-profile Flat Sequence Structure? Don't get me wrong, I hate the Sequence Structures just like everyone, but neither Null Wires nor Null Terminals are good constructs. (Imagine the abuse by a new LabVIEW user who comes from a text based language background... and we think Stacked Structures are bad...)

Message Edited by JackDunaway (mechelecengr) on 09-30-2009 11:36 AM

[Pnt]

I had never seen the posts at LAVA.

Allthough i had propossed this

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Data-flow-visual-improvement/idc-p/922254

[crelf]

Just to be clear: this idea is *NOT* for a null wire!  Sure, the link I posted goes to a thread that talks about a null wire concept, but if you read the thread, the idea is nixed in favor of the sequence container <- that's what this idea is about, so please stay on topic.

This idea is about a one-node-single-case-sequence-structure.  Jack mentions a lower profile sequence structure - I'd be fine with that as long as I could right-click on it and have it shrink to it's contents *and* I want to limit it to one case <- that's the idea that I'm after here.

[Jarrod_S.]

Seems like a potentially confusing concept to me. Visually, especially for newer users, it will look like these are inputs. I'd prefer to just use wrapper VIs that enforce some type of dataflow, like the OpenG VIs do with the Wait functions.

[crelf]

You'd prefer to use wrapper VIs?  Sure - so would I 🙂  But that assumes that there's no overhead in both memory, execution speed, etc.  And that means that I have to write a bunch of wrappers (not to mention all the unit testing I'd have to do).  I'm not saying that this is the best option (that'd be having every node include error handling), but it's far better than what we've got.

Also, the arguement about it being confusing for new/old users - no offense, but that's not a reason not to implement a feature like this.  Almost everything is inherently unintuative until you've used it the first time.  If we used that arguement (and we should certainly review it when making decisions like this), then we'd have no new features in LabVIEW.  LVOOP is a great example - would that have ever happened if NI said it'd be too difficult for new users?  I doubt it, and that's much more difficult to grasp than a one-frame sequence structure around a primative.

[Darren]

I like this.  Basically a single-frame sequence with a slimmer frame, solely for data flow.  Sign me up.

[crelf]

Darren said: Basically "...a single-frame sequence with a slimmer frame, solely for data flow."

Right, but it's only for a node-by-node basis (the current idea limits the numbers of items in the container to 1.  If you want to expand that to be able to include more than 1 item then use a standard sequence structure).

[donkdonk]

"Seems like a potentially confusing concept to me". Yes I think so too.

What about giving them error input and output terminals, even if an "error" is not likely to occur on something like a ms timer 😉

The error cluster is the most used and consistent LabVIEW-way of forcing a sequence. 

[crelf]

[donkdonk] you mean add error handling to all VIs and primatives, instead of using the sequence container?  Sure, the error handling inputs and outputs of subVIs are probably the most used method of execution order, but that doesn't mena that they're the answer to execution order.  ...and there will be primatives and subVIs that don't need error clusters (eg: the "add" primative - if the wires to it aren't broken, then there's no way for there to be an error in there), and adding error clusters to elements that don't need them will added the overhead required to handle them.  Besides, retro-fitting all subVIs and primatives with error clusters is not only a lot of work, it'll creak a *lot* of code and will make saving VIs for previous versions a nightmare.

I still think a native sequence contrainer is the right answer to this issue for the moment.