Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: different gauges and different lengths in connections #268

Open
2 tasks
daixtrose opened this issue Jan 15, 2022 · 13 comments
Open
2 tasks

feature: different gauges and different lengths in connections #268

daixtrose opened this issue Jan 15, 2022 · 13 comments

Comments

@daixtrose
Copy link

daixtrose commented Jan 15, 2022

  • IIUC it is not possible to have different gauges per cable. This is something we encounter quite often (data cables and current cables bundled for an electric engine)
  • Every connection might have a different length. This feature requires some indication of a center from which to indicate lengths in both directions, Might be tricky
@kvid
Copy link
Collaborator

kvid commented Jan 29, 2022

  • Different gauges per cable could easily be specified as an optional list of gauges (one for each wire), but to show them in the diagram, a new row for each wire might be needed (or alternatively just after the wire color).

  • To specify a different length for each connection, I suggest two new optional attributes length_left and length_right to specify a list of extra lengths for each wire at each end of the cable in the same unit as length_unit. These new values might perhaps be shown as spline labels at each side of the cable node, but then unconnected wire ends cannot show it's length. Maybe a new row for each wire might be needed for this purpose as well (or alternatively just after the source pin and just before the destination pin).

    • The length of each wire in a bundle is then length_left[i] + length + length_right[i].
    • The length of a cable is then max(length_left) + length + max(length_right) and we probably need a base_length or jacket_length multiplier to return just the length for sleeve lengths, etc.
    • Maybe length_left and length_right could be named left_end and right_end instead?
    • Maybe the current length should be named base_length or something similar?

This could be one way to show these values in a diagram:
issue268 gv txt
This is the manually edited Graphviz file, based on tutorial08.gv, that created the image above: issue268.gv.txt

@Halfwalker
Copy link

I would VERY much like to have different gauges per cable. For doing an automotive harness there are always multiple different wire sizes, and wire types within the harness. The view above would work very well.

If the different lengths facility above were to show up, I could definitely make use of that ...

@kvid
Copy link
Collaborator

kvid commented Mar 26, 2022

The two feature requests in this issue are independent and can be implemented independently of each other - maybe in two different PRs, but @formatc1702 wants to finish and merge PR #251 before any other PR that change code for diagram nodes. It seems he has not been able to work much on this project the last months, so it might take a while.

Anyone of us are free to create a PR based on the current dev at any time, but it would involve rebasing and re-adapting the code again after #251 is merged before any such new feature can be merged.

@kvid
Copy link
Collaborator

kvid commented Mar 26, 2022

I would also like to get more feed-back on how the new features should look like. The gauges feature is the easiest to implement, and should perhaps be done first. My suggestion above includes a summary of gauges for all wires just to the right of the wire count, but I have changed my mind, and I now suggest removing that because the same information is shown for each wire below.

@Halfwalker
Copy link

I kind of like the summary of gauges - it serves as a checkpoint. Handy to verify things, especially if you have a bundle of a LOT of wires. For example, the automotive wiring harness I'm working on has one section with 49 wires, and the main trunk with 86 wires.

Unfortunately, such large wire bundles get ... cumbersome. So I was thinking of another boolean flag for a Wire object compact_view. With that set to true, the wire object would not be expanded to show every wire inside, just the information blocks. All the wires entering would collapse down to a much smaller point, and exit the other side from a similar smaller point.

@kvid
Copy link
Collaborator

kvid commented Apr 24, 2022

@Halfwalker wrote:

I kind of like the summary of gauges - it serves as a checkpoint. Handy to verify things, especially if you have a bundle of a LOT of wires. For example, the automotive wiring harness I'm working on has one section with 49 wires, and the main trunk with 86 wires.

Your view is valuable input to how this proposed feature should work. Maybe such a summary should be optional? I would guess there are also cases where a summary doesn't add any insight, and the user might then prefer to avoid bloating the bundle object with repeated information.

Unfortunately, such large wire bundles get ... cumbersome. So I was thinking of another boolean flag for a Wire object compact_view. With that set to true, the wire object would not be expanded to show every wire inside, just the information blocks. All the wires entering would collapse down to a much smaller point, and exit the other side from a similar smaller point.

Please elaborate. A sketch would also help. Is this new feature something similar to a bus of wires that are often viewed in other drawing tools as a thick line that splits into a set of thin wire lines at both ends? However, I suggest you create a new issue for this as it seems not direcly related to the original issue.

@Halfwalker
Copy link

Yup, definitely optional. A simple flag would work, and in fact I would both use it and not use it. Heh, I mean I would do one render with it turned off, for an overview type view of the harness, and one with it turned on for the full detail to be used while building or verifying the harness.

The same would apply for the compact_view flag mentioned above. I think conceptually the view could be considered as a virtual junction point for all the wires coming in from a connector. With the flag off, each wire goes into the wire object individually, as usual
image
Whereas with the flag ON, each wire would go into the wire object to a single point, much like the blue wires for the ferrule-crimp here
image
Hrm, we could even get fancy ... Instead of a single point for every wire in the bundle, perhaps have a group-membership property for each wire. For example, all the power and GND wires could go into a POWER group, left side of engine go into a LEFT group and so on. Each group would have it's own single point in the wire object.

That group property could be specified at either the connector or the cable object in the yml file. I think at the connector is probably better, though perhaps both ? With one taking priority if both are defined.

connectors:
  EA2:
    hide_disconnected_pins: true
    pincount: 5
    pincolors: [BK, BKRD, IV, WH, BKRD]
    pinlabels: [Starter relay pin 5, EFI main relay OUT pin 5, NC, 7.5A Alt-S fuse, EFI relays]
    groups: [RELAYS, RELAYS, , POWER, RELAYS]
    pn: 90980-11413
    image:
      src: Supra_EA2.png

cables:
  Fusebox-cabin1: &template_main
    gauge: 20
    length: 2
    colors: [WHGN, GY, BU, BKRD, VTWH, GNYE, BK]
    groups: [SENSOR, SENSOR, POWER, POWER, RELAYS, RELAYS, POWER]

If this all makes sense and you think it worth doing, then I'll create a new issue

@martinrieder
Copy link
Contributor

@Halfwalker, have a look at my comment on the suggested twisting of wires:
#3 (comment)

The compact_view that you suggested could be done in the same fashion for either cables or connectors (and splices). They can both be hidden and shrunk using the fixed size tweak.

If you are to use the grouping on independend nodes (such as "virtual splices") then simply put them into a cluster. I would like to mention that Graphviz node attributes also offer a kind of grouping that would also impact edge layouting. It may be the better option, but I have not tried this yet.

I could think of use cases that combine both of these ideas. You could enforce some grouping through hidden connectors or hidden wire bundles. Additionally put them into a cluster, in order to align them in the layout. This really helps to get some nice looking results.

It would of course be nice to have this kind of grouping implemented, which needs to be discussed in a separate issue.

@kvid
Copy link
Collaborator

kvid commented Jul 6, 2024

@akikinho wrote in #378 about different lengths and gauges per wire:

I really hope in the future update the team implements it as it will be really helpful.

In my opinion, both (length: <int/float>[ ])and (gauge: <int/float/str>) should be of type List?

Originally posted by @akikinho in #378 (comment)

@martinrieder
Copy link
Contributor

It seems that the implementation of both, wire gauge and length is becoming too complex. We should rather split up this issue into separate ones.

  • Individual wire gauges
  • Individual wire lengths
  • "compact_view"

What needs to be discussed though, is how the suggested "grouping" would relate to the above. It might need to be implemented first if the other features depend on it. Or should it also be treated as an independent issue?

@kvid
Copy link
Collaborator

kvid commented Jul 7, 2024

@martinrieder wrote:

It seems that the implementation of both, wire gauge and length is becoming too complex. We should rather split up this issue into separate ones.

I agree. The three (or four) issues you list below seems quite independent of each other.

  • Individual wire gauges

As I've written earlier, this is probably the easiest to implement, by optionally accepting a list value for the existing gauge attribute, but implementing inserting the values for each wire should wait until #251 is merged into dev, or be prepared to rework the HTML generating code before a merge-in after #251.

  • Individual wire lengths

This requires some coordination with #306 and a new ‎NumberAndUnit‎ type added in #251, and perhaps with some ideas for #296.

We probably need to define a CableLength dataclass with a base length plus attributes for left and right ends accepting lists of the wire specific values. All the different values might optionally have different tolerances and possibly units (or require all values to use the same unit as the base length). We then need to define concise rules on how to map string values of length with simplified syntax into the dataclass attributes, so we still can support space separated base length and unit (as today) and most of the suggestions in #306, so only the advanced use cases need to specify such CableLength attributes individually.

  • "compact_view"

As I've written earlier, this is clearly a separate issue, and it might even be in conflict with the others, as it's not clear to me how to render the information that differ between wires with such a feature activated.

