>I think we're missing the point of "what are we trying to fix by fixing dxf importer overflows".
>Current implementation just convert them immediately as the library parses the DXF file. This suggestion would result in a complete rewrite of DXF importer but I believe would make DXF importer significantly more robust. Nope, not a complete rewrite at all because they aren't converted to internal objects immediately like you said. It's actually a trivial fix :P On Tue, Nov 26, 2024 at 3:58 AM RigoLigo RLC <[email protected]> wrote: > Hi all, > > I think we're missing the point of "what are we trying to fix by fixing > dxf importer overflows". > > The DXF file provided in #12392 has a board that measures 2 meters long so > it's still in our representation limits. Issue is that people draw their > graphics in whatever CAD program may place their stuff at arbitrary > locations (DXF uses double precision floats, very likely AutoCAD internally > uses it too) which makes coordinates easily go beyond our limits while our > system is actually sufficient to support the overall graphics size. > > IMO what we need is a normalization process in the importer, where we find > the bounding box of the graphical elements, fail if the overall size > overflows the internal representation, and "move" the whole graphics into > our representation bounds before converting. > > > Current implementation just convert them immediately as the library parses > the DXF file. This suggestion would result in a complete rewrite of DXF > importer but I believe would make DXF importer significantly more robust. > > > Rigo > > Liang Jia <[email protected]> 于 2024年11月26日周二 下午4:20写道： > >> Hi Rafał, >> >> Thanks for your reply. >> >> > Guys, have you ever considered going to "virtual dimensions"? >> I think it's not doable. >> >> Because you need to show the same thing with different units when using >> pcb editor. >> For example: >> 1. Users want to change the display unit from one to another. >> 2. Imported dxf shapes with specified unit >> >> Sincerely >> Liang >> >> >> >> On Tue, 26 Nov 2024 at 13:06, Rafał Pietrak <[email protected]> >> wrote: >> >>> Guys, have you ever considered going to "virtual dimensions"? >>> >>> What I mean here is that the entire design (that is the PCB of course, >>> not the SCH) is based on an integer grid like "natural numbers indices >>> to locations", while the grid size is provided for the entire PCB as a >>> single float? >>> >>> Consequently, the current 32bit integers stay as they are, only their >>> meaning changes. They would no longer mean "mm" (or whatever >>> "physical"), but just "indecies". "Physical sizes" would emerge only >>> when pcb get converted to production (gerber?) files ... or whenever >>> user puts in new constraints. The later naturally should be accepted in >>> physical dimensions as they are specified by fabs, but for the design >>> within KiCAD they should be converted to "grid size" based on current >>> grid size. Same goes for shapes libraries, but I think its doable. >>> >>> Such approach would introduce a "one time rounding errors" to the >>> design, but since this is really a "one time event" it does not bare any >>> cumulative effects, so it shouldn't matter at all. >>> >>> -R >>> >>> On 26.11.2024 04:25, Liang Jia wrote: >>> > Hi Mark and Seth, >>> > >>> > Thanks for your reply. >>> > >>> > Yes, you're right, it will lose some precision when using double. >>> > >>> > Just curious, I did some search online. >>> > *1. I found that the key players in the PCB market still have limits.* >>> > OrCAD X: 200 in. x 200 in = 5 meter * 5 meter; >>> > https://www.cadence.com/en_US/home/tools/pcb-design-and-analysis/ >>> > orcad.html#pcb-layout <https://www.cadence.com/en_US/home/tools/pcb- >>> > design-and-analysis/orcad.html#pcb-layout> >>> > Altium Designer: 200 in. x 200 in = 2.5 meter * 2.5 meter >>> > https://www.altium.com/documentation/knowledge-base/altium-designer/ >>> > >>> indicate-visual-cues-at-the-coordinate-limit-of-pcb-design-space-beyond- >>> > which-objects-should-not-be-placed <https://www.altium.com/ >>> > documentation/knowledge-base/altium-designer/indicate-visual-cues-at- >>> > the-coordinate-limit-of-pcb-design-space-beyond-which-objects-should- >>> > not-be-placed> >>> > Allegro: I can't find any detail information, but I tried the >>> software, >>> > it seems still have limit. *Anyone know the board size limit for >>> Allegro?* >>> > * >>> > * >>> > *2. If we really want to solve this problem, there are options below.* >>> > 2.1 Using software integer library, such as GMP; >>> > We can give an option to the user, let the user choose to >>> enable >>> > it or not. >>> > If enabled, Kicad can support a bigger board size, but software >>> > will slow; >>> > If enabled, Kicad runs as usual. >>> > **https://gmplib.org/ <https://gmplib.org/> >>> > 2.2 Using Binary coded-decimal, >>> > https://stackoverflow.com/questions/2624973/why-doesnt-my-processor- >>> > have-built-in-bigint-support <https://stackoverflow.com/ >>> > questions/2624973/why-doesnt-my-processor-have-built-in-bigint-support> >>> > https://en.wikipedia.org/wiki/Binary-coded_decimal <https:// >>> > en.wikipedia.org/wiki/Binary-coded_decimal> >>> > 2.3 *Give the control of precision and board size to the user.* >>> > If a user wants to have a smaller board size, he/she will have >>> > more precision location and something else; >>> > If a user wants to have a bigger board size, he/she will have >>> > less precision location and something else; >>> > >>> > *@Mark what's your opinion? * >>> > * >>> > * >>> > *@Seth, >>> > * >>> > >Addressing this means reworking our internal coordinate system >>> > Could you please kindly give me some location for those codes? so I >>> can >>> > dig into it. >>> > * >>> > * >>> > >>> > Sincerely >>> > Liang >>> > >>> > On Tue, 26 Nov 2024 at 02:02, Mark Roszko <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Floats are not accurate beyond 6-7 digits and worse, floating point >>> > behavior is actually not fully well defined. You can actually get >>> > different quirks depending on platform, compiler and arch. Though >>> > generally the risk isn't in the arithmetic but supporting functions >>> > that are part of libc. >>> > >>> > >And why did Kicad choose integer as internal measurement >>> resolution? >>> > >>> > Using integers is standard programming behavior for applications >>> > that want well defined and bounded mathematical behavior. >>> > >>> > When you do floating point math, even if we ignore the inaccurate >>> > power part of the number, that error still sits in the number. When >>> > you carry out sufficient and numerous operations using numbers that >>> > carry these not used digits, they can actually creep in and start >>> > affecting the digits you do care about and cause errors. >>> > >>> > >>> > >Last, so that means there is no way to handle this issue? >>> > >>> > >>> > We have come to the conclusion that if somebody needs PCB designs >>> > larger than 4 meters, which is already an ridiculous size. They >>> need >>> > to discuss with us the use case which is already going to be >>> > ridiculously niche for that one person because there is no standard >>> > PCB manufacturing equipment for a board of that size. >>> > >>> > >>> > On Mon, Nov 25, 2024, 8:01 AM Liang Jia <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Hi Mark, >>> > >>> > Thanks for your email. >>> > >>> > Could you please explain more about the relation between >>> "Change >>> > the measurement store from 32-bit to *64-bit*" and "128-bit >>> > integer math support in processors"? >>> > And why did Kicad choose integer as internal measurement >>> resolution? >>> > >>> > >mm is not adequate to express the resolution of position data >>> > required for a board design. >>> > How about this? use mm for internal measurement resolution, but >>> > use nanometer or *double(instead of integer)* for board design. >>> > >>> > >>> > Last, so that means there is no way to handle this issue? >>> > >>> > On Mon, 25 Nov 2024 at 19:21, Mark Roszko < >>> [email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > >This means it is possible to create boards up to >>> > approximately 4 meters by 4 meters >>> > >>> > Yes, KiCad is limited to 4x4 meter boards currently. >>> > >>> > > Change the measurement store from 32-bit to 64-bit, so >>> > Kicad can support a larger board. >>> > >>> > This is not an easy task in the slightest. Specifically >>> > because we can't get 128-bit integer math support in >>> > processors, and many compilers do not support 128-bit >>> > integers. I think gcc has some experimental support. >>> > >>> > > Change the resolution of all objects to mm >>> > >>> > mm is not adequate to express the resolution of position >>> > data required for a board design. >>> > >>> > >>> > >>> > Basically the bug here is we simply do not tell the users >>> > the DXF is beyond our board support limit. >>> > >>> > >>> > On Mon, Nov 25, 2024 at 5:07 AM Liang Jia >>> > <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Hi All, >>> > >>> > I am writing to inquire about the challenges we are >>> > facing when importing DXF files which contain large >>> > numbers into our system. >>> > >>> > I have noticed that when the number exceeds a certain >>> > threshold(such as 4437 mm), the import process results >>> > in an int overflow error. >>> > >>> > I did the search below: >>> > 1. Found that there was a ticket to track it, but it >>> > seems *it still opens*. >>> > https://gitlab.com/kicad/code/kicad/-/issues/12392 >>> > <https://gitlab.com/kicad/code/kicad/-/issues/12392> >>> > >>> > 2. From the Kicad document: >>> > The internal measurement resolution of all objects in >>> > KiCad is *1 nanometer*, and measurements are stored as >>> > *32-bit integers*. This means it is possible to create >>> > boards up to approximately 4 meters by 4 meters >>> > I think the *root cause* is here: Kicad tried to >>> convert >>> > the DXF number into nanometer, but those numbers >>> > exceeded the limit of integer. >>> > >>> > Questions: >>> > 1. Is there any workaround for this case, and let Kicad >>> > import those files successfully? >>> > 2. If I want to fix ticket 12392, what should I do? >>> > Change the measurement store from 32-bit to >>> 64-bit, >>> > so Kicad can support a larger board. >>> > Change the resolution of all objects to mm >>> > >>> > Looking forward to any comment or workaround. >>> > >>> > Sincerely >>> > Liang >>> > >>> > -- >>> > You received this message because you are subscribed to >>> > the Google Groups "KiCad Developers" group. >>> > To unsubscribe from this group and stop receiving >>> emails >>> > from it, send an email to >>> [email protected] >>> > <mailto:[email protected]>. >>> > To view this discussion visit >>> https://groups.google.com/ >>> > a/kicad.org/d/msgid/devlist/CAE0Ak8bd%3DgDwW%3DDWVXH- >>> > TKj%3Dr4nsgW370aNqB6PbP7T8b2QU6A%40mail.gmail.com >>> > < >>> https://groups.google.com/a/kicad.org/d/msgid/devlist/ >>> > CAE0Ak8bd%3DgDwW%3DDWVXH- >>> > TKj%3Dr4nsgW370aNqB6PbP7T8b2QU6A%40mail.gmail.com? >>> > utm_medium=email&utm_source=footer>. >>> > >>> > -- >>> > You received this message because you are subscribed to the >>> > Google Groups "KiCad Developers" group. >>> > To unsubscribe from this group and stop receiving emails >>> > from it, send an email to [email protected] >>> > <mailto:[email protected]>. >>> > To view this discussion visit https://groups.google.com/a/ >>> > kicad.org/d/msgid/devlist/ >>> > CAJjB1qKoN689BoyB1uWpWYmDCpbaCRKCyW2qmnBOoG5Au_Nnfg% >>> 40mail.gmail.com < >>> https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qKoN689BoyB1uWpWYmDCpbaCRKCyW2qmnBOoG5Au_Nnfg%40mail.gmail.com?utm_medium=email&utm_source=footer >>> >. >>> > >>> > -- >>> > You received this message because you are subscribed to the >>> > Google Groups "KiCad Developers" group. >>> > To unsubscribe from this group and stop receiving emails from >>> > it, send an email to [email protected] >>> > <mailto:[email protected]>. >>> > To view this discussion visit https://groups.google.com/a/ >>> > kicad.org/d/msgid/devlist/ >>> > CAE0Ak8bmAyB7ciCe6nrps8gw0meXgaj25r5Zq- >>> > o2Z9x_-8CFDA%40mail.gmail.com <https://groups.google.com/a/ >>> > kicad.org/d/msgid/devlist/ >>> > CAE0Ak8bmAyB7ciCe6nrps8gw0meXgaj25r5Zq- >>> > o2Z9x_-8CFDA% >>> 40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "KiCad Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, >>> > send an email to [email protected] >>> > <mailto:[email protected]>. >>> > To view this discussion visit >>> https://groups.google.com/a/kicad.org/ >>> > d/msgid/devlist/ >>> > CAJjB1qLDDND2JZpaBCOHZpoz9HvsVF%2Brn%3D5nSGAQVDzyrFFRBA% >>> 40mail.gmail.com < >>> https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qLDDND2JZpaBCOHZpoz9HvsVF%2Brn%3D5nSGAQVDzyrFFRBA%40mail.gmail.com?utm_medium=email&utm_source=footer >>> >. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "KiCad Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an email to [email protected] >>> > <mailto:[email protected]>. >>> > To view this discussion visit https://groups.google.com/a/kicad.org/d/ >>> > msgid/devlist/CAE0Ak8awnYeEqbpz0SwNc7wAf_hmS1ybhDWNbRuyr7efEPUf- >>> > w%40mail.gmail.com <https://groups.google.com/a/kicad.org/d/msgid/ >>> > devlist/CAE0Ak8awnYeEqbpz0SwNc7wAf_hmS1ybhDWNbRuyr7efEPUf- >>> > w%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "KiCad Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/kicad.org/d/msgid/devlist/53def67c-3503-4980-aa8f-ae33764ce9c7%40electric-sheep.eu >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "KiCad Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/kicad.org/d/msgid/devlist/CAE0Ak8aBa0Zt0G%2BKRfq4ZRMT9WiFVZO%2BBGHVdGLHWDJ%3D8f%2BzEQ%40mail.gmail.com >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAE0Ak8aBa0Zt0G%2BKRfq4ZRMT9WiFVZO%2BBGHVdGLHWDJ%3D8f%2BzEQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "KiCad Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/CADzo0sZ7hJNNk%2BOUs0uNwJPARry%3D3TZaWLsMK3OAkYCvrV5qMA%40mail.gmail.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CADzo0sZ7hJNNk%2BOUs0uNwJPARry%3D3TZaWLsMK3OAkYCvrV5qMA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1q%2Bwnt%3DtBF3cjOOJOr0_d-XuO7E-iYU7uHRVOvaPPc8zDA%40mail.gmail.com.
