kicad-developers team mailing list archive
Mailing list archive
Re: About MCAD integration
We would like IDF3 support. I have previously gotten it working with Eagle.
I think IDF export can best be implemented in the Python API.
It is a shame that most of the opensource MCAD tools are broken.
WebGL based solutions are not an option for most of the large assemblies
we work with.
In my experience it just usually goes ECAD -> MCAD because cases are
after the boards are mostly working. The tools are optimized for the
common use case, but
are terrible if you try to send changes back.
IDF4 will never be supported because it is good enough to move data from
SolidWorks to Pro/E
and back with no loss. Same thing goes for Altium to KiCad.
The nice thing about IDF is you can specify a rough 3D bounding
box/cylinder as the model and the MCAD
software can swap it out for a local high quality version if available.
This pushes the modeling on to
the mechanical side where it belongs.
On 05/05/2013 09:50 PM, Cirilo Bernardo wrote:
> ----- Original Message -----
>> From: Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>
>> To: Kicad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Sent: Sunday, May 5, 2013 10:29 PM
>> Subject: [Kicad-developers] About MCAD integration
>> People keep asking about this... at the moment DXF is the only useful
>> way to export a board to a 3D mcad (then you estrude it 1,6mm, usually,
>> but you don't have component boundaries and stuff).
>> IDF3 *is* plausible to make, but does actually someone want it? In
>> SolidWorks AFAIK you have to buy a special purpose module to import it
>> (strange thing: while IDF3 is designed to go both ways, it seems that
>> only the ECAD->MCAD route is used). IDF4 exists but AFAIK nobody uses it
>> (like IPC356B!)
> DXF is not really useful for this purpose.
> IDF3 works both ways (ECAD->MCAD and MCAD->ECAD) but all tools I have seen will rewrite an entire set of IDF3 files; I do not know of any software which makes changes to the files as described in the specification. IDF3 also has so many limitations; for example everything is an extruded footprint so you can't describe finer details - this makes more work for the mechanical designer when checking information such as panel cutouts for PCB mounted parts. In practice I've taken IDF3 files and replaced critical components with adequate 3D MCAD models; this isn't so bad in many (most?) cases, but I believe we can improve that. :)
> Despite its flaws, many people do use IDF3. The specification is extremely simple so it's not too difficult to implement; however, someone has to put in the time to create the footprints and manage them. This is a big job and it is why I haven't put any effort into IDF3 export.
> You're right about IDF4 - very few people seem to use it. In fact I don't know if even SolidWorks 2013 supports it. On one side people seem to use IDF3; on the other side (EADS and other huge companies) people seem to use PSI5 (like STEP, you pay $$$ for the specification).
> See below for my comments on STEP.
>> General consensus is that STEP is the desiderable format (too bad IGES
>> went out of popularity... it was freely documented and it's the
>> precursor of STEP). However it's huge, no, bigger than huge, it's
>> ISO-committee-designed. I have found this old message around, for more
> Don't even think about implementing a STEP library; that's a job which would take a large team many years. It is best for us to make use of existing tools like OpenCascade, but I also suggest that MCAD support should be done by external tools and we should not make KiCAD dependent on any specific MCAD. A scheme I suggested last year should work OK and require minimal support in KiCAD - basically a few more tags to point to 3D models, which is similar to what is currently done for VRML. The 3D model associations will have to be abstracted so that KiCAD can manage the associations without really caring about the specifics of the 3D tool (MCAD, VRML, etc).
>> The only STEP toolkit available for open source is the one in
>> OpenCASCADE. The zipped tar is more than 110MB (it's a whole geometry
>> engine for cad...), I feel it's a little big as a dependency :D It seems
>> that freecad uses it.
>> I tried to look inside a STEP file. It's quite readable actually, *if*
>> you have the schema to cross reference with. Too bad you have to pay,
>> a lot, for that. And extremely verbose; it's actually a dump of a graph
>> database (a good idea for a cad format IMHO). Too bad that for
>> describing a parallelepiped geometry the ST-Developer kit (commercial)
>> uses no less than 215 object (*two hundred fifteen* objects). And that
>> using the AP-203 (the entry level schema). I reordered and indented the
>> thing, it's quite obvious what is going on. I'll try to add a hole in
>> that box to see what infernal representation it spawns:D
>> However it seems feasible to reverse engineer the format for generating
>> at least something like the IDF3 representation: board shape and prisms
>> for component shapes. Not exactly like having the 'perfect' model, but
>> beats extruding the board profile from the dxf at least.
>> Any ideas on this? IIRC there were some people interested in this kind
>> of thing.
> Ultimately STEP is probably the most supported format for exchanging 3D information; however it is an inconvenient format to use within an MCAD due to the memory consumption. My idea was to wait until FreeCAD supports assemblies, then work on a tool to generate a FreeCAD assembly using the KiCAD pcb file and the native MCAD definitions for each component. This way KiCAD is not tied to any specific MCAD. The 3D effort can also be concentrated on native FreeCAD descriptions and these should be much smaller files than STEP. People then have the option of doing their own packaging designs with FreeCAD, but they can also export the assembly to STEP so that people can use whatever MCAD they want for the mechanical design. FreeCAD can also import STEP, so we can still make use of the numerous STEP files of parts available on sites like RS and in fact it should be possible to mix native and STEP models in a FreeCAD assembly.
> Even if we supported MCAD via FreeCAD, I imagine some people will still want IDF3 just because that's what their work requires; recently someone was asking about IDF3 support on the user list because their company required IDF3 and a STEP generated via VRML->STL->STEP was not acceptable.
> For 3D MCAD models I wonder if it is good enough to just model the rough volumes (for example, pins on a QFP would be 4 wide tabs on each side of the package rather than individual pins) or if there is currently any need or foreseeable future need for much better fine detail in the model. Obviously with better detail the MCAD can produce better eye candy, but for all work that I've done I can't imagine a use for the fine detail except where cutouts are needed.
> - Cirilo
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp