"Layers" in the block diagram

[bsvingen]

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

[crelf]

QUOTE (bsvingen @ Feb 25 2009, 02:11 PM)

LV is dataflow - not errorflow.

Errors are data too.

[bsvingen]

QUOTE (crelf @ Feb 25 2009, 08:20 PM)

Errors are data too.

He he, funny Yes, but everyone knows what that data is... It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind.

[crelf]

QUOTE (bsvingen @ Feb 25 2009, 03:10 PM)

It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind.

I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler.

[MikaelH]

Same here, I e.g. use a special Error code for User Abort, so I can terminate a test sequence as fast as possible.

//Mikael

[ragglefrock]

QUOTE (bsvingen @ Feb 25 2009, 01:11 PM)

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

I would argue instead of this (but similar) to have error wires default to the bottom z-order of a diagram, beneath all other wires. I don't want to hide them, but I always do Ctrl-Shift-J to put them beneath all other wires. It would be awesome if this was somehow the default behavior.

[crelf]

QUOTE (ragglefrock @ Feb 25 2009, 06:30 PM)

I would argue instead of this (but similar) to have error wires default to the bottom z-order of a diagram, beneath all other wires.

:thumbup: I like.

[bsvingen]

QUOTE (crelf @ Feb 25 2009, 09:25 PM)

I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler.

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

[crelf]

QUOTE (bsvingen @ Feb 25 2009, 07:17 PM)

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

If the wires were transparent then I wouldn't be able to look at the code and see where the data flows. That would be a big step backwards IMHO. Layers in the diagram - well, that's different, and certainly deserves further discussion...

[Val Brown]

QUOTE (crelf @ Feb 25 2009, 05:45 PM)

If the wires were transparent then I wouldn't be able to look at the code and see where the data flows. That would be a big step backwards IMHO. Layers in the diagram - well, that's different, and certainly deserves further discussion...

Layers would be good esp if the error wire could come to the top of the z-order IF an error or warning is being propagated.

[Justin Goeres]

QUOTE (bsvingen @ Feb 25 2009, 04:17 PM)

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

Dataflow code (i.e. what you write in LabVIEW) is fundamentally the expression of relationships between pieces of data. That's one of the key differences between dataflow and imperative programming. And those relationships (in this case, the wires) determine the execution order of elements of your block diagram. If the error wires, or any other wires for that matter, were hidden, you would be hiding key information about your program's execution from yourself (not to mention anyone else unfortunate enough to see it!). Just for starters, you'd be unable to tell if a particular new wire you create would form a cycle (circular data dependency). And if it did, you'd be equally unable to tell why your diagram was suddenly broken.

At runtime, the error wire also contains critical information about the outcome of whatever operations preceded it. That information is used to make all kinds of decisions, as other people pointed out. In the process of making these decisions, the error wire can branch and merge in complicated ways that affect the execution flow of the program. Masking out that kind of information would break the entire relationship between looking at your block diagram and understanding how its code executes.

Hiding the error wires would break the whole dataflow paradigm. It would be like hiding all the individual "if" statements in C code, but not the code inside the { } blocks that follow them, or something.

I would suggest that if you really are having trouble with error wires polluting your block diagrams, you've got too much going on in your diagrams and should use more subVIs.

[bsvingen]

QUOTE (Justin Goeres @ Feb 26 2009, 04:48 AM)

Dataflow code (i.e. what you write in LabVIEW) is fundamentally the expression of relationships between pieces of data. That's one of the key differences between dataflow and imperative programming. And those relationships (in this case, the wires) determine the execution order of elements of your block diagram. If the error wires, or any other wires for that matter, were hidden, you would be hiding key information about your program's execution from yourself (not to mention anyone else unfortunate enough to see it!). Just for starters, you'd be unable to tell if a particular new wire you create would form a cycle (circular data dependency). And if it did, you'd be equally unable to tell why your diagram was suddenly broken.

At runtime, the error wire also contains critical information about the outcome of whatever operations preceded it. That information is used to make all kinds of decisions, as other people pointed out. In the process of making these decisions, the error wire can branch and merge in complicated ways that affect the execution flow of the program. Masking out that kind of information would break the entire relationship between looking at your block diagram and understanding how its code executes.

Hiding the error wires would break the whole dataflow paradigm. It would be like hiding all the individual "if" statements in C code, but not the code inside the { } blocks that follow them, or something.

I would suggest that if you really are having trouble with error wires polluting your block diagrams, you've got too much going on in your diagrams and should use more subVIs.

I think we are sliding off topic here, but I just want to say a few things. To "shrink" diagrams into smaller sub vis purely for the sake of making things modular ,is the same as hiding key information. This is modularization without abstraction, and is IMHO often worse than no modularization at all. The main problem with large diagrams are the shear number of wires. This is exactly the same problem we have with large CAD drawings (a huge amount of information). I am simply saying that if we had a mechanism like layers, so that information would be shown on a "need to know basis", large diagrams would be a breeze to read and understand and change. Layering IS an abstract modularization process, and it is abselutely vital for all serious CAD/graphics applications. The error concept is not a fundamental entity for dataflow, it is more like a "wrapping" to put around sub vis. If we could at least have an error layer that can be turned off, it would unclutter a lot and emphasize the real dataflow. But then again, it could be a completely undoable concept all together for all I know.

