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] Automatic ordering of wires in a wire/bundle #275

Open
Halfwalker opened this issue Feb 12, 2022 · 2 comments
Open

[feature] Automatic ordering of wires in a wire/bundle #275

Halfwalker opened this issue Feb 12, 2022 · 2 comments

Comments

@Halfwalker
Copy link

I'm still working out how to use WireViz for an automotive wiring harness, and one of the issues is that there are a LOT of wires. Typically it goes from several large-pin-count connectors in the cabin where the engine ecu is (ecu connectors, harness-to-body connectors etc.) to a large bundle or wires through the firewall to the engine compartment. From there it snakes around, branching off several times, each branch may have quite a few connectors on it.

It's the representation of the wires that gets tricky. For example, that main bundle going through the firewall may be 100+ wires. Probably too many to have in a single wire-object, so one would break that up into logical chunks - would still need a way to group them together on the diagram though, like one can with connector-objects, using tweaks

tweak:
  append: |-
    subgraph cluster1 {
      color=blue
      EA1
      EA2
    }

I was only able to get that to work with connector-objects, trying with wire-objects would throw an exception.

Even broken up into several wire-objects, there are still a lot of wires in each one. And immediately one runs into keeping things in order and neat. Discovering that there is an unnecessary wire crossing means going back and re-ordering both the connector pins AND the wire order.

It would be really nice if WireViz could optimize the order of wires in a wire-object to minimize the amount of wire crossings on either size of the wire-object.

Simple example from #27
image
The W1 wire-object could be optimized automatically to order the pins as [Key:T, Key:R, Key:S] to remove the crossings.

This would likely be an iterative process to find the minimum number of crossings - one would not be able to remove them ALL every time. But it would help let the computer do what computers are good at, and remove the drudgery of manual tweaks to make things look good.

Another example (snipped from full source yml)

connectors:
  EA1:
    hide_disconnected_pins: true
    pincount: 8
    pincolors: [BU, WHGN, BK, BKYE, IV, BKRD, WH, GY]
    pinlabels: [AC clutch relay pin 5, AC clutch relay pin 2, Starter relay pin 1, EFI main relay IN pin 3, NC, NC, NC, EFI main relay CTL pin 1]
    pn: 90980-10897
    image:
      src: Supra_EA1.png

  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]
    pn: 90980-11413
    image:
      src: Supra_EA2.png

  A4:
    hide_disconnected_pins: true
    pincount: 4
    pincolors: [GNYE, VTWH, IV, BU]
    pinlabels: [AC lock sensor, AC lock sensor, NC, AC Magnetic clutch]
    pn: 90980-10942
    image:
      src: Supra_A4.png

cables:
  Fusebox-cabin2:
    gauge: 20
    length: 2
    colors: [WHGN, GY, BU, BKRD, BK]
    wirelabels: [t, t, t, +12V Switched, t]
  Fusebox-cabin3:
    gauge: 20
    length: 2
    colors: [BU, VTWH, GNYE]

connections:
 -
    - Elite_B26: B11
    - Fusebox-cabin1: 4
    - [X]
    - Fusebox-cabin2: 4
    - EA2: 2
  -
    - IJ1: 20
    - Fusebox-cabin1: 7
    - [X]
    - Fusebox-cabin2: 5
    - EA1: 3

image
The BKRD(4) and BK(5) wires in Fusebox-cabin2 wire should be swapped. That means editing the two connections involved to update the wire number, and the cable Fusebox-cabin2 to update the order of the colors, AND the order of those wires in the connector-object to the left. Same for the GNYE (3) wire from Fusebox-cabin3 to connector A4 - it should move from position 3 to position 1.

Not fun, and prone to errors, especially when dealing with connections with 38 pins and high-count cables.

The pins in the connector can also be moved to accommodate wire crossings. We don't really about the order of pins in the connector object on the diagram, since pins aren't just in a single line/column in real life. It would be nice if they were in pin order, but not critical. I wouldn't mind if they were out of order if that cleaned up the diagram ...

Perhaps a syntax change/option would help for this. Right now connectors define pins as a list, which is order-dependent. 3rd one defined is pin 3 etc. Pinlabels are defined the same way - see the connectors above. This means making sure that the pin labels are in the correct order to match the pin colors ...

How about defining pins individually ?

  A4:
    pins:
      - pin: 1
        label: AC lock sensor
        color: GNYE
      - pin: 2
        label: AC lock sensor
        color: VTWH
      - pin: 3
        label: NC
      - pin: 4
        label: AC magnetic clutch
        color: BU
@kvid
Copy link
Collaborator

kvid commented Feb 12, 2022

Thank you for an interesting use case. I've not had the time to read all the details yet, but it might help you a bit to specify unique wire colors or labels instead of wire indices in connections. See documentation for the different options.

