Re: [Kicad-developers] P-Cad plug-in
On 06/30/2012 11:05 AM, Dick Hollenbeck wrote: > 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 oops, user > 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
Re: [Kicad-developers] P-Cad plug-in
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 > *To:* kicad-developers@li
Re: [Kicad-developers] P-Cad plug-in
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'?
Best regards,
Alexander Lunev
From: Dick Hollenbeck
To: kicad-developers@lists.launchpad.net
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