[robijn]

QUOTE (bsvingen @ Feb 26 2009, 10:59 AM)

This is exactly the same problem we have with large CAD drawings (a huge amount of information).

(...)

Layering IS an abstract modularization process, and

I don't agree with you here. The layers are used to show an abstraction, but it is not the abstraction itself. That is a fundamental difference with an other way of abstraction, by hierarchy. Then the function (or subVI) is the abstraction itself.

I think hiding elements in a block diagram does not make it clearer to understand. Does it not encourage making a mess because you can use the hiding tools anyway ?

Maybe NI could write a block diagram analyzer that could make a suggestion of what code to place inside a subVI. It could do this based on the the self-sufficiency of a certain part of the code, which can be calculated from the number of wires. However, it would then also need to analyse which wires could better be bundled (cluster), because this is closely linked. Quite a complex problem. Maybe it's best to leave this to a human

QUOTE (bsvingen @ Feb 26 2009, 10:59 AM)

The error concept is not a fundamental entity for dataflow, it is more like a "wrapping" to put around sub vis.

I consider errors in LabVIEW the same as a throw-catch mechanism like in Java (and others). When I place (or get) an error in a wire, code further on will not be executed. The current subVI is exited quickly, and it hands the error to the next VI. I use a special VI (Suppress errors.vi) to catch given errors and for these I might perform a certain action. I could decide to retry, or to generate a different error instead. By default (if the error was not in the list of errors to be handled) the error stays and this means any further code is also not executed. Errors are transported by dataflow and therefor fit in perfectly. Just like in Java I can put some information in the error to know what the error is about. I like that.

Joris

Edit: made bold actually bold

[bsvingen]

QUOTE

I think hiding elements in a block diagram does not make it clearer to understand. Does it not encourage making a mess because you can use the hiding tools anyway ?

Maybe you are right, in LV the wires simply represent the data (or dataflow depending on your point of view) and their actual position is irrelevant for the functionality. In a CAD drawing the "wires" are the data and their positions and dimensions are the whole point. Anyway, the only information we need is knowledge of where the data comes from and where it goes to, everything in between is irrelevant, so it is a bit absurd that something completely irrelevant for the functionality is the one single thing that messes up everything. Obviosly there are lots of improvements that can be done with the basic wire concept, but it has not changed since LV 1.0

[crelf]

QUOTE (bsvingen @ Feb 26 2009, 06:45 AM)

...the only information we need is knowledge of where the data comes from and where it goes to, everything in between is irrelevant, so it is a bit absurd that something completely irrelevant for the functionality is the one single thing that messes up everything.

I agree with the sink/source idea, but I actually think the wire is a great way to represent that. Maybe all you're asking for here is the ability to adjust the brightness of the error (or other) wires? Then you could make them really light (but not transparent) so they are less confrontal. I dunno - every since NI made error wires their own special baby-poo-brown colour, I've been able to tune them out unless I'm specifically looking for them. I also usually line everything up on the error wires which makes that tuning out even easier.

Back to layers: maybe we could combine layers and brightness? If we could define layers and have all wires that aren't in currently selected layers to be very light gray? Should we be limiting the dicsussion to wires? In CAD, layers are synonomous with common functionality, so it might be a good idea to group primatives, subVIs, wires, control nodes, etc into layers. Then when you mouse-over something maybe it could highlight everything on that layer?

[bsvingen]

QUOTE

special baby-poo-brown colour

:laugh: But what do you mean by tuning them out?

When thinking about how layers are used in CAD, it is very similar to OO. Typically you have a layer consisting of the main structure, then add different kinds of detail and functionality. There is a lot of things that can be done I guess, and highlighting when mose over certainly would in an instance make things much clearer in a crowded diagram.

[crelf]

QUOTE (bsvingen @ Feb 26 2009, 09:45 AM)

But what do you mean by tuning them out?

My mind just doesn't get hung-up on them being there. In a sense, I just don't see them unless I'm specifically thinking about error clusters. The colour change, IMHO, was a good step forward to helping me to that.

QUOTE (bsvingen @ Feb 26 2009, 09:45 AM)

...highlighting when mose over certainly would in an instance make things much clearer in a crowded diagram.

I don't want to detract from the discussion at hand, but it sounds to me like the diagrams you're looking at could do with a little love. One of the reasons that CAD folks use layers is because they need to - the distance between objects is a vital part of the functionality of the design in the CAD world, but in LabVIEW it is not (unless you count the 32k pixel wire thaa AQ mentioned once ). So, while I think the idea of layers is a good one, I have a different reason for liking it than you do.

[jzoller]

Visual Studio has the same debate around #regions.

From Jeff Atwood:

QUOTE

I daresay being able to see the damn code is more important than having it meticulously segmented into six pointless little named buckets, but apparently a lot of programmers can't get enough of stuffing their code into pointless little named buckets.

I suspect there is no good solution.

Joe Z.