[feature] Top-down generation of harness

[lutorm]

Hi,
I find myself in need of designing a pretty complicated harness (for a small aircraft) so I'm looking around for options and came across Wireviz. I couldn't figure out whether there's a distinction between a wire and a bundle in Wireviz:

In my mind, a harness typically has an acyclical graph structure, with copper wires going between the various nodes (generally leaf nodes, but not necessarily in the case of in-line splices) in the graph. A "bundle" to me denotes an edge in this graph. So, a wire from X1 to X2 will traverse several different bundles of different lengths, bundled together with different sets of wires in any of them, on its way between the end points.

To me, the real utility of defining the harness would be to be able to input the harness physical layout, ie the bundle graph with edge lengths, separately define the electrical connections, i.e. the wires, connecting the nodes, along with their color/gauge, and then have the software calculate where the wire goes and how long the wire needs to be. It looks like this is not the problem Wireviz is attempting to solve?

[kvid]

Hi, I find myself in need of designing a pretty complicated harness (for a small aircraft) so I'm looking around for options and came across Wireviz. I couldn't figure out whether there's a distinction between a wire and a bundle in Wireviz:

In my mind, a harness typically has an acyclical graph structure, with copper wires going between the various nodes (generally leaf nodes, but not necessarily in the case of in-line splices) in the graph. A "bundle" to me denotes an edge in this graph. So, a wire from X1 to X2 will traverse several different bundles of different lengths, bundled together with different sets of wires in any of them, on its way between the end points.

• Your definition of a bundle seems to be equal to how this term is used in WireViz.
• A cable or bundle in WireViz currently consist of one or more wires with a common length.
• Variations of extra wire lengths at both ends is suggested in feature: different gauges and different lengths in connections #268 (comment)
• How to make a wire continue through several bundles is suggested in Need the ability to go from connector to wire to wire to connector #270 (comment)

To me, the real utility of defining the harness would be to be able to input the harness physical layout, ie the bundle graph with edge lengths, separately define the electrical connections, i.e. the wires, connecting the nodes, along with their color/gauge, and then have the software calculate where the wire goes and how long the wire needs to be. It looks like this is not the problem Wireviz is attempting to solve?

In WireViz the electrical connections are specified for each connection set - which is one or more connections sharing the same sequence of alternating connectors and cables/bundles, i.e. a botton-up approach connecting each segment instead of the top-down approach in your request to connect leaf nodes.

However, WireViz calculates the sum length of wires with equal properties for the BOM.

[kvid]

Maybe the top-down approach in your request can be solved in a preprosessor that produces the WireViz YAML input. Please suggest how you would like to specify the top-level graph and connections.

[lutorm]

Yeah, I'm pondering how I would describe the necessary input data now, so I'll post back if I come up with anything.

Did I understand correctly that it's now possible to put different gauge wires in a bundle? I haven't seen an example of the syntax to do so, though.

[kvid]

[...]
Did I understand correctly that it's now possible to put different gauge wires in a bundle? I haven't seen an example of the syntax to do so, though.

No, the current version doesn't support this yet, but this feature is suggested in #268. See my comment in that issue linked in my comment earlier today for how such a feature might look like.

[lutorm]

Ok, I have started working on a routing processor per what I outlined above. (I edited the issue title to reflect this.) In order for the result to be renderable in Wireviz, though, it would be a requirement to support:

• Different gauge wires in a bundle
• Several shielded wires in a bundle (along with other conductors)

If I get this to work, the resulting harness will likely have of order 30 nodes and 500 conductors, so I suspect that the result will be too complicated for graphviz to render in comprehensible fashion. I saw a discussion of an "outline mode" where, rather than rendering all the wires, it just renders a fat line for the bundle along with a table of the wires in the bundle. This would be fully sufficient for my purpose, rendering all the wires will just make a mess, I think.

[lutorm]

So the generation code appears to be working on a small test file I made up. However, the result is not pleasant. Even for such a small case, the result is pretty much unintelligible. It's possible the generated file is incorrect, but I figured I'd throw it out here and see if anyone has suggestions for improvements in the generated file to make it better.
wireviz.txt
harness.txt

Harness.txt is the source file for the generation, in case anyone's interested. The basic topology of the harness is given by the "edges" dict, where the edge is named for the two nodes it connects. The nodes named J* are all harness branch points and not connectors (although the generated wireviz output generates them as a simple connector.)

The connections are in the netlist dict, which specifies the connectors the net connect to, the lable of the cable connecting it, and the type of conductor. The conductors can be hierarchical, shielded, multiconductors, but since wireviz can't handle that anyway, I just used the first conductor in the multiconductor cable and dropped the others in the generated output. Since they all are routed together and just connect to different pins, they're not super interesting anyway.

When the harness passes a physical connector, the conductors in the harness that don't connect to any pins on that connector are connected to instances of the autogenerated simple "X" connector. I was hoping that would keep them just flowing along with the rest of the conductors in the wire.

One particular problem evident in the generated image is that some lines take the wrong direction through the wire boxes. I have assumed that a connection entry is nondirected, ie a connection P1->W1->P2 is equivalent to P2->W1->P1, since obviously electrically there's no difference. Does the wireviz rendering somehow rely on the direction of the entries?

Also, when a "connector" is just a branch point in the harness, like J1 and J2, I've generated those as real connectors which the wires connect to. Is this the best way to do it? I could also generate individual splices for every conductor, but I thought using a single "connector" would keep everything together. Maybe it just makes it worse since it apparently can't decide which end to make the wires come out?

[kvid]

Thank you for sharing your work. I've not yet looked into the details, but I must answer your question "Does the wireviz rendering somehow rely on the direction of the entries?"

Yes, all connection sets are assumed by WireViz to be from left to right to enable the YAML author to influence the diagram layout. See also my explanation in #293 (comment)

[lutorm]

Yeah, I saw that discussion after I had posted my question. Sorting the connections consistently improved the look a lot. I also reworked the whole-harness diagram to generate a separate wireviz cable for every cable in a bundle, since that's the only way I could figure out to get the BOM to generate correctly. Currently it looks like this:

I think the full diagram will never be useful, but the BOM will be. An "overview" mode that doesn't render the individual wires would still be very nice, though.

Instead I focused on getting views of individual connectors to generate. These look like this, which is pretty nice and certainly will be good enough to manufacture the individual connector endpoints.

[kvid]

• If you consider splitting your project into several harnesses, but still need an overall BOM, then I recommend to look at BOM From Multiple Cables #267.
• See [feature] Shield/Screen individual cores #330 for several shielded wire groups in the same cable/bundle.
• See feature: different gauges and different lengths in connections #268 for different gauges and lengths in the same cable/bundle.
• You might also suggest supporting other attributes diifferent for each wire, e.g. in a similar way as the latter issue above.
• You might also suggest an option to include the wirelabel in the BOM description.