Another tip to simplify the input: If you need labels for only a few of the connector pins (or wires), then the pinlabels/wirelabels list entries can be ~, null, Null, NULL, or an empty quoted string to indicate empty, i.e. no label, and such empty entries at the end of the list need not to be present (i.e. a shorter list is accepted). The same applies for pincolors.

@kvid
Copy link
Collaborator

kvid commented Feb 14, 2022

@Halfwalker wrote:

It's the representation of the wires that gets tricky. For example, that main bundle going through the firewall may be 100+ wires. Probably too many to have in a single wire-object,

WireViz can handle a lot of wires. I just tried connecting a 200 pin connector to a cable with 200 wires. The diagram gets tall, but it works.

so one would break that up into logical chunks - would still need a way to group them together on the diagram though, like one can with connector-objects, using tweaks

tweak:
  append: |-
    subgraph cluster1 {
      color=blue
      EA1
      EA2
    }

I was only able to get that to work with connector-objects, trying with wire-objects would throw an exception.

To Graphviz, there is no difference between connector objects and cable objects - they are all nodes - that can be grouped in clusters if you want. However, when the designators contain certain characters they must be quoted, and e.g. the dash in your "Fusebox-cabin2" is such a character. WireViz uses a library to generate the .gv output, and such designators are then put in quotes when needed, but in the tweak.append text, the user must take care of this manually. Knowledge of the .gv output contents from WireViz and the dot language used is needed to use the tweak feature correctly.

Even broken up into several wire-objects, there are still a lot of wires in each one. And immediately one runs into keeping things in order and neat. Discovering that there is an unnecessary wire crossing means going back and re-ordering both the connector pins AND the wire order.

It would be really nice if WireViz could optimize the order of wires in a wire-object to minimize the amount of wire crossings on either size of the wire-object.

Graphviz does the optimization on positioning all elements in the diagram, but the order of wires in a cable and the order of pins in a connector are both fixed by WireViz based on the order in the user input. This is by design because in most cases the order is important and often represents a physical order as well. When using color_code, the wire colors are also determined by their order.

The number of wire crossings depends heavily on how Graphviz is positioning the diagram elements, and I don't think it's trivial to optimize an automatic re-ordering of wires or pins to improve the end result, but ideas or PRs are welcome.

This would likely be an iterative process to find the minimum number of crossings - one would not be able to remove them ALL every time. But it would help let the computer do what computers are good at, and remove the drudgery of manual tweaks to make things look good.

I agree that computers normally are better suited to try out different re-orderings, but to determine which result is best, the algorithm needs to know the number of crossings, and that is not easy to read from the output files, as far as I know, but again - ideas or PRs are welcome.

The BKRD(4) and BK(5) wires in Fusebox-cabin2 wire should be swapped. That means editing the two connections involved to update the wire number, and the cable Fusebox-cabin2 to update the order of the colors, AND the order of those wires in the connector-object to the left. Same for the GNYE (3) wire from Fusebox-cabin3 to connector A4 - it should move from position 3 to position 1.

Not fun, and prone to errors, especially when dealing with connections with 38 pins and high-count cables.

If specifying wires by their unique color or label in the connections, then you don't need to change the connection order when re-ordering some wires.

The pins in the connector can also be moved to accommodate wire crossings. We don't really about the order of pins in the connector object on the diagram, since pins aren't just in a single line/column in real life. It would be nice if they were in pin order, but not critical. I wouldn't mind if they were out of order if that cleaned up the diagram ...

If specifying pins by their unique label in the connections, then you don't need to change the connection order when re-ordering some pins.

Perhaps a syntax change/option would help for this. Right now connectors define pins as a list, which is order-dependent. 3rd one defined is pin 3 etc. Pinlabels are defined the same way - see the connectors above. This means making sure that the pin labels are in the correct order to match the pin colors ...

How about defining pins individually ?

  A4:
    pins:
      - pin: 1
        label: AC lock sensor
        color: GNYE
      - pin: 2
        label: AC lock sensor
        color: VTWH
      - pin: 3
        label: NC
      - pin: 4
        label: AC magnetic clutch
        color: BU

That is a good idea. It should be possible to accept an input syntax similar to your suggestion as an alternative to the existing syntax, and WireViz can easily map the values from such an input into the current data structure. This way, users can select the easiest syntax for each connector and cable. Implementing such a feature should be quite easy and only involve __post_init__() of the classes Connector and Cable, but I suggest raising a separate feature request issue for it, as it is independent from the automatic ordering in #275.

Edit: To support such a feature also for cables/bundles, then I guess we need a new attribute wires that can take a list of dicts. Such a syntax alternative might also be an advantage when new attributes per wire is requested, like in #56 or #268. However, supporting custom wire naming/renumbering as is already supported for connector pins, would require numerous changes in several source files, and should therefore perhaps be out of scope for now.

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

2 participants