Re: [Kicad-developers] Kicad Fields, was Re: [RFC] On net ties, microwave tools & custom pad shapes, altogether.
On 5/4/2016 10:40 PM, Strontium wrote: > I split this from the net-ties, etc RFC because its drifting off topic > from that discussion. > > I am not sure I understand the rationale to "It should also > be limited to passing information to external tools such as simulators > and scripts such as Tom's proposal"? Any feature that is internal to kicad should not be handled through fields. Other than the 4 mandatory fields, fields are reserved for user defined data. For example, the gate and pin swapping information could be passed via fields. However, this will be a internal kicad feature in the future and will be implemented as part of the file formats rather than using fields. The only exception I know of is the spice netlist formatter with uses text notes and/or fields to generate spice netlists. > > Both the Footprint and the Component Reference are "Fields" and > key:value pairs. I would imaging these are the first Fields that any > new Kicad user works with. > > Kicad has functionality to work with those "Fields" and they are core > information NOT just for external tools, they also convey information > from Schematic to PCB. Yet they are also just Key:Value field pairs. > > I agree that it requires documentation if the number of fields grows, > especially if they are not explicitly included like the default Field > list automatically includes Footprint and reference. Surely one way to > mitigate that is to have a list of "standard" Fields that can be > selected from in addition to typing them in. It would also be possible > to have a validator or entry dialogue for a "standard" fields "value", > similar to the footprint field. This is not a design proposal, merely a > suggestion of how this could be handled. > > It would also still be very "generally" useful to be able to add fields > to nets, and for that information to be able to propagate to the PCB > elements they reflect. Alternatively (and I actually think its > preferable) some mechanism to query that information from the schematic, > given a PCB object, eliminates the need to propagate it into the PCB > file and keeps it DRY. > > Whether for a core feature or not, Properly implemented, I can easily > imagine fields that carry arbitrary information between Schematic/PCB > being a killer feature, especially for scripting. It would then make it > easy to create scripts for all sorts of purposes and for their operation > to be generally parametrisable and documented in the schematic. > Something which now is not possible. User defined fields can contain any information that the user can think of and are available to scripts in both the schematic file and the netlist file. There is nothing preventing you from parsing this information with any script and doing whatever you want to do with the user defined field information. This is outside the scope of kicad and is left up to the imagination of the user. The key difference is "user" defined feature versus "kicad" defined feature. > > Examples: You could have a python script which produces tuned antennas > parametrically, and does it based on the parameters specified in the > schematic. > In the schematic, you place a component for a "mounting hole" you > declare for the "mounting hole" its actual co-ordinates, as it is a > constraint. Now a script run on the PCB can ensure that the mounting > holes are located in "exactly" the correct location as specified in the > schematic. > You could create a schematic representation for your board > "outline", and the field is the name of a DXF. In pcbnew, a script can > read that, and automatically load the DXF and draw the outline on the > outline layer. Change the DXF and the PCB can easily and quickly be > updated to redraw the outline layer. > > It would clearly be up to the developer of the script to document the > parameters and how the script is used, as its not "core" functionality. > BUT, a full library of "extended" functionality could grow around this > feature and it makes kicad significantly more powerful and significantly > easier to extend. I believe users would quickly become accustomed to > looking in the library for the "extended" features they want, as their > needs grow. > > > > > On 04/05/16 22:57, Wayne Stambaugh wrote: >> The use of fields for arbitrary data is indeed powerful. It should also >> be limited to passing information to external tools such as simulators >> and scripts such as Tom's proposal. Anything that is supported as a >> feature in KiCad should be part of the schematic file format and fully >> supported by the schematic editor. The problem with using fields is the >> user has to know how to define all of the attributes correctly which >> requires thorough documentation. I don't see this as a good solution >> for the average user. This is a bit like using regular expressions. >> They are really powerful but only a small number of users (typically >> developers) will actually
[Kicad-developers] Kicad Fields, was Re: [RFC] On net ties, microwave tools & custom pad shapes, altogether.
I split this from the net-ties, etc RFC because its drifting off topic from that discussion. I am not sure I understand the rationale to "It should also be limited to passing information to external tools such as simulators and scripts such as Tom's proposal"? Both the Footprint and the Component Reference are "Fields" and key:value pairs. I would imaging these are the first Fields that any new Kicad user works with. Kicad has functionality to work with those "Fields" and they are core information NOT just for external tools, they also convey information from Schematic to PCB. Yet they are also just Key:Value field pairs. I agree that it requires documentation if the number of fields grows, especially if they are not explicitly included like the default Field list automatically includes Footprint and reference. Surely one way to mitigate that is to have a list of "standard" Fields that can be selected from in addition to typing them in. It would also be possible to have a validator or entry dialogue for a "standard" fields "value", similar to the footprint field. This is not a design proposal, merely a suggestion of how this could be handled. It would also still be very "generally" useful to be able to add fields to nets, and for that information to be able to propagate to the PCB elements they reflect. Alternatively (and I actually think its preferable) some mechanism to query that information from the schematic, given a PCB object, eliminates the need to propagate it into the PCB file and keeps it DRY. Whether for a core feature or not, Properly implemented, I can easily imagine fields that carry arbitrary information between Schematic/PCB being a killer feature, especially for scripting. It would then make it easy to create scripts for all sorts of purposes and for their operation to be generally parametrisable and documented in the schematic. Something which now is not possible. Examples: You could have a python script which produces tuned antennas parametrically, and does it based on the parameters specified in the schematic. In the schematic, you place a component for a "mounting hole" you declare for the "mounting hole" its actual co-ordinates, as it is a constraint. Now a script run on the PCB can ensure that the mounting holes are located in "exactly" the correct location as specified in the schematic. You could create a schematic representation for your board "outline", and the field is the name of a DXF. In pcbnew, a script can read that, and automatically load the DXF and draw the outline on the outline layer. Change the DXF and the PCB can easily and quickly be updated to redraw the outline layer. It would clearly be up to the developer of the script to document the parameters and how the script is used, as its not "core" functionality. BUT, a full library of "extended" functionality could grow around this feature and it makes kicad significantly more powerful and significantly easier to extend. I believe users would quickly become accustomed to looking in the library for the "extended" features they want, as their needs grow. On 04/05/16 22:57, Wayne Stambaugh wrote: The use of fields for arbitrary data is indeed powerful. It should also be limited to passing information to external tools such as simulators and scripts such as Tom's proposal. Anything that is supported as a feature in KiCad should be part of the schematic file format and fully supported by the schematic editor. The problem with using fields is the user has to know how to define all of the attributes correctly which requires thorough documentation. I don't see this as a good solution for the average user. This is a bit like using regular expressions. They are really powerful but only a small number of users (typically developers) will actually know how to use them effectively. On 5/3/2016 7:13 PM, Strontium wrote: My 2c. One of the fantastically useful features of eeschema is components have an "arbitrary" list of key:value pairs (fields) attached to them as attributes. Can I suggest that such a feature attached to objects on the PCB would be even more powerful/useful. It would mean that changes like the ones suggested would not require further format changes to the pcb file, these attributes can be added/deleted at will as they are just a key:value pair. It would also make the file format backward/forward compatible, pcbnew wont care what the key:values are, it can read/edit/propagate them. If functionality exists to utilise them then it can use it, if not, they are passive, just like eeschema. Further, the key:value pairs in eeschema could be imported into the matching pcb objects, so that there is only 1 place that needs to be edited to set them (the schematic). (I actually think that should be the proper place to set them) And by objects I mean both components AND nets. At the moment only components have "fields" on the schematic,
