[feature] Add heatshrink / sheathing information

[formatc1702]

No description provided.

[kvid]

I have been thinking of a tubing attribute for both connectors and cables/bundles, but I guess we might end up with many of the same attributes for each tube as in the other entities, like color, diameter/size, length, type, product number, etc. Is it possible to define it as a container entity that can contain one or several cables, and perhaps also connector(s)? Is it possible to use the the Graphviz group function? If not, the cable HTML tables could be embedded as cells in a large HTML table of the container node.

[formatc1702]

It is possible to use GraphViz' subraph function to collect a bunch of cables. Of course this breaks if you want one cable to exit the harness while the others continue on.
The nice thing is that you can define the subgraphs at the very end of the GraphViz code, see link below... perhaps a new section at the end of the YAML file could be used to define these 'superbundles'... something like this:

cables:
  W1:
    ...
  W2:
    ...
  ...

sheathing:
  S1:
    cables: [W1, W2, W3]
    type: abc
    attr: etc
    ...

Modified Example 02

[formatc1702]

Here's what a typical harness might look like, the question is how you would represent this in WireViz, and subsequently, GraphViz...
Where would you place the nodes for each cable's info?

[kvid]

How about splitting a cable into one node in each independent subgraph, but only one of them needs the annotations? The extra cable nodes can be "invisible" to force the wires through the subgraph. If you want the annotations outside of all the subgraphs, then add invisible nodes for each subgraph and have the real cable node outside.

[kvid]

You might need som way to specify distance from a connector to a sheathing? Can this be used to calculate the order of the invisible nodes along the harness?

[tim292stro]

As discussed with formatc1702 over email, that type of container could also be useful as a conduit, raceway or other type of container than just a simple sheath.

These sheaths may also need to overlap, as in the case of an automotive wire harness - where an overall plastic split loom may have a smaller split loom over a segment of the harness going to one sensor, but as it joins the main bundle, the split loom may be required to continue inside the main split loom of the major harness for several inches to allow for binding strength on the loom.

This could also be related to my offline suggestion that shielding be definable (both foil type and braid) - some types of cable have sub bundles, specifically as an example thinking Cat-7/Cat-8 cables where single twisted pairs may be shielded, and then the overall cable may also be shielded. This informs that there should not be an arbitrary limit to the number of "layers" in the visualization.

In a practical harness, how these shields are managed is very important - for example as a set of Cat-8 cables comes to a punch-down patch panel, the overall shield braid may be pulled back to a common ground for the panel, while the overall foil continues to manage the bundles of twisted pair to the final punch-down. It's also important that the shield continue along with the twist as close as possible to the punch-down to ensure cable performance.

Speaking of Cat-7/Cat-8, I'm also reminded of the MRJ-21 cable type found in high-density data centers where 6x cat-5 or higher cables are terminated at one connector, then they may fan out to individual RJ-45 connectors. Another case of an overall shield and sheath needing to be managed in a multi-cable, multi-conductor harness. The MRJ-21 end allows for a 3:1 space-claim reduction (about the space of a stacked pair of 2x RJ-45 allows 6x effective RJ-45 worth of ports).

[kvid]

I don't know how (if possible) to create a subgraph containing another subgraph. It seems each node can only be included in one subgraph. I did try some alternatives here: https://dreampuf.github.io/GraphvizOnline/

[formatc1702]

I recommend using Edotor.net for playing around with GraphViz. The editor is brilliant.
And if you look under Load sample -> Clustering 2, you will find the answer to your nested subgraph question :)

[kvid]

@formatc1702 wrote:

Here's what a typical harness might look like, the question is how you would represent this in WireViz, and subsequently, GraphViz...
Where would you place the nodes for each cable's info?

I started creating a .yml file to generate something similar:
sheathing.yml.txt
sheathing.gv.txt

Then, I modified the .gv file to include sheatings as subgraphs containing invisible wire nodes:
sheathing-mod1.gv.txt

I assume it is possible to remove the extra wire node frames, but for now, it is useful to see these nodes.

Then, I modified the .gv file even more to include heat shrinks as subgraphs containing an invisible wire node plus a connector:
sheathing-mod2.gv.txt

Now, it looks messy. I don't know why it suddenly ends up like this.

Do you think a variation of this might be useful? Any suggestions to improve this?

[formatc1702]

Now, it looks messy. I don't know why it suddenly ends up like this.

