Hi guys, The inclusion of manufacturer-specific libraries predate my arrival in the project so I cannot tell. Joachim, can you come up with a list of your symbols and in which original lib you would put them, so that we can compare the different options?
By the way, there is a script for moving parts from one library to another. It's here <https://github.com/KiCad/kicad-library-utils/blob/master/schlib/move_part.py> . Carl On Sat, May 14, 2016 at 10:16 AM, Patrik Bachan <patrikbac...@gmail.com> wrote: > Hi all, > Why should we have separate Interface library for LTC? There is already > Interface library. With separate library, aliasing is limited and same > function symbol similarity is difficult to maintain. > > I am not big fan of current library naming dualism purpose/manufacturer. > Was there any special reason to create manufacturer specific libraries? > > Patrik > > 2016-05-14 14:39 GMT+02:00 Carl Poirier <carl.poirie...@gmail.com>: > >> Hi Joachim, >> >> Are the LTC-specific footprints fitting in some already existing pretty >> libs? >> >> As for point 5, I had never noticed it myself, so I had to ask on the >> mailing list. There is an option in the preferences to disable that >> behavior, so yes it is desired. >> >> Carl >> >> On Wed, May 11, 2016 at 7:14 PM, Joachim Preissner < >> joac...@tailored-ip.com> wrote: >> >>> Hi Carl, >>> >>> thanks, well then - let’s get it in :) >>> >>> I’d suggest now to make the files >>> LTC_DataConversion, LTC_Interface, LTC_Power, LTC_SignalCondition, >>> LTC_Timing, LTC_Protection, LTC_RF. >>> There are also a few specific footprints. Should they go into the >>> existing prettys or is an extra Housings_LTC preferred? >>> >>> To item 5: >>> Although the symbol is defined with fields at certain positions (e.g. >>> centered footprint ref.) and certain alignments (left aligned >>> device name and reference), when placing it in the schematic, the fields >>> loose alignment and position (see attachments). >>> Is this a desired behavior? If yes, ok - if not, is it OS related (I’m >>> using Mac OSX). >>> >>> Eventually the position of the field on the symbol has an effect on this >>> behavior? >>> >>> Best Regards >>> Joachim >>> >>> >>> >>> Am 11.05.2016 um 02:41 schrieb Carl Poirier <carl.poirie...@gmail.com>: >>> >>> Hi Joachim, >>> >>> I had a look at your files. The library is very great and already >>> gigantic! >>> >>> In response to your questions: >>> >>> 1. Yes, let's split them right away. >>> 2. That would be LTC_Power as per rules 2.X >>> 3. No not really, you simply put them close. I suggest you have a look >>> at the Microchip_pic* libraries as an example. >>> 4. Yes, go for (a) (our libs are not consistent on that matter however). >>> Also, don't put the exposed pad on the symbol. The footprint name will >>> already indicate it in most cases by containing a "-1EP" as per rule 7.3. >>> You can make the symbols much smaller as well. >>> 5. I'm not sure to understand your question. >>> 6. Using aliases is the way to go. >>> >>> Please clarify question five so we can discuss it! >>> >>> Regards, >>> >>> Carl >>> >>> On Thu, May 5, 2016 at 5:18 PM, Joachim Preissner < >>> joac...@tailored-ip.com> wrote: >>> >>>> Hi Carl, >>>> >>>> Google is rejecting the zip due to the .lib files inside. >>>> Please accept the .txt renamed zip - provided it passes the gmail >>>> filter. >>>> >>>> Thanks & Regards >>>> Joachim >>>> >>>> >>>> >>>> Am 05.05.2016 um 21:48 schrieb Joachim Preissner < >>>> joac...@tailored-ip.com>: >>>> >>>> Hi Carl, >>>> >>>> well the easiest way to get an idea about my work in progress might be >>>> a look into the attached project. It should work out >>>> of the box. It includes a bunch of (partial) schematics to prove the >>>> symbols support a proper component placement. >>>> >>>> To the zip I also added the LibraryRules.txt file with a few open >>>> questions I’d like to discuss in advance. >>>> The current lib reports ~500 parts. I’d suggest to even start with >>>> several files. >>>> Many OpAmps are defined as aliases of generic units "OpAmp…", since >>>> they share all the same pinout often across all suppliers. >>>> I’d appreciate your opinion on this approach. >>>> >>>> My preferred symbol type is e.g. the LT3991 on page DC-DC-1. The >>>> exposed pad is also visually indicated on the symbol by the shaded square. >>>> >>>> Further below I just copied my few questions from the included file… >>>> >>>> Best Regards >>>> Joachim >>>> >>>> Initial Questions: >>>> 1. Provided the library will grow beyond 1000 parts, should it be split >>>> already at setup? >>>> Lineartech_Power (all power, LDO, Switcher, input protection, etc.) >>>> Lineartech_Mixed (mixed signal, ADCs, DACs, interfaces, etc.) >>>> Lineartech_Signal (pure analog signal conditioning, OpAmps, comps, >>>> references, etc.) >>>> Lineartech_RF (mixers, modulators, demods, etc.) >>>> Lineartech_Other (anything not in above ones) >>>> 2. Which library name complies to the nomentclature? >>>> LTC_power, LTC_Power, Lineartech_Power - which is preferred? >>>> 3. Should device name, reference and footprint fields be also placed on >>>> 0.1inch grid? >>>> 4. Pin names shall never overlap. >>>> If the footprint field in the center overlaps with pin names - >>>> a. move footprint field out of center to a non overlapping >>>> position >>>> b. enlarge the symbol outline >>>> c. the footprint field may overlap pin names (since it can be >>>> re-positioned in the schematic) >>>> I'd go for first a. then c. >>>> 5. Under wich conditions are the field locations in the symbols >>>> de-referenced in the schematic? >>>> 6. What is your opinion on the multi-part OpAmp devices? >>>> >>>> >>>> <LTCLIB_Share.zip> >>>> >>>> Am 04.05.2016 um 21:23 schrieb Carl Poirier <carl.poirie...@gmail.com>: >>>> >>>> Hi Joachim, >>>> >>>> We would be very grateful for your contribution. Can you please send us >>>> a list of the symbols included in your lib? We'll first look at the library >>>> structure. >>>> >>>> Right off the bat, I can tell you if your lib is passing the >>>> checklib.py script, it's a good start and probably not much will need >>>> adjustment for integrating into KiCad's library. Additionally, if you can >>>> maintain this lib over time that would be awesome. >>>> >>>> Regards, >>>> >>>> Carl >>>> >>>> On Tue, May 3, 2016 at 6:24 PM, Joachim Preissner < >>>> joac...@tailored-ip.com> wrote: >>>> >>>>> Hi there, >>>>> >>>>> what is the best way to add a new symbol library? >>>>> I tried it as a PR - which was closed as too large. >>>>> Over the time I created a lib of LTC parts (I'm working close with LTC) >>>>> ~500 parts. >>>>> My current files are passing the checklib.py script. There is also a >>>>> set >>>>> of schematic files >>>>> available where I checked, if the pinout is practical. >>>>> I understand that reviewing each and every device in detail is very >>>>> time >>>>> consuming. >>>>> >>>>> Is there a way to a review on "generic" level or even accredit me to >>>>> maintain this lib? >>>>> Please advise. >>>>> >>>>> Thanks >>>>> Joachim >>>>> -- >>>>> This message was sent from Launchpad by >>>>> Joachim Preissner (https://launchpad.net/~v-joachim) >>>>> using the "Contact this team's admins" link on the >>>>> kicad-lib-committers team >>>>> page (https://launchpad.net/~kicad-lib-committers). >>>>> For more information see >>>>> https://help.launchpad.net/YourAccount/ContactingPeople >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> Mailing list: https://launchpad.net/~kicad-lib-committers >> Post to : kicad-lib-committers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-lib-committers >> More help : https://help.launchpad.net/ListHelp >> >> >
-- Mailing list: https://launchpad.net/~kicad-lib-committers Post to : kicad-lib-committers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-lib-committers More help : https://help.launchpad.net/ListHelp
