[feature] Using inches and other units

[sahil48]

Is there a way to set unit to inches?

[formatc1702]

I'd like to implement this in the future, but it's not a top priority right now.
The question is, what units would you accept as inputs, how are they stored internally (personally, I'd convert everything to meters internally) and what unit is used for BOM output?
I will keep it in mind.

[sahil48]

Internally, and as output, we do and would continue to use inches because our products are designed in customary units, and wires and the components they are routed with correspond better to one another when they use the same units. We design and manufacture our products in the US, and components from machine shops are not only less expensive, but more readily available in customary units. Even our existing automated wire cutter Programsis set up in inches.

The only time we use metric is when adding holes and screws for mounting motors or power supplies, which are usually in metric units. Area is less significant to me, so I wouldn’t mind leaving out area from the output when inches is used.

[kvid]

I guess @formatc1702 is thinking about internally in his WireViz Python code, not internally in the users organization, and also input and output files related to this WireViz tool.

[sahil48]

Okay, that would make sense. In the source code, I would imagine metric would be easier to reason with.

[formatc1702]

I guess @formatc1702 is thinking about internally in his WireViz Python code, not internally in the users organization, and also input and output files related to this WireViz tool.

correct.

[chrisalbertson]

The way you do it is to store the dimension internally in "counts". Then you have a field someplace that is used to define what "counts" are. And these can be inches, furlongs or meters or millimeters. But all your internal calculation is done in "counts". The reason to never try and convert is they you end up with round off error. No one wants to see a dimension called out as "3.333333 mm" or "0.50001 inches" So you NEVER convert units, you simply take note of what units are being used. That said, in electronics, I rarely see anyone using inches, even here in the US. The exception is when we see pins on 0.1 inch centers but even that is called out as 2.54 mm centers (and the conversion is exact.)

…

On Sat, Jun 27, 2020 at 2:33 AM Daniel Rojas ***@***.***> wrote: I'd like to implement this in the future, but it's not a top priority right now. The question is, what units would you accept as inputs, how are they stored internally (personally, I'd convert everything to meters internally) and what unit is used for BOM output? I will keep it in mind. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQKNRWSLKOURMFVM6VWLYDRYW4FHANCNFSM4OG2QELQ> .

-- Chris Albertson Redondo Beach, California

[aakatz3]

In electronics, while I rarely see inches, I do constantly see mils (thousandths of an inch). While I haven't looked through all of the code extensively, I didn't see anywhere that the exact length of the wire matters right now. Maybe it could be kept unitless, and the unit suffix could be tacked on at the output stage? That's the nicest solution IMO, because it is the most portable, should one need to define custom units.

[kvid]

I agree with @aakatz3 , but it requires that all cables of the same type use the same length unit to avoid any unit conversion calculations when calculating the total length of each cable type. I guess most users can live with that.

[chrisalbertson]

On Sat, Jun 27, 2020 at 1:15 PM kvid ***@***.***> wrote: I agree with @aakatz3 <https://github.com/aakatz3> , but it requires that all cables of the same type use the same length unit

I think the more accurate statement is this: "but it requires that all cables of the same type *that are in the same YAML file* use the same length unit." I think it is reasonable for someone who needs to work in mixed units to use two input files. No please do not even think about the case where I make a cable be solder-slpicing metric and American wires that have different colors. But on the other hand wire cn have many properties that are REALLY important 1) diameter (or circular area) 2) Solid or stranded and if stranded how many strands and how are they organized. 3) the kind of metal used for the conductor and is the metal plated with tin or silver. I've seen copper-coated aluminum wire and copper coated steel too. 4) the kind of insulation, could be anything from cloth to silicon to vinyl or PVC 5) the voltage rating of the insolation 6) shielding. Foil, braid, both, coaxial, triaxial or not. Also some wire as a foil shield around each pair of wires, some has sheil around all wires One thing to note is that the above list can never be made complete. Some engineer will always be able to think of some new kind of cable. Perhaps all that is needed is a "notes" field where the user can write anything he likes.

…

-- Chris Albertson Redondo Beach, California

[njhurst]

Rounding is not a problem - we already round most numbers, as we use 0.1s of a mm which are not exactly representable. I don't think it is sensible to go down the multiunit pathway, that caused endless pain in inkscape with almost no return on investment. Instead, represent everything internally as mm, and convert at display time. Python's default float type is accurate to 1 part in 1000000000000000 or so.

Don't go unitless either, that way also lies madness, as you see with the random frustration when importing STLs or DXFs between tools. Stick to a real unit with a physical size and be clear about so that we avoid confusion. Honestly inches are mostly a convenience for humans, so we should leave them purely for rendering. (And remember that the inch is defined from the mm; you know, if we switched to 0.1microns we'd be able to represent mm and thous exactly).

[slightlynybbled]

I have successfully utilized pint in the past for storing and reading units. If you are going to start saving units, pint is as good as anything.

Package is stable, maintained, and pure python.

[zombielinux]

+1 for inches/feet. We use them ALL the time for our harnesses.

The BOM output already has a column for unit.

[formatc1702]

FYI, everyone interested: Support for custom units has been added to the dev branch in #196;
auto-parsing (length: 5 in yielding length: 5 and length_unit: in, analogous to how wire gauge works) will follow in #198 soon.

Be aware that units are treated purely as labels, no conversion has been implemented, and units need to match in order to be added together during BOM generation.
So if you have two identical wires, and specify one as length: 1 m and the other as length: 39.3 in, their lengths will not be added together in the BOM, and they will show up as separate items.

I will leave this issue open in case we decide to tackle actual unit conversion in the future.