Make connecting components together easier and more flexible

[formatc1702]

Fixes #67.

[formatc1702]

Input test file for this branch:

connectors:
  X1: &proper
    type: proper connector
    pincount: 4
  F1:
    auto_generate: true
    # category: ferrule
    pincount: 1
    color: PK
  F2:
    auto_generate: true
    # category: ferrule
    pincount: 1
    color: VT
  X2:
    <<: *proper

cables:
  W1:
    wirecount: 4
    color_code: IEC
  W2:
    category: bundle
    wirecount: 4
    color_code: DIN
  W3:
    wirecount: 4
    colors: [RD, YE, GN, BU]
  W99:
    wirecount: 2

connections:
  - # very long connection list, alternating connectors and cables
    - X1: [1-4]        # connector, as usual
    - W1: [2,1,4,3]    # wire, as usual
    - [F1, F1, F1, F2] # list of ferrules, may be different types
    - W2: [1-4]
    - F2               # single ferrule, will be auto-duplicated
    - W3: [2-4,1]
    - X2: [1-4]
  -
    - X1:  [1-2]
    - W99: [1-2]
    - X2:  [1-2]

Current output (work in progress!!)

[kvid]

Would a connector attribute hide_single_pin with default True value help to aboid a lot of special cases for ferrule in the code?

[formatc1702]

Would a connector attribute hide_single_pin with default True value help to aboid a lot of special cases for ferrule in the code?

Yes, I am working towards removing ferrules altogether, and implementing something like you suggest.

The new attribute autogenerate (no underscore in the future) will only work for connectors with a single pin (ferrules, Wagos with one electrial node only, wire nuts, ...) that don't have to be accessed again in another connection set after being created, and thus can receive internal, auto-incremented identifiers that the user does not need to know.

This example would not use autogenerate for the Wagos since you can't define the three-way splice in one connection set, so you need access to them again. Hoewever, a simplification is in the works here as well, the goal is to make the code work like this:

cables:
  C1: &cable
    type: Mains cable
    colors: [BN, BU, GN] # GN to be replaced with GNYE for PE
    gauge: 1.5
  C2:
    <<: *cable
  C3:
    <<: *cable

connectors:
  S1: &wago
    pincount: 1  # will appear as ferrule since hide_single_pin will default to true, like kvid suggested
    manufacturer: Wago
    manufacturer_part_number: 221-413
    color: OG
  S2:
    <<: *wago
  S3:
    <<: *wago

connections:
  -
    - C1: [1-3]
    - [S1, S2, S3] # these have autogenerate set to false, since we need to manually assign names...
    - C3: [1-3]
  -
    - C2: [1-3]
    - [S1, S2, S3] # ...to be able to use them here!

[formatc1702]

@kvid perhaps you have some ideas on how to implement the TODO's I earmarked in the comments above?

Overall I'm quite happy with this refactoring, except for the special case of loops. I'm even considering adding a new section in the YAML file called loops or similar, and separating it from connections, which should be between different components.

Or maybe even add a loops property to the connector itself, since it concerns only one, and potentially a tiny bit of wire. #48 is related but not 100% identical, since I guess some connectors' pins can be shorted internally without requiring a wire loop.

The whole ferrule vs. connector thing and hiding single pins is on my radar, don't worry.

[formatc1702]

It's the responsibility of the user to make sure it's really a single-pin component. If not, the code doesn't care and simply assumes you want to connect pin 1. Same for the next elif.

[kvid]

I'm afraid I might have to wait until late this evening to test what's stored in the yaml_data['connections'] in the different cable/wire/connector cases to be able to suggest something, unless you are able to describe briefly what's stored.

One thing about the loops, is that they are often made of short wires, and I would prefer to be able to specify wire attributes for them, and have them in the BOM together with other wires in those cases.

[kvid]

Assumimg pin 1 when only a connector without pin is specified, sounds very well in my mind.

[formatc1702]

I'm afraid I might have to wait until late this evening to test what's stored in the yaml_data['connections'] in the different cable/wire/connector cases to be able to suggest something, unless you are able to describe briefly what's stored.

I've started working on something here, still maturing.

[formatc1702]

Thanks @kvid, I've based the system on your proposal, seems to work great! Loops will be reimplemented elsewhere.

[formatc1702]

One thing about the loops, is that they are often made of short wires, and I would prefer to be able to specify wire attributes for them, and have them in the BOM together with other wires in those cases.

This will be its own issue/PR.. for now, I'm just restructuring code, loops will remain as primitive as they have been until now, just easier to declare directly, inside a connector's properties:

  X2:
    type: Molex KK 254
    subtype: female
    pinout: [GND, RX, TX, N/C, IN, OUT]
    loops:
      - [5, 6] # each entry must be a list of exactly two pins
      - ...