kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/30/2012 06:04 AM, Alexander Lunev wrote:
> Thank you for the comprehensive reply.
>
> On 06/27/2012 02:13 AM, Dick Hollenbeck wrote:
> > The library table allows concurrent use of PLUGIN::Footprint*() functions from multiple
> > alternative technologies.  It means you in theory would not need to convert PCAD, *.mod,
> > *.kicad_mod, or eagle footprints,
> > but rather you could use and edit them in situ, as if they were equivalently valid
> > footprints for Pcbnew.
>
> As I understand it actually works in theory only. If I ultimately convert some
> heterogeneous library to KiCad and somehow save it into
> new representation, say SWEET, then in most cases I will need to manually correct the
> new saved library components in order to fit their
> drawings in appropriate or better positions because of distortion caused by the
> conversion (positioning errors, shape approximation etc.)
> Moreover I can not imagine how to edit components in heterogeneous library in situ by
> means of KiCad not spoiling them because of
> distortion caused by import/export on-the-fly. Even though you edit
> the heterogeneous components in situ and manually edit/adapt them to
> KiCad, these components will no longer be well representable in the original
> (heterogeneous) CAD.
>
> Do I understand you right concerning 'in situ'?


Can we talk about one program at a time?  Let's focus on Pcbnew, for which the PLUGIN
interface exists.
Eeschema is for another day, and I don't think it is pertinent yet.

What you are saying will be fractionally true, with different magnitudes of truth
depending on the foreign EDA tool, and to the extent that each foreign tool has features
that Pcbnew footprints do not support in its footprints.

I don't see where rounding of numbers enters into it, since we now go to nanometer resolution.

The greater the compatibility in footprint features, the greater the ability to round trip
footprints. 

In the case of Eagle, I did not see anything preventing us from writing FootprintSave()
and FootprintLoad() and actually using Eagle footprints almost as well as they do,
including editing them.  In situ means "in place".   This means just use eagle footprints
where they live, say under the Eagle directory elsewhere on your hard drive, no need to
convert them to a different file format.  Also keep in mind that:

a) because the PLUGIN::Footprint*() functions position the MODULE as the go between
entity, the design encourages the enhancement of MODULE to accomadate features from other
EDA tools that we currently do not support.

b) most of the time footprints are read only entities, for if they were not, why in the
world would the default install of footprint libraries on linux do so into a read only
directory?

c) If you can read a footprint well enough to convert it, you can read it well enough to
certainly use it without writing back to disk other than in a BOARD via instantiation.

d) If you can read a footprint well enough to convert it, often you can figure out how to
write it back out in the foreign format.  Two reasons why you might WANT to do this are:
   1) you intend to inter-operate with a community of designers using that foreign tool,
2) you would like them to eventually feel comfortable enough with KiCad to convert.  This
is not particularly different than what Open Office has done.  They have supported both
read and write capability in many different file formats.

e) There is Pcbnew code to load a geda footprint now, if it was put into a PLUGIN, then
you'd have read only capability to use those libraries in situ, i.e. without converting
them first.


> Even though you edit the heterogeneous components in situ and manually edit/adapt them to
> KiCad, these components will no longer be well representable in the original (heterogeneous) CAD.


I don't know how you get to that above supposition.  If you write PLUGIN::FootprintSave()
then you preserve the ability of the original EDA tool to use your footprint edits.  This
is somewhat like when I send a *.doc file to a MS Word using that I created using Open Office.


The last thing I would say about the value of the PLUGIN API is that it is an organizing
mechanism for future evolution.  Just by putting code into the slots provided in the
plublic PLUGIN API, you are making somebody else's goals more achievable later in time.  
Organized, longer term enhancements become easier.  The Most Elaborate Plan becomes
easier, incrementally.

The cheapest plan of all is one I did not mention, and that is to inject PCAD_PLUGIN into
your conversion program, and simply implement as many of the functions in that separate
executable as you can.  This then becomes a building block for someone more ambitious
later on.


Dick


> Best regards,
> Alexander Lunev
>
> ------------------------------------------------------------------------------------------
> *From:* Dick Hollenbeck <dick@xxxxxxxxxxx>
> *To:* kicad-developers@xxxxxxxxxxxxxxxxxxx
> *Sent:* Wednesday, June 27, 2012 2:13 AM
> *Subject:* Re: [Kicad-developers] P-Cad plug-in
>
> On 06/26/2012 02:23 PM, Alexander Lunev wrote:
> > It was suggested to implement pcad2kicad converter as pcbnew plug-in. It is clear how
> to do this in the case of pcbnew. Even it is clear
> > how to do this in the case of eeschema. But it is not clear what to do with
> translation of P-Cad libraries (pcb and schematic libraries).
> >
> > Now there are 4 different modes in pcad2kicad converter: converting pcb design files,
> converting pcb library files, converting sch design
> > files and converting sch library files. Considering the user interface how the
> converting libraries could be implemented applied to KiCad?
> > Any considerations?
>
>
> Here are a couple of alternative plans for the *Pcbnew* portion of the
> problem/opportunity.  The degree of thoroughness can vary because Pcbnew PLUGIN
> can be implemented to varying degrees.  If you do not implement a function this is not a
> fatal problem.
>
>
> Elaborate Plan:
> ==============
> a) Implement *all* the functions in PCAD_PLUGIN, especially all PCAD_PLUGIN::Footprint*().
>
> b) Also implement a library table for Pcbnew, see new/sch_lib_table.h and
> new/sch_lib_table.cpp as the basis of
> some new similar class, but you replace LIB_TABLE::ROW::lib with a PLUGIN* pointer.  This
> architecture
> replaces the Pcbnew library search path design with a library table design.  An initial
> library table could
> simply be an s-expression text file, like is being parsed for SWEET already.  Could use
> that parser as as starting point, its done, it works.
>
> The library table allows concurrent use of PLUGIN::Footprint*() functions from multiple
> alternative technologies.  It means you in theory would not need to convert PCAD, *.mod,
> *.kicad_mod, or eagle footprints,
> but rather you could use and edit them in situ, as if they were equivalently valid
> footprints for Pcbnew.
>
>
> Mid-level Plan:
> ================
> a) Implement just the Load() & Footprint{Load,Enumerate}() read only type functions.
>
> b) Also implement the library table as above.  But hard code any writing of footprints
> back through the new KICAD_PLUGIN.
> This basically gives you a read only or edge triggered conversion of footprints, but lets
> you access them natively in situ.
>
>
> Lazy Plan:
> ==========
> a) Implement just the Load() & Footprint{Load,Enumerate}() read only type functions.
>
> b) Use Miguels scripting to convert from PCAD to s-expression both boards and footprints
> on the assumption that the scripting housing could simaltaneously manage two plugins.
> Read a footprint, write a footprint.  Read a board, write a board.  You bother with
> scripting because its going to happen again on the next PLUGIN.
>
>
> One of the most frequently reported bug reports that has been seen over the last five
> years is the library search path.  I don't like that design and never have.
> Obviously I have thought that the library table concept is better, since that is what I
> had coded for SWEET.  You can actually see it in operation if you single step
> through the SWEET test program.  The key to it is the "logical library name".  In Pcbnew
> you have something like a shortened library name in the UI already, and it is currently
> the last part of the library path.  With the library table, it becomes more meaningful, it
> is an index into the library table.
>
> So if you can see the value in the library table concept, it needs to come in even on its
> own merits, aside from this discussion.  Once there is buy in for that,
> then the Mid-level Plan starts looking pretty doable for footprint access.
>
> In all cases, just having PLUGIN::Load() gives you the BOARD.  So selecting a plan from
> above is tantamount to deciding how you plan on handling footprints.
>
>
> ================================================
>
> EESCHEMA
>
> My concept for SWEET does not encompass any full schematic treatment like PLUGIN::Save()
> or Load().  I only intended to support part retrieval, and since the major driver was to
> get these parts over the Internet, the representation of the part is SWEET text.  This
> means that if you were going to convert from a foreign format, you would do it way down
> low, and are actually required to return a SWEET string, not actually load it into a C++
> structure.  So the design is completely different in the following ways:
>
> a) API requires that SWEET *textual* representation be the returned results.
> b) API intends to be REMOTED.
> c) Inheritance is supported, we can and want to do small changes to someone else's work,
> and this requires text to do it.
>
> It does not contemplate nor address anything to do with full schematic loading.  In fact,
> this library could be used by any other schematic tool, perhaps geda.
>
> Since SWEET is not part of EESCHEMA, and SWEET is not a schematic plugin, but rather a
> part plugin for a schematic tool, you do have the option of simply creating a new
> PLUGIN design for EESCHEMA which only encompasses the full schematic, i.e. Load() and
> Save().  Leave the part plugin portion out of it and plan on incorporating SWEET down the
> line.
>
>
> Dick
>
>
>
>
> >
> > Best regards,
> > Alexander Lunev
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/%7Ekicad-developers>
> > Post to    : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/%7Ekicad-developers>
> > More help  : https://help.launchpad.net/ListHelp
> > .
> >
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/%7Ekicad-developers>
> Post to    : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/%7Ekicad-developers>
> More help  : https://help.launchpad.net/ListHelp
>
>