Drill file parsing

[vec...@slingshot.co.nz]

OK, next problem...

FC can't get past "parsing" when I try to bring in a drill file.   Drill file attached.   This was originally made in PADs PowerPCB to match the other file I have sent you and has had the header manually edited in to load into another program called LineGrinder.   The header contains drills of identical size to get LineGrinder to show a size which I was having trouble seeing.   It does not contain the M95 for header closure because LG would not accept it.   What is missing or required to parse this file into FC ?

Chris

[vec...@slingshot.co.nz]

Any conclusion on the drill file ?   Strangely, I loaded it as a Gerber by mistake and it loaded in but nothing is displayed.   When loaded as an Excellon file it hangs on "parsing".   If I need to manually alter the file to add header lines or other things, I am happy to do that.

Chris

[jpcaram]

I found 2 issues:

1) There is a bug parsing the METRIC directive.

2) Your Excellon is non-compliant:

Tool changes should have the format: Txx
where xx are digits.

Your file has: TxxFyySzz
The F and the S should be part of the tool definition in the header. This is wrong according to the Excellon syntax. Does your program ask for any options when you export? Does it say what format it's exporting to?

I'm hoping to have a new release this weekend, which would have 1) solved, but I would like to find out more about the drill file format before I make any changes to the parser. Is there Any chance you can look at other drill files generated by other programs, or try generating a file with a different program, and see if they do the same? I've tested with Kicad already.

[vec...@slingshot.co.nz]

My reading of the Excellon format here:  http://www.excellon.com/manuals/program.htm  under "Duplicate commands" and further down under "Spindle RPM" indicate that one is allowed to re-specify the TxxFyySzz setting in the body of the program after setting in the header although it says that the header has precedence.   I am not trying to justify the PADs drill file output which I think is actually particularly poor, I am just reading the Excellon spec.   I am happy to manually modify the file to get it to work so long as it is not too laborious.   As I mentioned, the file I have posted has actually had the header added.   I imagine writing a parser for the Excellon format is not for the faint hearted !

PADs (my version 4.0.1) has 2 options for export, Excellon and "Drill Listing" as shown in the attached picture.   They both appear to output the same file.   The many other options that can be set can lead to files that do not conform to the Excellon standard.   There are literally hundreds of permutations, most of which will not be correct.   I have just tested the limits of the number format all the way from 8:0 to 0:8 without zero supression (44 different permutations !) and they all produce a file but few of them would conform !     However I have thousands of hours of investment with it both professionally and personally so am reluctant to try to port all my work and libraries to another PCB program but I am happy to try some of the permutations to test on your parser if you want.

I don't have any other PCB programs loaded at the moment but I will see what I have in archive.

Chris

[jpcaram]

Thanks for pointing that out. It seems you are allowed to re-specify spindle speed and other stuff in the body, but I will have to read it more carefully. I just want to be careful to implement a very clean parser that will not create other issues with cleaner fully compliant code. I might be able to include a fix in the next release.

[Anders Hellstrand]

I also found a drill file which got stucked on "parsed". It was creaded with the latest release of KiCad.

A proposal, Is to introduce a "debug mode" in the application for the parser which would be useful to identify the part of non compliant code which is expected to happend now and then given the number of PCB software applications in use.

[jpcaram]

Yes, it breaks Alpha 2. I will look into it.

Thanks!

[jpcaram]

This is the bug: Was not parsing numbers with a fractional part (with a period somewhere).

For now, you can export from KiCad or whatever app in the 2:4 format for instance. That should work. It might take me some time (a few weeks) to make a new release with the fix as I'm making some other large changes in the code at this time.

Thanks.