kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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