Support rendering Allegro drill files with lots of missing information

[shawon1220]

@mcous ，this gerber's drill layer svg incorrect，converter no width and height. I don't know what's causing it, hope you can help，thanks.

[mcous]

@shawon1220 what CAD program generated this drill file? And what program did you use to get the screenshot above? The drill file is technically indefinite, which is why tracespace can't render it.

Problems:

• Tool sizes are specified in comments rather than with a tool definition blocks
  • A standard tool definition looks like: T01C0.010
  • Instead, this file does: ; Holesize 1. = 10.000000 ... MILS ...
• Tool changes seem to happen implicitly via M00 (stop) commands
  • I've never seen anything like this, so this is an educated guess
• The file uses R# repeat commands
  • I've never seen these used before so tracespace does not support them

It would be a non trivial amount of work to support this particular flavor of indefinite drill file. If you are able to regenerate this drill file with different settings, I would recommend trying that. The tracespace packages work best if drill files are specified in something close to the XNC spec, as output by KiCAD.

For now, I do not plan to try to support this drill file.

[shawon1220]

@mcous Thank you very much for your suggestion. These files are from users, and there are many more files in this format generated by Cadence Allegro16. https://dfm.elecfans.com/viewer/?tid=DFM-dh can get the screenshot above.
I am trying to convert such line to standard looks like T01C0.010 and it's can work in tracespace now.
But I still have a question, how to confirm the places? the places in the following two files seem to be different. And I found that there is nc_param.txt contain INTEGER-PLACES and DECIMAL-PLACES.

M48
INCH,TZ
;LEADER: 12
;HEADER:
;CODE : ASCII
;FILE : MB1261_REVB_160930_FAB2-1-6.drl for board MB1261_REVB_160930_FAB2.brd ... layers TOP and BOTTOM
; Holesize 1. = 8.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 43
; Holesize 2. = 10.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 317
; Holesize 3. = 12.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 289
; Holesize 4. = 20.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 2
; Holesize 5. = 33.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 2
; Holesize 6. = 36.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 50
; Holesize 7. = 40.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 41
; Holesize 8. = 138.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 4
; Holesize 9. = 28.000000 Tolerance = +2.000000/-2.000000 NON_PLATED MILS Quantity = 3
; Holesize 10. = 39.000000 Tolerance = +2.000000/-2.000000 NON_PLATED MILS Quantity = 4
; Holesize 11. = 79.000000 Tolerance = +2.000000/-2.000000 NON_PLATED MILS Quantity = 2
%
G90
X210500Y171400
X215649Y171707
X217739Y171500
X210300Y167000
X216200Y166900
X213305Y166905
... ...

---

M48
INCH
;LEADER: 12
;HEADER:
;CODE : ASCII
;FILE : SPRAY_V1_3B_19110706-1-4.drl for ... layers TOP and BOTTOM
;DESIGN: SPRAY_V1_3B_19110706.brd
; Holesize 1. = 10.000000 Tolerance = +0.000000/-0.000000 PLATED MILS Quantity = 186
; Holesize 2. = 34.000000 Tolerance = +0.000000/-0.000000 PLATED MILS Quantity = 40
; Holesize 3. = 36.000000 Tolerance = +0.000000/-0.000000 PLATED MILS Quantity = 8
; Holesize 4. = 45.000000 Tolerance = +0.000000/-0.000000 PLATED MILS Quantity = 4
; Holesize 5. = 99.000000 Tolerance = +0.000000/-0.000000 PLATED MILS Quantity = 4
%
G90
X-0079800Y0036149
X-0075823Y0035965
X-0073823Y0002821
X-0076800Y0003199
X-0082075Y0001390
X-0284490Y0046800
X-0084400Y-0000506
X-0279290Y0046490
X-0056400Y0000631
X-0043100Y0044381
... ...

[mcous]

Shoot, of course it's Allegro. Similar issues over in #371, so I'm going to re-open this while I think about it. Would you mind posting that nc_param.txt file you referenced?

But I still have a question, how to confirm the places?

I believe that the hole sizes are in mils:

; Holesize 1. = 8.000000 Tolerance = +3.000000/-3.000000 PLATED MILS Quantity = 43
                ^^^^^^^^                                        ^^^^

So 8 mils becomes 0.008 inches becomes T01C0.008.

nc_param.txt contain INTEGER-PLACES and DECIMAL-PLACES

This probably refers to the drill coordinates themselves, but it's important information for tracespace to be able to parse them.

For example, I'm guessing the first file might have INTEGER_PLACES 2 and DECIMAL_PLACES 4

   decimal places
   vvvv
X210500Y171400
 ^^
 integer places

There are a few other, non-standard ways to specify this that tracespace understands. For example, a FORMAT comment block will do the trick

;FILE_FORMAT=2:4

[shawon1220]

@mcous Thank you, I am now pre-reading the content of art_param.txt to support Allegro format.
Has the exported file name changed by the user? I found that Allegro's file name is very bad, it seems that there is a problem with judging the layer by the file name. And I found Some gerber files only have art_param.txt, but some only have nc_param.txt.

nc_param.txt
art_param.txt

[mcous]

It looks like art_param.txt specifies properties of the Gerber file output and nc_param.txt specifies properties of the drill file output.

I was initially opposed to trying to parse those files in tracespace, but it's seeming more and more likely that it's a requirement for good Allegro support. I'm going to keep thinking about it and maybe add it to the pile of planned tracespace v5 features.

If you are able to share any of your work parsing these files, I'd be curious to see it!

[rgetz]

Would add - it’s mostly the larger semiconductor manufactures using Allegro - since they have all the cadence tools (for IC and SIP design) and just don’t buy anything else for PCB design.

[jaseg]

For reference, here are links to gerbonara's Allegro tool definition parsing code:
https://github.com/jaseg/gerbonara/blob/main/gerbonara/excellon.py#L579 (inline comments)
https://github.com/jaseg/gerbonara/blob/main/gerbonara/excellon.py#L87 (ncparam.txt)

[shawon1220]

it!

My current approach is to read the file line and then match if the layer'type is not matched by the file name. I'm currently testing as many open source gerber files as possible from the web, with various compression types and assorted suffixes.
Looking forward to the release of the new version of tracespace v5.

[shawon1220]

@mcous The test found that many gerber files have space problems, so I suggest whether it is possible to add space rules for the RE_TOOL_DEF:
var RE_TOOL_DEF = /^%ADD0*(\d{2,})([A-Za-z_$][\w\-.]*)(?:,\s{0,}((?:\s{0,}X?[\d.-]+)*))?/

Test case:

[jaseg]

Adding to the reply of @shawon1220 , both gerbv and KiCAD's gerbview ignore all embedded spaces (gerbv, kicad). While ucamco's spec clearly forbids spaces embedded inside the actual gerber code, this is probably a sane policy also outside of aperture definitions as I can totally see broken software emitting illegal spaces e.g. inside of aperture macro definitions.

Fun inconsistency: gerbv also ignores tabs and embedded null bytes (!), which AFAICT would make KiCAD justifiably choke.