Export drill file in XNC format

[TRST-P]

Current Behaviour

Hi, when exporting as gerber files, I found that not all files use the same number format for coordinates. This in turn is the cause of errors in other software I use. I believe it is considered a discrepancy if gerber files for a single project use different number formats. And thus I think it is a valid bug if Fritzing exports gerbers using different number formats.

Build: Version 1.0.3

Operating System: Windows 10

Steps to reproduce:

• Create any sketch, export as gerber
• Check the copper top and drill files and compare number format.

Expected Behaviour

Number formats do not match

[KjellMorgenstern]

Version 0.9.3 is from 2016. Please try our recent release from https://fritzing.org , which uses a higher resolution.

Also note that the number format is specified FSLAX23Y23 (1000dpi) in the example you gave.

[TRST-P]

Sorry, version is 1.0.3, the latest I believe. The examples given is the direct export from Fritzing. The problem is with the inconsistency between the files. The copper top may be X23Y23 format, but the drill clearly isn't.

[KjellMorgenstern]

In the preferences, could you try to enable "gerber export improvements" ?

[TRST-P]

Hi Kjell, thank you for the suggestion. I tried it but the problem persists, although the accuracy is improved (6 decimals vs 3) the number format is still inconsistent between drill file and copper top:

The specific problem this causes in my print software is that it does not recognise holes and creates a toolpath over a hole where it should be a ring around a hole.

Here I manually added two trailing 00's to the coordinates of one hole and left the other as exported by fritzing. As you can see this generates one correct hole with a ring and where there should be another it is filled:

I have mentioned this problem to the support from the printer software as well and asked if they can make ther Gerber parser more 'flexible'.

But I believe the Gerber export function in Fritzing should be consistent in this as well.

[TRST-P]

Goodmorning,

I looked a bit deeper into this and found some additional info that might help.

1. The number format specified FSLAX23Y23 or FSLAX26Y26 (gerber export improvements enabled) does not actually generate coordinates in this format.
   • In case of the first, it should generate 5 digits, two integer and 3 decimal. But as can be seen in my first screenshot there were only 4 digits per coordinate.
   • In case of the second format, it should generate 8 digits per coordinate, 2 integer and 6 decimal. However, it generates 7.

The gerber file specification does state that leading zero's may be omitted and how the coordinates should be handled:

Following this logic with the copper and drill files provided before, we get the following mismatches between coordinates:

• first post format: FSLAX23Y23 copper: X1022Y1422, interpreted as 01.022, 01.422 drill: X010222Y014222, interpreted as 10.222, 14.222 (assuming no left padding is done since digits already >5, decimal placed before 3rd digit from the right)

  • second post (gerber export improvements enabled): format: FSLAX26Y26 copper: X1622220Y1422220, interpreted as 01.622220, 01.422220 drill: X016222Y014222, interpreted as 00.016222, 00.014222

• second post (manually modified drill coordinate): format: FSLAX26Y26 copper: X1622220Y1422220, interpreted as 01.622220, 01.422220 drill: X01622200Y01422200, interpreted as 01.622200, 01.422200

  2. In the past, with older versions of Fritzing, I did not have this issue. So I checked some old files exported by an older version of Fritzing (don't know exactly which version unfortunatly): format: FSLAX34Y34 copper: X0013990Y0011000, interpreted as 001.3990, 001.1000 (even leading 0's match the stated format) drill: X013990Y011000, interpreted as 001.3990, 001.1000 So, even though the number of digits between copper and drill files are different, following the interpretation logic from the gerber spec, it still yields the same result.

I hope this helps,

Marten

[KjellMorgenstern]

The drill file is still an NC format. Opening the file in gerbv or other tools doesn't directly show problems.

~My guess is that it follows the XNC subset~ At least we should produce a XNC subset: https://www.ucamco.com/files/downloads/file_en/452/xnc-format-specification-revision-2021-11_en.pdf?2ccd0fdd6dd78e87ed52185bbd06038b

What we see here are some of the problem described on https://www.ucamco.com/files/downloads/file_en/130/pcb-fabrication-data-a-guide_en.pdf?6f1ad339fbbb654d75d8b25bc426d2c3 , page 17ff

[TRST-P]

Hi Kjell,

Thank you for looking into this! Yes, XNC seems to be a better format, but why not all gerber? The documentation in the links you sent is quite pro gerber😅

[KjellMorgenstern]

@TRST-P The code we are talking about is more than ten years old. I'd be happy with gerber drill files, but there are currently ~467~ 465 open issues, and in average > 100 new issues per year. And this fritzing-app github repo is just the visible tip of the iceberg. Therefore it will take a while until we get to this.

It might be faster to just improve the current NC output to comply with XNC.