Pop quiz! Test your understanding of channels!

[sth]

I think beta tries to show a timing dependence.  We are used to the paradigm where flow is generally from left to right.  In this case it implies that there is still an order to these wires.

Actually since each loop has to move the date from one channel to another there is an order.  Visually you then can see when/where a blockage or delay could occur

[Dragis]

Thoric wrote:

At the moment I don't think the wire look is sufficiently distinct. As kegghead put it there are now infinite wire colourings with class customisation, so async wires looking a little more rounded (like pipes) doesn't make it particularly easy to distinguish them from the plethora of possibilities. I'm not sure what to suggest though as an alternative. No wires? Dashed wires between the loop boundaries? Ghosted/semi-opaque wires? Three-dimensional wires that 'leave the virtual block diagram surface'?

                   

These are some of the same ideas that have been floating around internally. I personally, after looking at various mockups, still like a variation of the wires that float above the diagram. There are also options for toggling the wires to mostly-transparent until you hover over an endpoint, for instance, that makes it easier to see only the information that is currently pertinent. The same would go for getting rid of dataflow wires while you are attempting to inspect only the communication of the system.

[Dragis]

The vertical vs horizontal distinction does not sufficiently solve the problem for many of the applications I've written. The convention of data flowing from left to right is great, but more importantly data should flow in the direction that it needs to flow. Having built a number of applications that act like systolic arrays or mesh networks there is data that flows in every direction and I already find that LabVIEW doesn't make it easy to write code that looks clean for these situations.

I really want to find a solution that separates the channel communication layer from the dataflow layer in a way that doesn't require a flat 2D plane.

[Thoric]

Maybe the key here is in the word "layer". In graphics packages, which I tend to use a fair bit, I find the concept of layering intrinsic to grouping of content. I can create a background layer, a frame layer, a guidelines layer, a primary content layer etc. Each sits atop the next building up the entire graphic.At any one time I usually have just one or two layers visible to make editing easier, it reduces noise. Our wonderful LV Icon Editor uses just this concept.

If the Block Diagram had layers (perhaps a 'dataflow' layer and a 'communications' layer to start) we could switch the visiblities of these layers to enable easier interpretation of the diagram. I imagine Channels would be restricted to the communications layer, per se, and not visible unless Channels were an enabled feature. To the ordinary user, with Channels disabled, the BD wouldn't be any different. For those with Channels enabled, this layering concept for the async wires could be presented - a simple toggle button on the toolbar would suffice?

I guess this is synonymous to pseudo-3D block diagrams?

[AristosQueue (NI)]

The layers concept, while definitely worth discussing, doesn't negate the need for drawing the channels when that layer is showing. At this point, that's the main thrust: if you had the channels drawn, how would they best draw to show these connections? If we solve that, providing an option that makes them transform into stubs of some sort is easy. 🙂

[Thoric]

My issue with Channels drawn like dataflow wires is they're not distinguishable. If they're hidable through layering, I'd be able to more easily idenitfy them by toggling the layers. If that's easily attainable then they can remain looking like wires.

When hidden, consider the numbering stubs I've drawn above. When unhidden they can be redrawn in completion, node to node.

In my head I'm already imagining a simple keyboard shortcut for switching the Channels layer visiblity. At the instant I notice a block diagram with Channels I can quickly switch their layer on and off to help with identification and interpretation. The switching action becomes their unique graphical attribute.

[Bob_Schor]

Boy, I was a sucker for the Fun Variant for Code Reuse.  I tried coding it, stopped midway and closed LabVIEW, moved the folder with my VIs, reopened, and promptly got "We apologize for the Inconvenience" (I logged a Discussion here).

So I finished the example using Pipes, and confused myself on what would happen (nothing -- it never starts).  Just for fun, I changed the Pipes to Tags, but now find I can't do the wiring because the Call by Reference nodes persist in naming themselves Pipes!  If I use the Actual VI and look at the connectors, they say Tags, but when I find the Strictly Typed VIs and choose the pattern, I get Pipes.

I'm going to play a bit more, see if I can't kick this hard enough.

Bob Schor

[AristosQueue (NI)]

The layers hiding does pose a problem of how do the connections get manipulated as you move code around. When you hide and then show again, do we just autoroute the wires? If we try to maintain their routes behind the scenes while they're hidden, we're likely to end up with any number of strange kinks and twists as code gets stretched with no regard for these hidden wires.

[Thoric]

I can imagine that when hidden their existence is still valid in the computational space, so the 'wires' are constantly considered when their owners are manipulated/moved, in the same way standard dataflow wires would be. They get stretched and rerouted in exactly the same way.

If an edit breaks the code, the error dialogue would provide the necessary descriptive help to indicate that the problem could lie in the hidden Channels layer. Perhaps the proposed toolbar icon for switching on the Channels layer could show a red X on it too?

Also: For some reason I can't see my posts, only your replies. To me the thread looks like you're replying to yourself!

[Mads]

AristosQueue wrote:

                       

Mads wrote:

I think the most intuitive solution would be to fully adopt the real-world analogy; wireless communication. Just drop the idea of a channel "wire".

That would pretty much defeat the purpose of the feature. The requirement is to solve the problem of the connection path not being visually depicted. The lack of a visual depiction of the transmission path creates problems for understanding code among many users and fails to express the API at conpane boundaries for reusable subcomponents.

Connection managers and the like have been -- and continue to be -- explored. There's a lot of other NI work going into that sort of thing. But none of them directly address the conpane and visual path issues the way channel wires appear to do. The trick appears to be finding a suitable rendering appearance, and different people have different thresholds for "this is different enough that I recognize it distinctively" over to "this is so radically different that it doesn't scan as part of LV". The goal is an appearance that hits that sweet spot for the majority of users.

In short, exploring variations on the visualization of the wire is open to discussion. Abandoning the entire point of the work is a good topic for a separate conversation, but irrelevant here.

                   

I agree that it is nice to have a visualization of the fact that there:

a)  is a connection

b) where the other end(s) of the connection are

c) what type of connection it is

For asyncronous communication I do not think that the "path" of the connection is relevant anymore though. It would be sufficient to have end-point indications which are hyper-linked to a connection list for example. This connection list (a single channel communication manager if you'd like) can in turn be hyper-linked to the block diagram of each end-point...and have different visualization modes on offer. Wires do their job well for "syncronous" connections, and should rule that domain without any look-alikes.

But if we are only discussing how to variate the look of the channel wire to minimize its de-clarifying impact I'll stay out (wireless 😉 ), and focus on other properties of the concept.