[feature] Tolerance in cable lengths

[ct2irw]

Hi there,

My name is Diogo. So often manufacturers ask to include tolerances in the cable lengths. I think it would make sense to have a key/value for that. The way I've implemented that was by mostly cloning the length key... The only change I did in that was to inherit the units from the length if none is provided instead of assuming 'm' like length does. Ideally, it would process different tolerances like -10mm and +15mm, but I did not have time to mess with that.

Let me know if you want any help implementing that.

Best regards,
DIogo

[formatc1702]

It would be nice if this didn't require an additional key/value in the YAML, but if it could be parsed within the length attribute itself. Internally, it probably makes sense to have it as a separate variable for sure.

Some suggestions for YAML input:

length: 100  # assume default unit
length: 200 mm  # explicit unit
length: 300 ±5 mm   # place unit before or after tolerance? allow both?
length: 400 +-5 mm  # allow +- instead of ± for easier input
length: 500 +5 -0  # allow asymmetric tolerance
length: 600 ±10%  # allow percentages?
                  # show as percentage in output or do the math?
                  # maybe as a second step later on
length: 700~750  # allow length range?

[kvid]

How should similar entries with such lengths be summed up in the BOM?

• Sum nominal lengths only?
• Sum nominal lengths, positive tolerances, negative tolerances (all in the same length unit) and present
  as {sum_nominals} +{sum_positives} -{sum_negatives} {unit}
• Sum minimum and maximum lengths of each length range and present
  as {sum_minimums}~{sum_maximums} {unit}

If specifying length range is allowed as input - hence no nominal specified, then only the latter alternative above might be possible.

If different lengths in #268 also will be implemented, then care must be taken how to present that combined with different length tolerances for each length.

[formatc1702]

BOM should probably show a sum of nominal lengths.

The last possibility (specifying a length range without a singular nominal length, e.g. length: 700~750) should be discarded so that there always is a nominal length available.

Tolerances (sum of positives, sum of negatives) could become their own column in the BOM, but it might be overkill to actually display them?

[kvid]

BOM should probably show a sum of nominal lengths.

Yes, I guess that's what most users would expect.

The last possibility (specifying a length range without a singular nominal length, e.g. length: 700~750) should be discarded so that there always is a nominal length available.

It's also possible to define a length range input to be regarded as equal to a nominal length = range middle and ±tolerance = half range length - e.g. 700~750 equals 725 ±25.

Tolerances (sum of positives, sum of negatives) could become their own column in the BOM, but it might be overkill to actually display them?

I guess tolerance columns in BOM could be optional, e.g. like this:

• None when no BOM entries have a tolerance or options.bom_tolerance_cols=0
• One when all BOM entries have equal positive and negative tolerances or no tolerances and options.bom_tolerance_cols=1
• Two when any BOM entriy has different positive and negative tolerances or options.bom_tolerance_cols=2

[kvid]

Maybe ufloat from the uncertainties library might be used to store and accumulate such cable lengths? In that case, it might be wise to consider the input syntax of ufloat_fromstr(). However, asymmetric values might not be directly supported: lmfit/uncertainties#25

[formatc1702]

I'm torn on adding a library for this.. sounds a bit overcomplicated? or at least should be split as a separate task, after implementing "simple" tolerances, that show up in each cable's node, but have no effect on BOM (which only uses nominal lengths), and getting feedback on that.

[kvid]

@formatc1702 - You are probably right it might be overkill using such a library for a simple sum of tolerances, but maybe it can serve as an inspiration, by picking a few elements we also need...

I do like the idea to have a class representing a float with it's tolerances (nominal, p_tolerance, n_tolerance), but how to fit this with other requirements depend on several questions:

• Do we require tolerance values to be in the same unit as the nominal value (or percentage)? Probably yes.
• If different lengths in feature: different gauges and different lengths in connections #268 also will be implemented, do we require all length elements (base, left_end, right_end) to use the same unit? However, such length elements probably might need different tolerances.
• If all numbers to be accumulated in the BOM must have the same unit, then it probably makes sense to only store one length_unit or length.unit in addition to all these:

  length.base.nominal
  length.base.p_tolerance
  length.base.n_tolerance
  length.left_end.nominal
  length.left_end.p_tolerance
  length.left_end.n_tolerance
  length.right_end.nominal
  length.right_end.p_tolerance
  length.right_end.n_tolerance

• The left_end and right_end values might optionally be lists to store different end values for each wire, but it should probaby be possible somehow, to specify a common tolerance to avoid repetition when that's the case.

When displaying all this in the cable node:

• Zero p_tolerance or n_tolerance can be omitted.
• Equal p_tolerance and n_tolerance can be combined with a leading ±.
• Zero left_end or right_end can be omitted.
• If all values are different, it'll take much space, but it's a choice the user makes.

In the BOM, the nominal length will be length.base.nominal+length.left_end.nominal+length.right_end.nominal for wires and length.base.nominal+max(length.left_end.nominal)+max(length.right_end.nominal) for cables (assuming all wires in a cable/bundle must have a common base length - with the jacket intact in the cable case).