RB3200-ESP32 drill file not rendering within board

[kasbah]

Hey, not sure what's going on with this one. Gerbers are from RoboticsBrno/RB3200-ESP32universal. It doesn't seem to be the normal Eagle trouble with zero supression (I tried adding INCH, TZ and METRIC, TZ but neither look right).

Eagle version is 7.7 I believe and CAM job is http://technika.tasemnice.eu/trac/browser/eagle_libraries/Seeed_Gerber_Generater_2-layer.cam

Gerbv and KiCAD Gerber Viewer seem ok with this one.

@yaqwsx can probably give more info if needed.

manufacturing files

drill file outline gerber

svgs

[mcous]

Don't put a space after the comma. I'm able to get it to render by adding:

METRIC,TZ

(Metric, leading zero suppression, 3 integer places, 3 decimal places)

[yaqwsx]

I would like to just point out that none of the fab houses we used so far had any trouble with the gerbers and I don't like the idea of manually post-processing gerbers in order to supported gerber-to-svg. I think this is a feature/a bug, which should be implemented/fixed in gerber-to-svg.

Eagle export to the Excellon format seems to produce two files - one with hole dimensions (and unit specification) and the second one only with the hole positions.

[kasbah]

It's always been just a work around for sure and my plan has been to implement some kind of trailing zero detection on the drill files (at least in pcb-stackup). It's worth pointing out that the fabs normally will have someone step in and make adjustments with errors like this.

The surprising thing for me on this is that KiCAD and Gerbv actually deal with this fine so I will look into how they do that. If they do something more interesting than just assume leading zero suppression then it might be worth copying.

Assuming trailing zero suppression might still be the better option as well, trying to find the cases where Gerbers break then and compare would be worth it even just for my peace of mind (I've only ever seen it break one way, not the other because it's been this way quite a while).

[mcous]

@yaqwsx it's for sure an annoying/unreasonable step to manually edit the drill file. However, the drill file output from Eagle is consistently lacking. Excellon has a mechanism to specify zero suppression (,TZ and ,LZ), and it also "specifies" (in quotes because it's not a real spec) a default of trailing zero suppression. Accordingly, gerber-to-svg will look for the zero command (which does not exist in this file) and then fall back to Excellon default. Could you attach that other information drill file you mentioned so I can see if there's anything there?

A few versions back, the default was swapped, so this file would've worked, but it broke other drill files, so it wasn't really a win.

Zero suppression detection would need to be implemented in gerber-parser. Totally doable with this file, as there are trailing zeros present in a few coordinates that could be detected.

The other option would be, as @kasbah said, to implement something in an orchestration layer like pcb-stackup. gerber-to-svg works on files in isolation, so there's only so much information it can bring to the game.

[mcous]

Tracking zero-suppression detection in mcous/gerber-parser#15

[yaqwsx]

These are the files produces by Eagle using standard CAM file (by SeedStudio), which all the manufactures I met accept with no problems:

The DRI and the TXT file contain the drill information.

gerbers.zip

[mcous]

Interesting. There's definitely good information in that DRI file about the coordinate format (standard Excellon in inches is 2:4, this file is called out as 2:5 in the DRI). Still nothing about zero suppression. I have no doubt the fabs are able to handle these files (because they've been dealing with Eagle's problems forever). I, however, don't use (nor like...) Eagle so gerber-to-svg has never been the best at handling its idiosyncrasies.

For reference, here is the drill file header of this Eagle file (// comments added by me). Notice the lack of any format or zero suppression information.

%
M48  // specify header start
M72  // specify inches (implies coordinate format 2:4)
T01C0.01181
T02C0.02362
T03C0.03937
T04C0.04000
T05C0.04331
T06C0.05118
T07C0.08661
%

Now, contrast that with a drill file from KiCad:

M48  // specify header start
;DRILL file {Pcbnew (2013-07-07 BZR 4022)-stable} date 11/9/2013 6:13:08 PM
;FORMAT={2:4/ absolute / inch / keep zeros} // detailed formatting info
FMAT,2 // specify excellon version
INCH,TZ // specify inches and keep trailing zeros (suppress leading zeros)
T1C0.015
T2C0.020
T3C0.035
T4C0.098
T5C0.142
%

@kasbah do you think perhaps an Eagle preset in gerber-parser/gerber-to-svg could help? It'd still require a little bit of user intervention, but less so than putting in the exact formatting options

[kasbah]

do you think perhaps an Eagle preset in gerber-parser/gerber-to-svg could help? It'd still require a little bit of user intervention, but less so than putting in the exact formatting options

Wouldn't it be exactly the same as the --zero=L option?

[mcous]

Haha yes... but it would be easier to remember! (I didn't think through it very hard before suggesting it)

[mcous]

Closed via mcous/gerber-parser#15