[feature] Enable including components in the harness

[kvid]

Sometimes, a few simple components are integrated into the harness, like e.g. a LED indicator or switch mounted at a connector housing, a resistor at the end of a bus line, diodes for protecting against reversed polarity, etc. I suggest adding such a component as a connector with all connector attributes available, except that it can be marked as a Component instead of a Connector in the BOM entry.

In addition, it would be nice to have the option to connect the pins of such a component directly to a splice (simple connector) or connector pin without cable/wires between when the component has legs that allow direct connections in real life. It might be implemented similar to the mockup in #134 (comment) where ferrules (simple connectors) are connected directly to another connector.

Are there other use cases where something like this might be useful?

[formatc1702]

This sounds extremely useful, but will require some rewriting of the input checking logic, since so far it has been a strict CABLE-CONNECTOR-CABLE-CONNECTOR-.... sequence.

It's a good task to tackle for v0.3!

[kvid]

This sounds extremely useful, but will require some rewriting of the input checking logic, since so far it has been a strict CABLE-CONNECTOR-CABLE-CONNECTOR-.... sequence.

I have suggested a possible input syntax in #134 (comment) that doesn't break the alternating connector-cable-sequence, except accepting a direct connection as an alternative to a cable in the sequence , and that also can support mating wire connectors within the harness, as in #148.

[formatc1702]

Naïve question:
Is there a way to unify connectors and these components somehow in the YAML?
I understand that currently, the BOM entry auto-appends the "Connector" prefix, which is unwanted in this case, but easily fixed.

Alternatives:

• Rename connectors to components, and adding a category: connector parameter, which would not necessarily have to be rendered inside the node, but could be prepended in the BOM.
  • The problem is that, technically, cables and wires are components too, so the semantic distinction kind of falls apart.
  • Most components are likely to be connectors in the majority of use cases, so this adds a lot of unnecessary lines to the YAML if you need to specify this every time.
• Keep connectors and components separate, just like connectors and cables are separate.
  • BOM generation might get uglier, since now one more dictionary need to be parsed...
  • As mentioned above, a better semantic distinction would be helpful.
• Simply omit the "Connector" in the BOM entry, and treat these components as connectors.
  • IMHO, LEDs or switches within a wire/harness kind of qualify as "connectors" too, so it's not completely far fetched to list them under the connectors list. But it's not the most elegant solution either.

Any other ideas?

[formatc1702]

This may be only partially related, but this is how I implemented including a little level shifter PCB in one of our wiring diagrams at work (using the feature/mate+autogenerate branch for the arrows, and the dashed lines representing the "internal routing" within the PCB).

My vision is to be able to group connectors using the GraphViz cluster feature to more clearly show that both *_M connectors are part of the same component.

[kvid]

@formatc1702 wrote more than 4 years ago:

Naïve question: Is there a way to unify connectors and these components somehow in the YAML? I understand that currently, the BOM entry auto-appends the "Connector" prefix, which is unwanted in this case, but easily fixed.

Alternatives:

• Rename connectors to components, and adding a category: connector parameter, which would not necessarily have to be rendered inside the node, but could be prepended in the BOM.

  • The problem is that, technically, cables and wires are components too, so the semantic distinction kind of falls apart.
  • Most components are likely to be connectors in the majority of use cases, so this adds a lot of unnecessary lines to the YAML if you need to specify this every time.

I agree to the arguments against this alternative.

• Keep connectors and components separate, just like connectors and cables are separate.

  • BOM generation might get uglier, since now one more dictionary need to be parsed...
  • As mentioned above, a better semantic distinction would be helpful.

I'm not convinced this is the way to go. There might come future requests about more categories too.

• Simply omit the "Connector" in the BOM entry, and treat these components as connectors.

  • IMHO, LEDs or switches within a wire/harness kind of qualify as "connectors" too, so it's not completely far fetched to list them under the connectors list. But it's not the most elegant solution either.

The important distinction between connectors and cables is how their amounts are measured:

• connectors by count
• cables by accumulated length

With this in mind, I think any countable components can be regarded as connectors.

Any other ideas?

@JarrettR suggests in #430 to add an optional attribute like e.g. bom_description to both connectors and cables to override their default (currently hard coded) description values "Connector", "Cable", or "Wire" used in their BOM entries. This way, ordinary connectors, cables, and bundles will continue to work as normal. I like this idea.

Update: I assume such an optional description value also should be written just before the type value in the diagram. Alternatively, we could add an optional attribute to hide/show the default BOM description and let the user put the full description in the type attribute. The visual result should be the same, but the first alternative enables a common description in a template for different components with different type values, and is therefore more flexible.