[feature] Ability to add BOM items within components

[MikeCrookes]

Would be great to be able to specify the crimps for connectors and for this to be added to the BOM

[formatc1702]

This is a very good point, especially once you get to more complicated mixed contact connectors (first example that comes to mind) which need different pin types within one connector.

Maybe @Tyler-Ward and @kvid our BOM experts have a suggestion? 😃

It probably makes sense to start with #51 to allow arbitrary manual BOM additions first, which could cover crimps for the time being. I am totally on board for supporting a proper crimp definition in the future, though!

[Tyler-Ward]

This sounds like a good idea and probably wouldn't be too hard to add. Doing #51 first sounds sensible and should be relatively easy to do.

I can see there being two methods to define the crimps.

For single crimp types a string can be set for the crimp part number and internal part number and used for all positions. (might want a flag to turn on/off limiting crimps to only being added for populated positions). With Templating this can allow the crimp to be declared for an entire series of connectors at once e.g. all female Molex KKs.

For multiple crimp types we can specify with arrays similar to bundle wires. Will likely also need a field for a crimp description so they can have a useful description in the bom. The array helper function in #62 will help for this. As well as the example above a common example of needing this might be where there are different crimp parts depending on wire gauge.

For interest If you want connectors with unusual loadouts I believe it is possible to set up some lemo connectors to have all of the following in one connector, Low voltage, high voltage, coax, fibre-optic and fluid/gas.

[formatc1702]

Do you want to take care of #51 and #50 (probably in that order)? I'm starting to assign issues to contributors to keep an overview of what's going on, so let me know!

[Tyler-Ward]

I'm happy to take those on so feel free to assign to me.

[formatc1702]

Much appreciated. It seems you have to comment on #51 in order to be eligible for assigning.

[formatc1702]

An idea here would be to tag certain items to be used only for pins that are actually populated, others for all pins (qty = pincount), others in custom quantities (like you mentioned, backshells and the like)...

perhaps the qty attribute could be either an int, or a custom string like $all or $populated that gets replaced after all connections have been made.

[Tyler-Ward]

Apologies for the lack of progress on this the last couple of weeks have bee quite busy. rather than the implementation idea suggested above in #50 (comment) integrating crimps into the idea from #51 which supports additional components on parts might be a better soloution rather than having two methods of defining.

I have created a potential format for describing these below. by specifying an additional item field a list of additional items can be added to a connector (or wire). For quantity this can either be a number, "pincount" for the number of pins in a connector or "connectioncount" for the number of connections used. To account for items where the connector is made up of constituent parts and doesnt have a main part (anderson powerpoles as an example) i have also added a ignore_in_bom field below that will prevent creation of a line for the connector itself. This might also be usefull for preterminated connectors which will curently generate two lines in the bom (one for the connector and one for the cable).

Any thoughts or suggestions on the format addition example below?

connectors:
  X1:
    type: Powerpole
    pinout: [GND, VCC]
    ignore_in_bom: true
    additional_components:
      -
        type: housing
        qty: 1
        unit: ea
        manufacturer: Anderson
        manufacturer_part_number: 1327G6
        internal_part_number: powerpole-black
      -
        type: housing
        qty: 1
        unit: ea
        manufacturer: Anderson
        manufacturer_part_number: 1327
        internal_part_number: powerpole-red
      -
        type: crimp
        qty: pincount
        unit: ea
        manufacturer: Anderson
        manufacturer_part_number: 1331
        internal_part_number: powerpole-crimp-30A
  X2:
    type: Molex Micro-Fit
    subtype: female
    pinout: [GND, VCC, A, B, C]
    manufacturer_part_number: 436450500
    manufacturer: Molex
    internal_part_number: MF3.0-5
    additional_components:
      -
        type: crimp
        qty: connectioncount
        unit: ea
        manufacturer: Molex
        manufacturer_part_number: 43030-0007
        internal_part_number: MF3.0-Crimp

[formatc1702]

The format looks reasonable.

