kicad-developers team mailing list archive

[Martin Marmsoler <martin.marmsoler@xxxxxxxxx>]

Can you open this diagram in draw.io?
https://drive.google.com/file/d/1rBKeY-FXcvZxThrx6qSuzhS-VaCdgWb7/view?usp=sharing
I think the right branch how you are thinking to implement it and the left
one is mine. Maybe others have other preferences how the workflow should
look like. Just draw it into the diagram ;)

Cheers,

Martin

Am Do., 27. Aug. 2020 um 22:26 Uhr schrieb Jon Evans <jon@xxxxxxxxxxxxx>:

> I think the system I am describing could easily link to Part-DB as the
> backend, just looking at it briefly.
>
> That could be a cool application.
>
> -Jon
>
> On Thu, Aug 27, 2020 at 4:16 PM Martin Marmsoler <
> martin.marmsoler@xxxxxxxxx> wrote:
>
>>
>> On 8/27/20 10:04 PM, Jon Evans wrote:
>> >
>> > You can also choose to place symbols from a regular KiCad symbol
>> library.
>> > So you could just choose an inductor symbol, which would have no
>> > footprint association.
>> > Later when you know what inductor you need, you can replace that with
>> > a specific inductor from the database, which will bring in a footprint
>> > association with it.
>>
>> Yes this sounds like I proposed. For a part all checked symbols can be
>> assigned. So choosing a part which is not compatible with the current
>> symbol raises an error.
>>
>>
>> On 8/27/20 10:04 PM, Jon Evans wrote:
>> > I think that a database library could also have a place in a community
>> > setting, if the database is well-curated.
>> > This would likely mean some kind of web interface for browsing parts,
>> etc.
>> > It would be possible, but is beyond the scope of what I'm planning to
>> > work on at this point.
>>
>> For this I checked out if there exist an open source part database and
>> there I found Part-DB
>>
>> https://github.com/Part-DB/Part-DB-symfony
>>
>> You can test it also:
>>
>> https://part-db.herokuapp.com/en/
>>
>> For me it looks promising, but I checked it only shortly.
>>
>>
>>
>>