Some wiring ideas...

[X.]

I have no pretension to originality here but could there be some flexibility in our wiring options? I know there is a fine line between a cluttered VI with bad architecture and true limitations of the LabVIEW editor, but let's see where this thread goes...

- allow straight but not vertical/horizontal wires to be drawn (I am not suggesting Bezier curves although that would be neat!):

The cross above is both illustrating a bad wiring example (but I hate to have to draw a svastika each time I am in this situation) and a possible solution. This opens the way to a lot of potential abuses (think spider web) but IMO it is more than compensated by the added flexibility.

- allow bundling of wires, as electrical companies are doing to neatly bury cables.

Replace this:

by that (imaging nice tube parts at the intersection of horizontal and vertical sections):

In other words a simplified bundle/unbundle object that would allow compacting a lot of wires together in a "tube" for display purpose only (so at compile time it would actually NOT bundle/unbundle anythings at all).

- Better yet, I would suggest following the "buried cables" image a step further and offer the option to "burry" wires like this:

- Am I starting to suggest a 3D version of LabVIEW (with a backplane and a front plane in the diagram)?

My 2 cts.

[SteveChandler]

Parent already had the link 🙂 http://lavag.org/topic/10670-wired-wires/

[X.]

No kidding, I am dead serious about this idea!

I just realized that I could as well have suggested wireless VIs... 🙂

[dthor]

---

@X-) wrote:

(so at compile time it would actually NOT bundle/unbundle anythings at all)

---

Why would this be an advantage? To my knowledge, bundle and unbundle costs essentially nothing in build time, execution time, CPU cycles, or any other measure that I can think of.

I understand where you're coming from (I hate those svastikas too) but I don't think this idea will get anywhere 😕

[X.]

I don't expect NI to jump on this idea either...

"Hiding stuff is not a good strategy", "Cluttered diagrams requiring such a drastic treatment should be simplified using subVIs", "Diagram layout should favor straight wires for better legibility", etc, the objections are easy enough.

However not everybody can reach perfection and I must say that a diagram I recently wrote over a period of several weeks has way too many wires to be easily legible.

Could I use subVIs to simplify it? I don't think so.

However, I could see myself selecting a VI on the diagram, pressing a magic key selecting all the wires connected as INPUTS to this VI and selecting "bundle in a pipe" option. The editor would then try to get back as far as possible trying to bundle all these inputs towards their source (and stopping of course when a wire needs to be connected to a nearby source (be it a control, shift register, VI, etc).

Selecting the pipe would highlight the wires coming in and out of it. The pipe could be "buried" or moved out of the way (in some baseboard-like structure around the diagram)?

To get back to the wireless VI joke, I guess I forgot that it is somehow already here (queues, notifiers, etc).

[GregR]

This idea basically covers 4 concepts:

• straight diagonal wires
  Don't care for. Auto wire routing and auto diagram layout should be able to handle these. If they don't, then report that and it can be worked on.
• a new kind of wire bundling
  I'll cover this below.
• teleportation of wiring
  Don't care for. Too much potential for abuse. I don't even want to contemplate learning someone else's VIs when they use this feature.
• editor features for easily creating wire bundles (from the later comment)
  That could be very interesting even applied to clusters as they are defined today. I could see taking advantage of that.

The idea of combining wires into a "bus" (name influenced by hardware guys) comes up about every year or 2 internally. The answer always comes down to the same thing. How different would this really be from a cluster? The answer so far has been not enough to be worth the effort. The key is providing functionality distinct from the cluster and solving use cases that aren't easily handled by clusters.

Here is the angle on it that I think is the most compelling. Rather than the hardware bus or buried cable paradigms, I prefer to think of it as a cable organizer. You know, those black coil things that are supposed to make the back of your desk look all neat. With a cluster you have to know all the elements when the cluster is created. With a cable organizer, you can have another cable go in whereever you want. With a cluster you can read an element as many times as you want. With a cable organizer, the cable exits once and then its gone. So the key features would be arbitrary entry/exit points but with single in/single out for each wire. 

[X.]

GregR,

thanks for commenting on those ideas.

I beg to differ on the straight diagonal wires. Autowiring and diagram clean-up definitely avoid ambiguous intersections and overlaps but the resulting paths are usually not easy to follow. As an old friend of mine once said, "the shortest path between two points is a straight line" (or maybe that should be attributed to Euclid?) and for whatever biological/evolutionary reason, it also appears to be the way the human brain is wired to function (the human brain on the other hand seems to have been wired by a LabVIEW beginner - or may be "diagram-cleaned"-, as scientists are still trying to figure it out).

I would agree that limiting this option to short distances (say from an unbundle to a nearby bundle of expandable function) might help with legibility. What I am trying to solve here is the "fractal svastikas" aspect of some wire-dense diagram neighborhoods.

The trench suggestion was added to deal with long-distance diagonal (and pipe/bus) wiring. I accept that this could be dangerous.

Related to the "bundling wires reaching a VI" idea is the idea of allowing VIs (and other objects) connected to a wire (or multiple wires) to be highlighted in a simple manner:

Right-clicking a VI (but that could be extended to any objects) would allow highlighting upstream and/or downstream connected VIs, objects, controls, indicators, Property Nodes, Shift Registers, you name it, and of course wires.

In the figure above, the upstream VI to the right-most red highlighted VI is surrounded by a dotted rectangle, with the connecting wire in red. Green colors correspond to controls or property nodes connected to the VI (and the corresponding wires).

Much to be added to this idea, but you hopefully get the gist of it...

[SteveChandler]

GregR wrote: Here is the angle on it that I think is the most compelling. Rather than the hardware bus or buried cable paradigms, I prefer to think of it as a cable organizer. You know, those black coil things that are supposed to make the back of your desk look all neat

Ah yes it is called "loom". Would that support wires going in each direction?

[X.]

Another wiring idea:

when using the conveient "Create & Wire Unwired Cases" in an Event structure, DO NOT DISPLAY (and try to route around the mess in each case) the wires. They will indeed be conveniently hidden in ducts in the Event structure "walls". If we want to check which input (resp. output) they are coming (resp. exiting) from, the "Find" function is good enough.

[RavensFan]

X,  your idea is pretty similar to a bunch of other ideas.

Take a look at:

A better way to define the output of unwired output tunnels

Allow Output Tunnel of Case Structure to Use Previous Value if Unwired (Latch)

wire jumping across case structure

[X.]

Great. I'll go and visit and vote for them. Thanks for the links.

Edit: I actually had already voted for Christian's idea. I need to read it again 🙂

Edit 2: actually, I think it duplicates this more than any of the other ideas linked to above, although I am not a big fan of the proposed visual clue...