I think GraphViz always tries to minimize the sum of all edge lengths in the graph. If W3 were below Cable sheathing 2, it would end up with longer edges.
This is analogous to a problem I was having with wire bundles some time ago. I used subgraphs to draw a dashed line around invisible nodes, two per wire of the bundle to get a straight section in the middle for labeling, and the same thing would happen.

See examples pre 7ee78b7 commit (ancient history), eg. example 03 from 7151346. Wires are supposed to be alternating red/black, but GraphViz tries to be clever and rearrange them "optimally". I tried doing invisible edges between the invisible nodes of a bundle, to no avail...

Congratulations! You have rediscovered a behavior that I was able to fix by starting to use HTML tables with ports for each wire, because WireViz doesn't mess with those... Now we are one layer above, creating "superbundles".

For comparison, here's what it was supposed to look like all along, and what it looks like now, after the fix:

I can't offer a solution right now, but I thought I would share.

[formatc1702]

To answer your other question...

Do you think a variation of this might be useful?

Absolutely! I don't know how we could auto-generate the invisible nodes in the correct position, or how hard that is to implement, but if we can figure it out, and somehow override the edge length minimization issue, I think you're on to something here.

[SnowMB]

You can use rank=same to clean up node placement. https://graphviz.org/doc/info/attrs.html#d:rank

graph.gv.txt

[kvid]

Good idea. It might not be easy to automatically select which nodes to have the same ranks, but maybe we could have an optional YAML entry like this:

samerank
    - [X3, X4, X2]
    - [W1, W2, W3]

I did a few experiments with rank=same when trying to obtain a layout similar to #31 (comment), but I didn't succeed.

[kvid]

Another thing that might help, is to combine all invisible nodes on the same rank inside a sheathing into a common invisible node to avoid that Graphviz swap their order.

Edit: Using a variant of the syntax suggestion from #31 (comment):

sheathing:
    Cable sheathing 1:
        cables: [W1, W2, W3]
        length: 4 cm
    Cable sheathing 2:
        cables: [W1, W2]
        length: 4 cm
    Heat shrink 1:
        cables: [W1, X4]
        length: 2 cm
    Heat shrink 2:
        cables: [W2, X3]
        length: 2 cm
    Heat shrink 3:
        cables: [W3, X2]
        length: 2 cm

I'm not sure how easy it will be to automatically determine where to create invisible wire nodes and their order - maybe based on the order in the specification above? Otherwise, it might be possible to add a numeric suffix to the wire entries above to indicate an invisible node and the order between them.

If some cables/wires break out of a tubing/sheathing somewhere in the middle, how can that be specified? Can it be solved by splitting it in two consecutive tubing entries with the same name, but different contents before and after breaking out? Or maybe something like this:

sheathing:
    Long cable tube:
        sections:
        -
            cables: [W1, W2, W3]
            length: 20 cm
        -
            cables: [W1, W2]
            length: 10 cm
        notes: Make a 5 mm hole in the tube where W3 breaks out

[kvid]

Inspired by a recent issue, I pick up this old thread again. How about specifying each heatshrink section as a separate bundle and splice the wires going through several bundles using «virtual splices» as I suggest in #270 (comment)?

[izyb]

Hello, I am new to wireviz and am trying to spec a cable that has an external ferrite attached. The type of diagram I am looking for is exactly like what SnowMB commented above, just replace the "Cable sheathing 1" label (for example) with the ferrite PN. Then I could add a note box that gives details about the position of the ferrite along the cable bundle or something.

I just wanted to point out that this functionality could also support ferrites and would love to see this implemented ASAP! :)

[martinrieder]

@izyb please see #155 where cable glands were requested. This is closer to what you expect.

The difference is that sheathing and heatshrinks are applied to the cable. They have an impact on wire length, while ferrites and cable glands would not. The latter are just components that are added to the BOM. They would be treated similar to a connector which does not have any length information.

[kvid]

@izyb - As I also partly suggested in #155 (comment), you can today use image, notes, and additional_components of a cable to describe this. However, I agree that a more dedicated functionality could be useful.

Please add your use case in #155 to aim for a common solution.

[martinrieder]

I am wondering, whether the cable labelling suggested in #222 would also belong to this issue or over into #155.

[kvid]

@martinrieder wrote:

I am wondering, whether the cable labelling suggested in #222 would also belong to this issue or over into #155.

That might be a good idea? I suggest you make such a comment in #155 - it doesn't really belong here. If @izyb doesn't present his use case himself, you can mention that as well, and link to his comment here.