[feature] better readability for cables with numbered wires

[Tyler-Ward]

I recently created a cable using YY control cable that has numbered cores rather than different colors, this results in needing to count how far down the core is to work out its number. A potential soloution for these cables or others that don't use colour to diferentiate might be to add a wirelabel option similar to the pinlabels used on connectors. What are peoples opinions on this?

[kvid]

• connector.pins contains the unique pin identifiers, default range(1, connector.pincount+1) when unspecified.
• Edit: There is currently no attribute to specify custom unique wire identifiers, but a 1-based numeric index is used to specify connections. Internally in the source code, they are looped by enumerating the colors list - is that still going to be possible?
• connector.pinlabels contains the label of each pin - often the function of each pin, i.e. several pins might share the same label, e.g. "GND", but those labels that are unique within the connector can be used to identify a pin in connections.
• I would therefore expect a cable.wirelabels to contain the label of each wire - often the function of each wire, i.e. several wires might share the same label, but those labels that are unique within the cable can be used to identify a wire in connections. Is this in conflict with your suggestion?
• However, please correct or redefine my description above, e.g. using more generic terms than function.
• Edit: Please check for any label collision with the implicit wire identifier 's' in shielded cables.
• When no wire colors are specified, I guess these wire labels take their place in the wire node, but when both labels and colors are specified, then both should be present, e.g. separated by colon as in this diagram:
  
• Do you think such labels optionally could be specified as a numeric range, like this?

--------------------------- tutorial/tutorial05.yml ---------------------------
index 449dd84..ba2c4fe 100644
@@ -16,6 +16,7 @@ cables:
     length: 0.3
     gauge: 0.5 mm2
     colors: [YE, BK, BK, RD] # custom colors, wirecount is implicit
+    wirelabels: [1-4]
 
 connections:
   -

• In cables with a high number of colored wires, I believe I've seen numbered wire groups with unique colors within each group (repeating the sequence of colors). Are we able to specify wire labels that are incremented for each repeating color sequence? Is this useful, or too complicated? Maybe such a feature is better solved with a new cable.colorgroups attribute?

[formatc1702]

We should look for some parallels between a connector's pins (=unique IDs) and pinlabels (not necessarily unique) when considering new attributes for cables.

Internally in the source code, [the wires]are looped by enumerating the colors list - is that still going to be possible?

I am not too happy with the current situation, we need a more elegant way to iterate over wires of a cable/bundle. See #56 and #127.

• Edit: Please check for any label collision with the implicit wire identifier 's' in shielded cables.

Perhaps we should change this to _s, _shield or something else, so as not to limit the possible user-assigned labels too much.
Shield definition might change in the future, see linked issues above.

• Do you think such labels optionally could be specified as a numeric range, like this?

--------------------------- tutorial/tutorial05.yml ---------------------------
index 449dd84..ba2c4fe 100644
@@ -16,6 +16,7 @@ cables:
     length: 0.3
     gauge: 0.5 mm2
     colors: [YE, BK, BK, RD] # custom colors, wirecount is implicit
+    wirelabels: [1-4]
 
 connections:
   -

I would follow the current practice for a connector's pins, autonumbering if no pins attribute is specified.
Generally speaking, using ranges ([1-4]) would be nice as long as we make sure not to repeat #139's bug.

• In cables with a high number of colored wires, I believe I've seen numbered wire groups with unique colors within each group (repeating the sequence of colors). Are we able to specify wire labels that are incremented for each repeating color sequence? Is this useful, or too complicated? Maybe such a feature is better solved with a new cable.colorgroups attribute?

Sounds too complicated for now TBH, and there are probably multiple implementations of this.
Unless we can find a standard, I would not prioritize this right now.

[formatc1702]

See #194.

• Ranges ([1-4]) will not be implemented to define labels at this point, but it is worth keeping in mind for the future.
• Refactoring to eliminate iterating over wire.colors will happen later, too.
• Changing the shield definition can be discussed as a separate issue, adapting the code should be easy. For now, checks for using s as a label within a shielded cable raise an exception.