← Back to team overview

kicad-developers team mailing list archive

Re: Development of IDFv3 export

 

----- Original Message -----

> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Cc: 
> Sent: Thursday, December 5, 2013 2:40 AM
> Subject: Re: [Kicad-developers] Development of IDFv3 export
> 
> On 12/4/2013 10:23 AM, Lorenzo Marcantonio wrote:
>>  On Wed, Dec 04, 2013 at 09:24:15AM -0500, Wayne Stambaugh wrote:
>>>  What is missing from the board file format that is required to export 
> to
>>>  IDFv3?  None the the other exporters required any changes to the board
>>>  file format.  I'm not thrilled about the idea of changing the board 
> file
>>>  format just to satisfy exporting to another file format.
>> 
>>  I already did some feasibility study a while ago, nothing is needed
>>  (except some way to convey height information for the modules, if
>>  wanted). Also if he picks the segment in the board instead of taking the
>>  bounding box he will a) handle the more-common-than-you-think case of
>>  nonrectangular boards and b) not need the 0.1mm reduction hack.
> 
> I didn't think any changes were required but I'm no IDFv3 expert.  I
> would prefer to see the actual board outline implemented before
> committing this feature to KiCad.  More than 50% of the boards that I
> design are *not* rectangular so this would be a show stopper for me.
> 


The code I'm working on will initially only use the bounding box; this is due to time constraints more than anything else and I had always planned to correctly implement the outline. For me it's a matter of getting some basic code in there that would be useful and then improving it.

>> 
>>  Every structure in the IDF3 is defined by wound polylines (board
>>  counterclockwise, cutouts clockwise), each segment can be a line or
>>  a circular arc segment. So nothing in pcbnew can't be represented in
>>  IDF3 (some math required:D)
>> 
>>  A better work could be done for holes, since IDF distinguish between
>>  mechanical, tooling, via and pins... since an NPTH hole is definitely
>>  a mounting hole, the only doubt is the plated hole (can be a pin or
>>  a 'grounded' mounted). Heuristics could help, maybe. Or maybe 
> simply
>>  nobody cares about the difference (like for some things in gencad).
> 
> Perhaps looking at the net connections could be used determine the
> heuristics.  If it cannot be determined, prompt the user to state the
> heuristics.
> 


For now I differentiate PTH/NPTH based on the pin's GetAttribute(). A hole is labeled "PIN" or "MTG" based on the identifier: 0, blank (if that can ever happen) or ~ are interpreted as MTG and everything else is PIN. For me the distinction really isn't important since even SolidWorks can't interact with IDF in the manner envisioned by the people who developed the specification.

- Cirilo



References