• I would get rid of unit: ea and simply default unit to None (meaning pieces) if not specified
• Maybe it's just me, connectioncount sounds a bit off and, as opposed to pincount, does not exist as a term anywhere else. On the other hand, I have no better suggestion 🤷
• Good idea about the ignore_in_bom option 👍
• I guess if and when this is implemented, it should be supported for both connectors and cables, just in case. Cables/bundles should support qty: wirecount, analogous to pincount.
• ⚠️ care must be taken when generating bom, of multiplying the qty of the additional_components by the quantity of actual connectors... this is critical especially for autogenerated connectors! Maybe it's no big deal, but nonetheless...
• Should additional_components be changed to additional_bom_items to match Add ability to include aditional bom lines. #80?
  Or should it be different on purpose? If so, make it even more different than it is now.

[Tyler-Ward]

for cable

The format looks reasonable.

• I would get rid of unit: ea and simply default unit to None (meaning pieces) if not specified

Unit is currently defaulted to none, I just put ea in the example as I wated somthing to fill the field.

• Maybe it's just me, connectioncount sounds a bit off and, as opposed to pincount, does not exist as a term anywhere else. On the other hand, I have no better suggestion 🤷

I wasnt sure on connection count either anyone else got any better ideas?

• I guess if and when this is implemented, it should be supported for both connectors and cables, just in case. Cables/bundles should support qty: wirecount, analogous to pincount.

For wires/bundle i can think of the following things you might want to multiple quantity by.

• wirecount.
• wireterminations.
• length
• total length (sum of length all wires in a bundle) e.g. when sleving individual cables

Perhaps adding a qty_multiplier or similar field be a better way to do this, that way you can specify somthing like 2cm heatshrink per connection and get a total length out the end.

• ⚠️ care must be taken when generating bom, of multiplying the qty of the additional_components by the quantity of actual connectors... this is critical especially for autogenerated connectors! Maybe it's no big deal, but nonetheless...

In the implementation so far the list is created for each connector and then deduplicated. Will take a look at autogenerated conenctors to make sure they are handled correctly.

• Should additional_components be changed to additional_bom_items to match Add ability to include aditional bom lines. #80?
  Or should it be different on purpose? If so, make it even more different than it is now.
  I think either would work, I went with a different name in the format to diferentiate it from bom items as it should be possible to add these to the main diagram under the connector pinout (not sure if this will look good though) at which point the functionalities would be different.

[formatc1702]

feel free to submit a PR draft with the current state of things so others can find it and have a look!
See the two drafts I already have submitted, it's quite useful :)

[kvid]

• Maybe it's just me, connectioncount sounds a bit off and, as opposed to pincount, does not exist as a term anywhere else. On the other hand, I have no better suggestion 🤷

I wasnt sure on connection count either anyone else got any better ideas?

$populated was suggested in #50 (comment)

$connected is another alternative.

• I guess if and when this is implemented, it should be supported for both connectors and cables, just in case. Cables/bundles should support qty: wirecount, analogous to pincount.

For wires/bundle i can think of the following things you might want to multiple quantity by.

• wirecount.
• wireterminations.
• length
• total length (sum of length all wires in a bundle) e.g. when sleving individual cables

How about optionally different entries for each wire/pin? And perhaps also in wire/pin templates and/or cable/connector templates?

Perhaps adding a qty_multiplier or similar field be a better way to do this, that way you can specify somthing like 2cm heatshrink per connection and get a total length out the end.

Good idea. Unless you consider accepting expressions like qty: 2 * connected - 1 (probably overkill at this stage).

• Should additional_components be changed to additional_bom_items to match Add ability to include aditional bom lines. #80?
  Or should it be different on purpose? If so, make it even more different than it is now.
  I think either would work, I went with a different name in the format to diferentiate it from bom items as it should be possible to add these to the main diagram under the connector pinout (not sure if this will look good though) at which point the functionalities would be different.

I agree it might be useful to list them in each diagram node in addition to the BOM with the option to hide them individually.