kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

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.



> 
>>
>> 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 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