What needs to be discussed though, is how the suggested "grouping" would relate to the above. It might need to be implemented first if the other features depend on it. Or should it also be treated as an independent issue?

It depends on how many new and existing features should be affected by such a grouping. There are many features that need some kind of grouping of wires:

It has also been discussed if cables/bundles should have been defined as a hierarchical structure that could contain groups of other cable/bundles. That would probably be a major rewrite of the basic data structure, but it could solve many of the grouping needs. Update: It might also be combined with the designator dot syntax to allow both named and unnamed groups and multiple instances of the same group.

Grouping of pins in a connector might also be a future need, so it'll be nice to have in mind that a grouping feature might later become common for both connectors and cables.

@martinrieder
Copy link
Contributor

Note that the following suggestion would be in conflict with strict hierarchical structures:

YAML itself is well suited for hierarchical structures, but keep in mind that it limits flexibility when they are strictly enforced. WireViz already breaks the hierarchy by employing designators to link connectors and wires though connection sets. This non-hierarchical feature enabled some interesting additions like auto-generation and arrows.

@lutorm
Copy link

lutorm commented Nov 30, 2024

In my harness design attempts (see #431), I've resorted to making individual "cables" for all the different wire gauges and types in order to overcome the lack of the features mentioned here. This also made it possible to specify all the conductors in multi-conductor cables as individual wires in the no-longer-bundled cables, without duplicating them in the BOM.

Just being able to specify gauge individually would not solve the problems with multi-conductor cables. I think we have to think carefully about how to best specify wires. The current syntax seems aimed at describing flat-cables connected to PCBs by KK254 connectors in electronics, and then bandaided with the bundle declaration.

In order to truly describe both harness bundles, where the BOM should count the "outer" cables in the bundle, and connections at connectors, where each individual connector in every wire must be included, I think the bundle description has to be hierarchic.

In my project, where I'm generating a wireviz input file from my own, top-down description of a harness, I came up with a description like this:

  • A "cable types" section that describes the structure of a cable, like its color, is it shielded, but also a "multiple" section that specifies the types of subconductors. Here's what the description of M27500 multi-core shielded wire looks like:
  20TG1:
    gauge: 20 AWG
    color: WH
  20TG2:
    gauge: 20 AWG
    color: WHBU
  M27500-20-2:
    multiple:
      - 20TG1
      - 20TG2
    shield: true
    type: MIL-C-27500-20TG2T14
  • The connections are specified with a netlist, ie all the pins connected together. This also specifies the label for, and type of, cable used. In the case of a multiconductor cable, which of the conductors the net uses:
  CAN BUS HI:
    cable: CANBUS
    conductor: M27500-20-2.1
    net:
      - P4601 1
      - P251 1
  CAN BUS LO:
    conductor: M27500-20-2.2
    net:
      - P4601 2
      - P251 2
  CAN BUS GND:
    conductor: M27500-20-2.S
    net:
      - P4601 3
      - P251 3
  • Since there's no way to tell that all these nets are to be handled in the same M27500-20-2 cable, there's a separate "multiconductors" section that associates the nets routed together in the same multiconductor cable. (By being listed in this way, it is also checked that all the nets in the same cable go between the same set of connectors.)
  CANBUS: [CAN BUS HI, CAN BUS LO, CAN BUS GND]
  • And finally, this cable is routed between the connectors specified in the netlist, generating a bundle of cables that e.g. go between connectors P4601 and P251 which includes the cable labeled "CANBUS". In my code this is done automatically based on a graph of harness structure. If there are more than two connectors in the nets, then the cable is generated as several segments, which implicitly have to be spliced together at branch points. (I'm not specifying the details of the splices at branch points and connections, it's pretty self-explanatory when manufacturing although it would be nice to get it into a BOM.

I think the basic structure above is the minimum amount of information needed to describe the structure of a wire harness. There are potential extra things you might need, like specifying bundle coverings like heat shrink and transition boots that should go in the BOM, but you'd need a very complicated harness to not be able to keep track of that by hand.

The termination details can also get very complicated. In order to properly terminate those Canbus cables you are supposed to use a solder sleeve with attached braid, which is terminated to a ring terminal, which is screwed to the connector housing. The part no for the connector pins may depend on the gauge of the wire being crimped, etc. Designing a system able to describe this kind of detail would be difficult.)

Now, rendering a hierarchical cable structure like above in the current style such that it's intelligible would be, imho, impossible. You also need hierarchical renderings with an outline of the structure, separate details of the connectors, and details of the wires in the bundles.

Anyway, some thoughts that might give someone ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants