kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

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

> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: "kicad-developers@xxxxxxxxxxxxxxxxxxx" <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Cc: 
> Sent: Thursday, December 5, 2013 10:53 AM
> Subject: Re: [Kicad-developers] Development of IDFv3 export
> 
> On 12/4/2013 3:56 PM, Cirilo Bernardo wrote:
>>  ----- Original Message -----
>> 
>>>  From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>>  To: Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>; 
> "kicad-developers@xxxxxxxxxxxxxxxxxxx" 
> <kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>  Cc: 
>>>  Sent: Thursday, December 5, 2013 7:36 AM
>>>  Subject: Re: [Kicad-developers] Development of IDFv3 export
>>> 
>>>  On 12/4/2013 2:46 PM, Cirilo Bernardo wrote:
>>>>   ----- Original Message -----
>>>> 
>>>>>   From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>>>>   To: kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>   Cc: 
>>>>>   Sent: Thursday, December 5, 2013 1:24 AM
>>>>>   Subject: Re: [Kicad-developers] Development of IDFv3 export
>>>>> 
>>>>>   On 12/4/2013 4:02 AM, Cirilo Bernardo wrote:
>>>>>>    Hi folks,
>>>>>> 
>>>>>>     I've just tested a very bare IDFv3 exporter since I 
>>>  didn't have 
>>>>>   the patience to manually model a board with almost 300 
> thru-holes. The 
>>>  code 
>>>>>   works in much the same way as the gencad and vrml exporters.  
> I just 
>>>  have to 
>>>>>   clean up the code, sort out the dialog issues (I cry whenever 
> I have to 
>>>  work 
>>>>>   with wxformbuilder), and prepare the patches.
>>>>>> 
>>>>>>     What the code does:
>>>>>>    1. exports a rectangular board based on the board 
> bounding box; 
>>>  the board 
>>>>>   is reduced in size to compensate for a 0.1mm line width.  The 
> intention 
>>>  is to 
>>>>>   eventually create an outline from the information in the edge 
> layer; 
>>>  however, 
>>>>>   the information in the edge layer will require some processing 
> to 
>>>  present it in 
>>>>>   an IDF compliant form.
>>>>> 
>>>>>   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.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>>   The change to the board format would be to support the IDF library 
> and 
>>>  future solid model work. Basically a scheme is needed to specify 
> information for 
>>>  multiple types of 3D information as opposed to only VRML. The current 
> IDF code 
>>>  only exports a board with holes though, so no change is necessary to 
> accommodate 
>>>  this; any proposed changes to the format are still a future thing and 
> require 
>>>  more thought.
>>>> 
>>>>   - Cirilo
>>>> 
>>>> 
>>> 
>>>  As far as I tell this would only be required if you needed to import 
> IDF
>>>  files in which case you would only need to add a file type to the model
>>>  definition.  Before I would consider such a change, I would require the
>>>  implementer to create a well designed plug in architecture for loading
>>>  and saving various model file types similar to the design used by the
>>>  board plugin architecture.  This would prevent the mess we used to have
>>>  in regard to loading third party footprint library and board files in
>>>  Pcbnew.
>>> 
>>> 
>>>  Wayne
>>> 
>> 
>>  No problem. I think for now I'll leave the first cut of the IDF 
> exporter simply exporting rectangular boards with holes and a 3mm extrusion of 
> the module bounding boxes; this should be possible to implement in a fairly 
> small patch. If you prefer I continue development to the stage where I can do a 
> correct export of the outline before submitting a patch, just let me know.
>> 
>>  I'll have a closer look at the code as time permits and think about 
> what needs to be done for future solid model work. Ultimately I'll have to 
> put time into the plugin architecture that you mentioned, but I'm keen to 
> add to KiCad's ability to generate 3D models which MCAD folks can work with.
>> 
>>  - Cirilo
>> 
> 
> I think you will be better served giving it some thought up front.  It's
> always a lot more work to go back and fix it after the fact.
> 
> 


Yes, I realize that. I always make my software extensible; even refactoring has been somewhat painless with the way I design things. What I currently propose is to submit patches for IDF export of a rectangular board with holes.  This requires the addition of a few files for the GUI and of course the export implementation, but does not make any intrusive changes to the existing codebase and requires absolutely no format changes. There would be nothing broken to be fixed here; my next step would be to implement the correct outline export. At that stage at least the board with holes is easily exported to MCAD even though the components won't be there.

 My next incremental change would be to put component bounding boxes on the board to represent the components; this is quick and dirty, but not much time will be lost if I rip it out later to implement something better.  Everything after that will require a lot of thought and planning before proceeding. The implementation of per-component heights and IDF outlines will be more intrusive, so an improved component outline export is something which requires a lot more thought and some comments from developers. Although one of Lorenzo's suggestions to use an extrusion layer to provide the outline is tempting, as much as possible I'd rather not take up any valuable layers.

- Cirilo