WireViz icon indicating copy to clipboard operation
WireViz copied to clipboard

[feature] Add heatshrink / sheathing information

Open formatc1702 opened this issue 4 years ago • 20 comments

formatc1702 avatar Jun 28 '20 11:06 formatc1702

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.

kvid avatar Jun 28 '20 11:06 kvid

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 avatar Jun 28 '20 12:06 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?

IMG_3665

formatc1702 avatar Jun 28 '20 12:06 formatc1702

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 avatar Jun 28 '20 12:06 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?

kvid avatar Jun 28 '20 12:06 kvid

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. automotive_wireharness

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. Cat-8_Shielded 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). MRJ21AD-01_500x500_View1

tim292stro avatar Jul 04 '20 16:07 tim292stro

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/

kvid avatar Jul 05 '20 00:07 kvid

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 :)

formatc1702 avatar Jul 06 '20 17:07 formatc1702

@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?

IMG_3665

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

Then, I modified the .gv file to include sheatings as subgraphs containing invisible wire nodes: sheathing-mod1.gv.txt sheathing-mod1 gv 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 sheathing-mod2 gv 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?

kvid avatar Jul 07 '20 19:07 kvid

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 7ee78b7ae7affcd7199bd8d66871b596d71255e7 commit (ancient history), eg. example 03 from 7151346e387e2a23827c06d669bef845f39a65e6. 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... ex03 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: ex03-1

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

formatc1702 avatar Jul 07 '20 20:07 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.

formatc1702 avatar Jul 08 '20 05:07 formatc1702

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

graph(2)

graph.gv.txt

SnowMB avatar Jul 22 '20 14:07 SnowMB

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 https://github.com/formatc1702/WireViz/issues/31#issuecomment-650744594, but I didn't succeed.

kvid avatar Jul 22 '20 17:07 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 https://github.com/formatc1702/WireViz/issues/31#issuecomment-650743390:

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 avatar Jul 22 '20 18:07 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 https://github.com/wireviz/WireViz/issues/270#issuecomment-1029535877?

kvid avatar Feb 16 '22 20:02 kvid