-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug] mm² to AWG tables are inaccurate #282
Comments
You are right, the automatic conversion between AWG and mm² is not perfect. The current AWG to mm² conversion does indeed deviate from some other conversion tables, but see my comments below on those deviations that seem to be due to rounding up for safety. IMHO, the current mm² to AWG conversion being unsafe is a greater problem. Based on the definitions described at Wikipedia, this code prints mathematical conversions with 3 digits precision, and compare it to the current conversion table: from math import pi
for n in range(-3, 41):
awg = n if n > 0 else '0'*(1-n) + f' or {1-n}/0'
mm2 = pi * (0.005 * 25.4/2)**2 * 92**((36-n)/19.5)
mm2tbl = mm2_equiv_table.get(str(n))
info = f' [{100*float(mm2tbl)/mm2 - 100:+.1f} % = {mm2tbl} mm²]' if mm2tbl else ''
print(f'{awg} AWG = {mm2:.3g} mm²{info}') The code above prints this output that shows AWG to mm² mathematical conversion with 3-digits accuracy, and in brackets, the deviation from the mm² values in the current equivalent table:
The current equivalent table seems to represent a conversion from a selection of common AWG numbers into the closest common mm² value - always rounding up for safety (choosing an alternative wire should not result in a thinner wire that might get too hot when maximum current is applied). The current code use the same table for converting mm² to AWG, and e.g. converting 0.75 mm² to 20 AWG is unsafe because it would result in a 0.518 mm² wire that has less than 70 % of the cross-section area, and hence will get hotter than the original wire when the same current is applied. I suggest we instead use a table with mathematically conversions when converting from AWG to mm² (and let the user round up to the closest available wire when needed), but the same table cannot be used directly for converting the other way because the mm² values don't match common wire dimensions exactly. There are several alternatives when converting from mm² to AWG:
As long as rounding is needed, and rounding to a thinner wire is not safe, then it is impossible to convert in both directions using the same table as we do today. |
I just ran into this today with some wire which appears to be uniquely specified in mm2 and there is no exact AWG equivalent. It is 0.12 mm2, closest to 26 AWG. I like using the formula instead of a table, and would add my preference to round to the nearest standard AWG vs always going up to the next largest size. I understand the issue, and that makes sense in many applications, but when making small cables, sometimes such rounding up could kick you out of the range of the crimp connectors, for example. I would also like to see the equivalent value so-indicated, perhaps by parentheses. In my example, it would be |
When such a preference might differ between applications, maybe we should add some options to let the user decide, e.g. something like this: options:
gauge_equiv:
show: true/false # Default 'show_equiv' value for cables in this harness
awg_rounding: nearest # Or other strategies, e.g. named 'safe', 'thicker', 'not_thinner', 'not_thicker', 'thinner', ...
mm2_digits: 3
poor_match: (some tolerance limit for showing a leading '~') Maybe (in the future) also an optional Maybe the |
I thought of a parallel example with machine screws. If I have some mounting holes to attach feet to a prototype board, people can safely use either M3 or #4-40 screws as if they're equivalent. But if someone were designing a back porch or a pedestrian foot bridge, the screw sizes would be absolutely critical (not to say there couldn't be equivalents, but each option would have to be checked by the mechanical engineer). I think this issue of equivalent wire gauges is quite similar. Heck, if Wikipedia can be believed, there are some "standard" metric wire sizes for which there is no AWG equivalent (interesting that my 0.12 mm2 wire doesn't seem to exactly belong in either category). |
I agree your example illustrates why different applications might have different conversion rule preferences, but I still think my suggested new options can resolve such a need. Do you agree or not? Please suggest alternatives or variations to my suggested solution. How can we visualize the conversion rule in use to avoid misunderstandings whitout too space demanding annotations? |
Oh. I should've been clearer. I do like your proposed solution very much. I had suddenly thought of the machine screw analogy shortly after sending my original comment, and posted it as a second comment in case it helped anyone understand the logic behind this. In my own recent design searches, I think there's a standard or convention for purely metric series of wire sizes -- wire whose diameters / cross sectional areas aren't intentionally aligned with the AWG series, but are themselves "normal" metric values. Kind of like a 2 mm pitch connector vs a 2.54 mm connector. The latter is metric, but clearly it's just the equivalent of part designed in inches. The former is a part made originally using the metric system. I mention this because it would be nice to include such a table in the program alongside the list of AWG sizes. |
Thank's, but please also add variations that you find useful.
Yes, I now understand it was not meant as an argument after reading my suggestion.
IEC 60228 specifies the nominal cross-sectional areas, in the range 0.5 mm² to 2500 mm², for conductors in electric power cables, but the standard does not apply to conductors for telecommunication purposes.
In what way would you expect such a list to be used? Maybe an optional conversion preference to select the nearest equivalent in such a table, but then we ideally should also cover small dimensions, and I don't know a standard for that. Maybe something like the list attribute |
Maybe "list" is the wrong term. I meant that the program should be aware of these wire sizes, too, in as much as it needs to be aware of any standard wire gauge information. Today that takes the form of a list. And upon further thought, I think that list is only used for conversion between AWG and metric. I assume any revised algorithm as outlined above would probably use a similar table to "know" the standard sizes. I'm just guessing that a purely mathematical approach to deriving the standard sizes is probably more hassle than using a tabulated approach (just think about the headaches of using equations to generate the E96 number series, for example). The total number of different (and commonly used in modern designs) standard wire sizes seems manageable and shouldn't be so large as to exclude the tabulated data approach, IMHO. I'll dig around and see if I can figure out where those "pure metric" wire sizes come from that I found on Wikipedia last week -- if they are a standard or just made up for illustrative purposes on that chart. My first reaction to the notion of digging through wire manufacturers' data books is "oh no, that doesn't seem like a good idea". But on further thought, if indeed there is no standard but it's obvious that a major wire companies are using a single de-facto "standard" set of sizes, then it's not a bad idea. But if there are like four different private sets of wire sizes, I think that would become unwieldy. Wild thought, how difficult would it be for an (advanced?) user to provide their own table of wire information to the program's algorithm? I'm not sure of the usefulness of such a facility, but if it turns out there are really a bunch of conflicting manufacturers' private wire standards when it comes to pure metric sizes in the small signal low voltage space, it might make sense. As to your request for additional parameters to the prosed new way of specifying wire size, I'm not thinking of any at present. However, a kind of related size topic would be the wire's insulation size. I suspect that's more unclear than wire gauge sizes, but if there are some reasonable standards it might be helpful to include those in a manner similar to gauge? I'm just thinking out loud here, having recently worked on a design where the insulation diameter was also important for PCB strain relief purposes. |
Variation 1: options:
gauge_equiv:
show: true/false # Default 'show_equiv' value for cables in this harness
rounding: nearest # Common strategy unless specified for each unit
awg:
rounding: nearest # Or other rounding strategies, e.g. named 'thicker', 'thinner', ...
available: [13, 15, 17, 19, 21, 23] # Subset to use
kcmil: # Unit to use when thicker than 0000 AWG
rounding: nearest # Or other rounding strategies, e.g. named 'thicker', 'thinner', ...
available: [250, 300, 350, 400, 500] # Subset to use
mm2:
digits: 3 # Compute 3-digit equivalent
available: [0.5, 0.75, 1, 1.5, 2.5, 4, 6, 10] # Subset to use
rounding: nearest # Or other rounding strategies, e.g. named 'thicker', 'thinner', ...
match:
poor: 10 % # Show a leading '~' unless rounding within ±10 %
invalid: 50 % # Don't show equivalent unless rounding within ±50 %
options:
gauge_equiv:
show: true/false # Default 'show_equiv' value for cables in this harness
rounding: nearest # Or other common rounding strategies, e.g. named 'thicker', 'thinner', ...
awg: [13, 15, 17, 19, 21, 23] # Subset to use
kcmil: [250, 300, 350, 400, 500] # Subset to use
mm2: 3 # Compute 3-digit equivalent, or alternatively
mm2: [0.5, 0.75, 1, 1.5, 2.5, 4, 6, 10] # Subset to use
match:
poor: 20 % # Show a leading '~' unless rounding within ±20 %
invalid: 60 % # Don't show equivalent unless rounding within ±60 % |
A full list of standard sizes could be the default values of the
Yes, references to relevant standards (or de-facto "standards") are welcome.
Do you mean something like the
This last suggestion about extra parameters might perhaps be resolved by something like |
I'd say variation 2 is best, but then again I'm not a power user. Not sure of the usefulness of specifying the closest match in such a fine-grained approach. These proposed yaml directives are on a "per-invocation of the program" basis? Or could they be overridden on a per-cable basis? If the latter, that seems like it would take care of any situation where the user wanted to tweak the nearest-match tolerance. |
I agree it looks better than variation 1, but don't stop looking for even better variations.
Is it the
I suggest accepting the Edit: Maybe also consider renaming |
By fine-grained, I meant specifying rounding separately for each kind of wire gauge standard, not the kinds of rounding options. I think those are good. |
I agree - that was also my motivation for variation 2. Originally, I was thinking separate values for each unit to allow a computed value for mm² and rounding to list entries for AWG, but then I realized only one value is really needed separately for each unit - either the number of digits in a computed value, or a list of available values for matching. |
After designing a harness with WireViz and setting
show_equiv
totrue
for my wires, I noticed the conversion from 20 AWG to mm² was not correct. 20 AWG should be 0.5mm², but WireViz converted it to 0.75mm².I took a look at
wv_helper.py
and noticed that awg_equiv_table seems to have incorrect values for 21AWG, 20AWG, & 18AWG. That's according to this table I found after a quick Google search: https://lexproducts.com/technical/wire-conversion. Other tables I looked at seem to agree as well though.The text was updated successfully, but these errors were encountered: