| Thread Previous • Date Previous • Date Next • Thread Next |
It also means that its not really an "abuse" of the footprint field, just that there are 2 kinds of footprint libraries, static and dynamic. Dynamic footprints are python module (I think Dynamic footprints should ALL be python modules, not single files, and each component in the module should be an implementation of a component base class, with known methods).
Dynamic footprints should have a set of sensible defaults when no dictionary is passed, so that they can render acceptably in the footprint viewer.
With regard to caching PCB footprints, I dont know why this is a problem?? it seems no different to placing a component on a PCB and then editing the footprint later. Once the footprint is placed, it should be a static graphical object, like any other footprint. It shouldn't update on the PCB unless the user tells it to. BUT if it is more complex than that, could not the time-stamp be used for that? The component could produce a unique hash, based ONLY on the parameters it uses, and that’s used in the time-stamp on the PCB. Any change to the parameters would change the time-stamp and so could be used to indicate the component changed?
As far as the fields themselves and their validity, as the component footprint is dynamic and a python script, it could be called sanely from the DRC pass of both the schematic and PCB editor. In the Schematic DRC check, it can verify the values of fields, and emit DRC errors/warning if any of them are wrong or badly formatted. Same goes for PCB DRC checks. This would not require specific changes to handle field formats in schematic/pcb but is just the ability to do custom DRC checks which would probably be required for dynamic components in any event.
And while we are at the topic of dynamic PCB components, would it not also make sense to dynamically generate the Schematic symbol for said component in exactly the same way?
On 12/05/16 00:33, Wayne Stambaugh wrote:
A standard format for the text of a given field is not the same thing as adding code to the schematic editor to edit that field. I do not want to introduce code into the schematic editor for generating formatted field text for external use. This should be done within the current field editor or an external text editor if you are so inclined. All fields are saved in the netlist so the netlist format will not need to be modified. On 5/11/2016 11:46 AM, José Ignacio wrote:If it's still too offensive, you could discard the naming part of my proposal and just modify the netlist format so that eeschema passes _all fields_ to pcbnew, that way the script can access them and do whatever it wants. It would enable all sorts of powerful things in the future, though it might complicate the "caching" behavior when deciding whether to regenerate footprints or not. On Wed, May 11, 2016 at 10:41 AM, José Ignacio <jose.cyborg@xxxxxxxxx> wrote: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_______________________________________________ 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
| Thread Previous • Date Previous • Date Next • Thread Next |
