"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.

[tst]

> 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

It's interesting you should mention the Add primitive. Try wiring a waveform into it and see what happens.

[donkdonk]

@crelf,

>"adding error clusters to elements that don't need them will added the overhead required to handle them"

You may be right, I just simply would't know. I'd guess if the error cluster is simply there for sequence purposes, a compiler would know and cause no overhead.

>"then there's no way for there to be an error in there". So what?

>"Besides, retro-fitting all subVIs and primatives with error clusters is not only a lot of work [....]

You probably are right, but I would not suggest to fit all primitives. I've never felt the urge to have an additional way of forcing a sequence after a 'add primitive' apart from the scalar wire resulting from it.

An example BTW is the "time delay" express vi which I now use often instead of the 'wait (ms)' primitive. That's what I had in mind when I put my reply.

I agree however, that your suggestion is much more flexible. But as it is presented now, it too much suggest there's dataflow.   

>[..], it'll creak a *lot* of code and will make saving VIs for previous versions a nightmare".

Didn't think of that, good point, I guess.

[donkdonk]

@crelf, 

>"and there will be primatives and subVIs that don't need error clusters"
yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"
Probably, but then I would not suggest to provide every primitive with error clusters.
In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

>"elements that don't need them will added the overhead required to handle them"
I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".
Yes, probably a good point mentioning this.

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.
However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

@crelf,

>"and there will be primatives and subVIs that don't need error clusters"
yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"
Probably, but then I would not suggest to provide every primitive with error clusters.
In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

>"elements that don't need them will added the overhead required to handle them"
I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".
Yes, probably a good point mentioning this.

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.
However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

@crelf, 

>"and there will be primatives and subVIs that don't need error clusters"

yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"

Probably, but then I would not suggest to provide every primitive with error clusters.

In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

>"elements that don't need them will added the overhead required to handle them"

I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".

Yes, probably a good point mentioning this. 

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.

However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

@crelf, 

>"and there will be primatives and subVIs that don't need error clusters"

yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"

Probably, but then I would not suggest to provide every primitive with error clusters.

In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

>"elements that don't need them will added the overhead required to handle them"

I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".

Yes, probably a good point mentioning this. 

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.

However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

@crelf, 

>"and there will be primatives and subVIs that don't need error clusters"

yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"

Probably, but then I would not suggest to provide every primitive with error clusters.

Or just right click, and an additional node is attached to the primitive.. 

In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

 

>"elements that don't need them will added the overhead required to handle them"

I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".

Yes, probably a good point mentioning this. 

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.

However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

@crelf, 

>"and there will be primatives and subVIs that don't need error clusters"

yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"

Probably, but then I would not suggest to provide every primitive with error clusters.

Or just right click, and an additional node is attached to the primitive.. See attached figure.

In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

 

>"elements that don't need them will added the overhead required to handle them"

I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".

Yes, probably a good point mentioning this. 

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.

However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

ahh,

All my posts are here.....I didn't see them. One has to click on top of the page to see the next 10 replies...

Thanks to subscriber ' tst' this all comes to an end now 😉

Sorry for the duplicates... 

[rgvdh@rdf]

I understand that sequence structures are frequently overused and misused, but isn't coordinating tasks that don't really share data but still need to be sequenced exactly what it's for?