On 9/17/2017 2:59 AM, Oliver Walters wrote: > Hi Wayne, others, > > It has been a while since I have heard anything on here regarding the > .sweet format for schematic symbols. > > I remember reading that Wayne was not wanting extra input on this, but > this was a very long time ago! > > With my current effort to consolidate the libraries before v5 release, > it has again brought into focus the areas in which the current symbol > file formats are lacking. > > For reference, the most recent version of the .sweet proposal I have > been able to find is here - > https://lists.launchpad.net/kicad-developers/binDp0KdUNMWc.bin (perhaps > there is a newer one Wayne?)
I have not updated it with the last round of proposals but it will not be much different. Once the stable 5 release is out, I will update the file format doc and open the discussion one last time before I start working on it. > > Following is a short list of question: > > *1. Specify multiple functions for a single pin* > > I have asked this before here > - https://lists.launchpad.net/kicad-developers/msg27071.html - however I > did not really get much of a response. > > It would be great to be able to assign multiple functions to a given > pin, and users can select a pin func (drop-down-box) which then enforces > ERC accordingly) This was already approved for the new file format and will be included. > > *2. Symbol Variants* > * > * > One of the pressing shortfalls in the current library scheme is that the > footprint field is common to all aliases. Thus, if a symbol is made for > e.g. a SOIC-8 there cannot be an alias for a DIP-8 version of the > symbol. Many components have pin-compatible footprints. > > In this case, is it as simple as doing the following: > > (part "MYPART_DIP-8" inherets "MYPART_SOIC-8" > (footprint "DIPS:DIP-8"> ) > > That's how I read the specification document. If my reading is correct, > then I think that's great. That is exactly how it's supposed to work. The "inherits" token is very powerful. > > *3. Token Default Values* > * > * > The spec. doc. does not indicate what default values will be inferred > from a file that is missing particular tokens. e.g. does a text field > missing the "visible" tag default to YES or NO? It implies the text field is visible. No token, implies not visible. I'm not opposed to using show/hide. I would rather a single token than a token with a state (visible yes/no) which is more verbose with no improvement in readability. > > Thanks, > > Oliver > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp