Re: [Kicad-lib-committers] Question on KiCAD schlib-format and extensions.

[Patrik Bachan]

AFAIk there is/was plan of new library format called sweet.
http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html#v5_sch_sweet
It has several pending dependencies.
I don't think that another format will make it to upstream.

Patrik Bachan (diggit)


so 22. 10. 2016 v 17:37 odesílatel Jan Krieger <j...@jkrieger.de> napsal:

Hi everybody!

does anybody of you know, how the plans to change also the schlibs of
KiCAD to a new fileformat (similar to the .pretty repos) are going forward?

... and do you know whether there will be new features in the new format?

I'm thinking of having the footprints a fourth thing that one can change
in ALIASes (see a discussion that I started here
https://github.com/KiCad/Potentiometers.pretty/pull/12 ... but didn't
get anywhere useful). This would be great, especially for components
like say diodes: Then we only need one symbol for all
diodes/transistors/... with the same pinout and have all sorts of
different types as aliases, where we just set the new
description+keywords+datasheet+footprint ... I think that would be
really usefull, also to maintain the lib.

A second thing would be special DCM-files (lets call them EDCM for now)
that are not tied to a specific LIB-file, but that can reference any
component from any .lib-file without the need for components in the EDCM
to be referenced in the .lib as ALIAS ... then this EDCM would be like a
database for components, e.g.:

$ECMP 1N4148 device.lib:D
D Diode
K diode
F ...
P Diodes_ThroughHole:Diode_DO-34_SOD68_Horizontal_RM7.5
$ENDECMP

... that would make maintenance of libs even easier (especially if we
had a simple table-editor for these files ...

What do you think?

Best,
JAN

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

Re: [Kicad-lib-committers] Hello & Question

[Patrik Bachan]

Hi and welcome on board :)

I wrote some functions to help me with PR handling. It is for fish shell,
but you can easily modify it for other shells.
You can find them here:
https://gist.github.com/diggit/4c6c6fb847180b8ebf6bab92884046d8
I use it on top of my forked symbol repo with additional remote called
"upstream" pointing to official kicad-symbols repo.
Calling `gupr 668` clones PR from upstream to branch 668, then opens
subshell and checkouts that branch. After finished work, just log out from
shell and you are back on master.

Patrik Bachan (diggit)

so 15. 10. 2016 v 22:08 odesílatel Ashton Johnson <acj0...@gmail.com>
napsal:

Glad to have you aboard, sir!

On Fri, Oct 14, 2016 at 6:29 AM Carl Poirier <carl.poirie...@gmail.com>
wrote:

Hi Jan,

Welcome to the team! Your contributions are very appreciated. :)

As for your question, there is one way that simplifies things a lot when it
is a PR for a .pretty. You can simply paste the URL of the repo into your
fp-lib-table (the project specific one will keep the other clean) and then
you have access to the footprints. However this won't work if the
contributor has committed to another branch than master.

By the way, we have the IRC channel if you want to join!

Regards,

Carl

On Oct 14, 2016 01:46, "Oliver Walters" <oliver.henry.walt...@gmail.com>
wrote:

Jan,

Welcome to our little group! I've been very impressed with the
contributions you have made so far :)

Regards,
Oliver

On Fri, Oct 14, 2016 at 4:44 PM, Jan Krieger <j...@jkrieger.de> wrote:

Dear all,

Carl Porier recruited me for the Library maintainers ;-) ... so Hi to
everybody!

Maybe a bit of background about me (so you know roughly who I am and what
to expect):
I'm a physicist with a PhD and a strong side in computer science, worked
relatively long in biophysics (building microscopes, writing data eval
software etc.) and now switched over to industry: I'm now a (senior)
software developer in a large German company that build offset and digital
printing machines in Heidelberg (southern Germany) ... so maybe you can
guess the name ;-) On the side IÄm designing electronics on and off (for
private use, or on the job) and have experience in several ECADs:
(Ultimate, Eagle: both very early, during the last years: Target3001).
And BTW: I live in Heidelberg/Germany, no kids 1 wife ;-)

I'm going to try and contribute a few hours (say 0.5-3) per week ... let's
see how that goes.

Now for my question: When reviewing a PR: Is thre a quick way to get the
changed files to my computer (maybe except the "View in GitHub desktop"
button)?

Best,
JAN


-- 
+-
|   Jan Krieger
|
|   j...@jkrieger.de
|   www.jkrieger.de
+-

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

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

Re: [Kicad-lib-committers] Some questions/ideas

[Patrik Bachan]

Hi Thomas, hi library team!

2016-07-08 19:44 GMT+02:00 Thomas Pointhuber :
> Hy library team,
>
> I have some points and would discuss them on the mailing list:
>
> At first, I would suggest to add LICENSE files into the .pretty
> repositories to clarify it (I'm also a little bit unsure about the
> license, but from what I see it should be GPL v2).

I agree, but as far as I remember, someone said, that .pretty repos
can contain *.kicad_mod files only.
If not, another thing to do is to move 3D-models to their footprint
.pretty repo. I makes much more sense to have them together, rather
than in symbol repo.

> Another question is about 3d-models. I already seen bunches of Models
> merged into KiCad which were clearly from the manufacture. From my
> perspective this would be a copyright infringement, because I haven't
> found a fitting permission/licence of the company which would allow this
> stuff.
> This could lead to legal issues in the future, so I would suggest to
> check this problem in detail and create treatment recommendation for the
> library team.

Yes, manufacturer's 3D-models in kicad repos could be legal issue.
Once repo LICENSE is specified, we can check manufacturer's license
for each pre-made model (future) or accept only user made models to
prevent problems.

> Now a non legal idea. What about adding contributor/author files into
> the .pretty and the schematic repository? I think they would be
> motivating for contributors and no big deal to manage.
Great idea!

> thx, Thomas
>
>
> --
> 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
>

As this is about questions and ideas, I'll add some mine.

I have some ideas about new structure format of symbol library files.
Is there any already opened discussion? (mailing list, forum,...?)
Current format causes a lot of redundant symbols, ineffective
footprint assignment and more.

Patrik
(TP: sorry for duplicity, I forgot to answer to mailing list)

2016-07-08 19:44 GMT+02:00 Thomas Pointhuber :
> Hy library team,
>
> I have some points and would discuss them on the mailing list:
>
> At first, I would suggest to add LICENSE files into the .pretty
> repositories to clarify it (I'm also a little bit unsure about the
> license, but from what I see it should be GPL v2).
>
> Another question is about 3d-models. I already seen bunches of Models
> merged into KiCad which were clearly from the manufacture. From my
> perspective this would be a copyright infringement, because I haven't
> found a fitting permission/licence of the company which would allow this
> stuff.
> This could lead to legal issues in the future, so I would suggest to
> check this problem in detail and create treatment recommendation for the
> library team.
>
> Now a non legal idea. What about adding contributor/author files into
> the .pretty and the schematic repository? I think they would be
> motivating for contributors and no big deal to manage.
>
> thx, Thomas
>
>
> --
> 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

Re: [Kicad-lib-committers] Adding a new library - lineartech

[Patrik Bachan]

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 :

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

[Kicad-lib-committers] "shields" as parts

[Patrik Bachan]

A have similar question as one in issue
https://github.com/KiCad/kicad-library/issues/391. Why there are not
symbols + footprints for so called "shields" instead of templates?
The only disadvantage is overlapping of such footprint with other
parts in pcb editor. So when you do some action (rotate,move,...)
above "nothing", but you work inside this footprint, you perform this
action with "shield's" footprint.
In my opinion, it makes sense to have it as symbol + footprint at
least for simple shields with pin headers and mount holes.

Patrik Bachan (diggit)

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

[Kicad-lib-committers] 3D models in Schematic symbol repository

[Patrik Bachan]

Why are 3D models with schematic symbols in one repository? 3D symbols
are tied together with footprints and they have nothing to do with
symbols. This results into multiple PRs for new footprints with 3D
models or filename changes.
Would be problem to merge 3D models into footprint repositories? (or
at lest separate them from symbols repo.)

Patrik Bachan (diggit)

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

Re: [Kicad-lib-committers] Idea about changing some default behavior of Kicad, to met KLC

[Patrik Bachan]

Hi,
I agree on all schematic symbol default changes. It will decrease
amount of KLC 3.6 violations.
I suggest setting default rectangle fill to BG.

There is a lot of symbols with footprint field using italics instead
of normal font. Any recommendation?
Then we can add an EC to check it.

F.SilkS layer is enabled for THT and NPTH by default, as i tested now.
But still, I can't see reason why.

Patrik Bachan (diggit)

2016-03-07 22:59 GMT+01:00 Thomas Pointhuber <thomas.pointhu...@gmx.at>:
> Hy,
>
> for the one which don't know. I'm one of the new library maintainers,
> with the GitHub username "pointhi".
>
> I try to start a discussion about changing some default values in Kicad,
> to simplify KLC compliant footprint drawings.
> The problem is, some default values are differ from the required value
> which is given in the KLC. Also there is some weird default behavior
> which should be probably changed.
>
> Here some problems, which I have noticed:
>
> * Text size of schematic symbols is per default 0.060, but KLC says 0.050
> * the width of lines in schematic symbols is per default 0.000, but now
> an inofficial KLC rule says 0.010
> * pads have by default the layer "S.SilkS" enabled, which is somehow
> useless. It get rendered on the 3D view, but doesn't appear on the
> gerber file and so also not on the finished pcb (it also wouldn't be
> usefull on the pcb at all).
>
> Probably there is some other default behavior which should also be improved.
>
> thx, pointhi
>
>
> --
> 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