kicad-developers team mailing list archive

[José Ignacio <jose.cyborg@xxxxxxxxx>]

It would not introduce a limitation, just a standard format that would
work with pcbnew footprint generators, external scripts can run
outside of kicad and use field names and values however they please.

On Wed, May 11, 2016 at 10:23 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> On 5/11/2016 10:24 AM, José Ignacio wrote:
>> What about (ab)using the footprint field (actually the library plugin
>> system) for this? Say you add a new library plugin called "python",
>> each library would be a python module (either a single .py file or a
>> folder with an __init__.py script) That module will have a callable
>> for each "virtual" footprint. Those callables will take in a
>> dictionary of key-values and spit out a footprint object. The name of
>> the callable will be the base name of the footprint, say, Microwave.py
>> having a Microstrip(**args) will be called out as
>> Microwave:Microstrip.
>>
>> To add parameters to the called footprint a dash "-" could be used as
>> the argument separator (as it is an illegal identifier for python
>> objects), with an underscore "_" to separate key and value. For
>> example a microstrip could be called out as
>> Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
>> Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
>> allows for some neat things to happen without touching much code in
>> both eeschema and pcbnew. When the dimensions change in eeschema,
>> pcbnew will automatically try to fetch the new footprint (which will
>> call the script) but the rest will be left alone as they have the same
>> name. This will also allow using the existing footprint archival
>> facilities to save "baked in" copies of the generated footprints.
>
> The text in a given field would be completely dependent on the script
> that would use it.  Key/value pairs may or may not make sense depending
> on the script.  The formatting of the field text should be left to the
> script developer.  The schematic editor should have no say in the
> formatting.
>
>>
>> To make editing parameters less cumbersome in eeschema it would be
>> neat to add a feature at netlist generation, for fields with special
>> names like "footprint(W)" with a value of say "10mil" will cause
>> eeschema to tack "-W_10mil" at the end of the footprint name when
>> generating the netlist. The policy for duplicated keys is that the
>> last one counts, and the keys would be sorted alphabetically to have a
>> predictable ordering.
>
> I would reject any change that would impose any formatting limitations
> on the field text.  Fields are merely generic text for anything the user
> can think of so all text is valid.  The formatting of the text is
> determined by the user not by schematic editor.
>
>>
>> Recap:
>>
>> The features that would be needed for this idea would be:
>> * A new pcbnew library plugin that calls functions in a python script
>> to generate footprints based on the footprint name
>>   - Perhaps later on build a toolkit library to ease the creation of
>> parametric footprints, an initial hacky version could be to just
>> generate SEXPRs in python and barf them into the existing kicad_mod
>> parser.
>> * A change in the eeschema netlister to append arguments to the footprint name
>> Format changes needed: none
>>
>> The python bit is optional actually, the library plugin could be done
>> in pure C++ if it proves to be easier, but having python access would
>> be the most flexible.
>>
>> What do you think of this idea?
>>
>> On Wed, May 11, 2016 at 8:24 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>> On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
>>>> On 09.05.2016 14:38, Wayne Stambaugh wrote:
>>>>> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
>>>>>> On 04.05.2016 16:48, Wayne Stambaugh wrote:
>>>>>>> How are you saving this auto generate flag and width/length parameters
>>>>>>> in the schematic?  If you are using component fields or text that's
>>>>>>> fine.  However, please keep in mind that using component fields and text
>>>>>>> is for passing information to third party tools that are not part of
>>>>>>> kicad.  If we are going to support net ties and micro wave component
>>>>>>> generation, we should do that as part of KiCad proper rather than treat
>>>>>>> it like a third party tool which you are proposing.
>>>>>>
>>>>>> Hi Wayne,
>>>>>>
>>>>>> I would store the microwave dimensions as key:value pairs, just like the
>>>>>> current schematic fields. I think microwave components will be best
>>>>>> handled by python scripting. These scripts should be IMHO permanently
>>>>>> included in Kicad distribution, not a 3rd party tool. I chose component
>>>>>> fields to pass the dimensions information because with every new exotic
>>>>>> shape (e.g. a Wilkinson power divider instead of a simple microstrip
>>>>>> line), we would need to add new tokens to the SCH file format and
>>>>>> netlist specification.
>>>>>
>>>>> Hey Tom,
>>>>>
>>>>> Would it be easier to provide a python script with a UI to input the
>>>>> dimensional information used to generate these complex microwave
>>>>> footprints and just associate them with a schematic symbol rather that
>>>>> trying to squeeze all of that dimensional information into a field?
>>>>> This may be more natural for the user to handle.  I understand the
>>>>> temptation to use fields to do this but I'm not sure this is the easiest
>>>>> path for users.  I just don't see users be comfortable with this in
>>>>> terms of usability.  Developers will have no issues with it but I'm
>>>>> trying to see this from a typical user's point of view.  It might be
>>>>> worth getting some feedback on the users forum.
>>>>
>>>> Hi Wayne,
>>>>
>>>> The tools I used in the past (Microwave Office/ADS) keeps all dimensions
>>>> in user-defined schematic symbol fields. AFAIK Qucs uses the same
>>>> philosophy. I think most microwave users are aware of this workflow. I
>>>> find it efficient because during the design/simulation phase I need very
>>>> often to change the dimensions of microstrip components. Running an
>>>> external script to update a footprint every time would be IMHO less
>>>> efficient and error prone.
>>>
>>> I hadn't considered the geometry data being passed to a simulator so it
>>> makes sense to keep this information in a field.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> For net ties, there's no schematic/netlist format changes, only PCB.
>>>>>>
>>>>>> I'm wondering how to handle the auto_generate flag. Maybe this one
>>>>>> justifies a separate file format entity connected to a checkbox in the
>>>>>> sch library editor and a text field specifying which plugin/script to run...
>>>>>
>>>>> The only risk I see with using a field as an auto_generate flag is field
>>>>> namespace pollution.  If someone inadvertently uses the auto_generate
>>>>> field name, I image a bunch of script errors would be a bit confusing.
>>>>> This risk is low but it is something to consider.  My proposal would
>>>>> eliminate the need for an auto_generate flag.
>>>>
>>>> How about keeping this flag outside the user-defined fields.
>>>
>>> I'm not sure how that would work without modifying the schematic or
>>> board file formats.  I'm not sure we should modify either file format
>>> since these scripts and the information they require are external to
>>> kicad.  What about using a field that calls out the script to run?  I
>>> don't know if it makes sense to run this every time a new netlist is
>>> generated.  You could always add a menu entry when the netlist is loaded
>>> in Pcbnew to run the script manually.  If we decide to go that route, we
>>> need to define a generic script field since it would be useful for
>>> things other than microwave generation.  The script field could look
>>> something like:
>>>
>>> RUN_XXXX script_name:data_field_name:menu_string:other_info
>>>
>>> This is just conceptual.  I'm not terribly concerned about the
>>> delimiters or formatting at this point.  Whatever we decide to
>>> implement, it will have to be well documented so users understand how to
>>> use it.
>>>
>>>>>
>>>>>>
>>>>>>> I don't want the
>>>>>>> component fields and text used for kicad features.  If you want to
>>>>>>> provide this as an interim solution, I am OK with that.  However, you
>>>>>>> may be creating more work for yourself when we finally get around to
>>>>>>> supporting net ties and micro wave component generation as part of the
>>>>>>> schematic editor.
>>>>>>
>>>>>> How do you see the role of the schematic editor in generation of
>>>>>> microwave components (in my proposal there's none)?
>>>>>
>>>>> I agree.  I don't pretend to be a microwave expert but AFAIK most if not
>>>>> all microwave features are complex geometrical shapes which should be
>>>>> treated as footprints and associated with a schematic symbol.  I don't
>>>>> see why the schematic editor would need to know anything about microwave
>>>>> footprints other than possibly passing parametric information via a
>>>>> field to the board editor.
>>>>
>>>> Sure. That's why I proposed to keep the parameters in user fields, as
>>>> there's so many microwave design technologies that it would be difficult
>>>> to standardize this as an internal Kicad feature. Moreover, the same
>>>> dimensions are needed both for simulation and PCB design (relying on the
>>>> netlist extracted from the schematics), so IMHO the schematic file is
>>>> the most logical place to store dimension information. We shouldn't also
>>>> forget about other uses of script-driven footprints (e.g. TouchSense
>>>> capacitive buttons/sliders, antennas, multilayer printed transformers),
>>>> which can use exactly the same technology.
>>>>
>>>> Cheers,
>>>> Tom
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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