[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Solving the light/heavy symbol problem
Metadata can be a parallel task.
In gschem you pick your resistor.
You have two buttons, place lite, place heavy. Place heavy brings up a second wizard to populate the heavy symbol, probably from your database.
Then place your symbol.
In pcb, when you import a schematic.
Any parts without footprints gets listed. Then you can populate the right footprint. And a back annotation mechanism to update upstream schematics.
As a third tool for series workflows
sch in to output updated sch, bom, and netlist.
Perhaps with features like, general remapping of footprints to the smallest package in your library.
Or to your preferred hand soldering size for that type of component.
Like ranking 0603 first, 0805 second, and 0402 third. Based on parameters like value and tolerance.
Option to use only the heavy part specified, i.e. Don't change out this part.
Steve
On May 20, 2011, at 6:34 PM, Cullen Newsom <cullennewsom@xxxxxxxxx> wrote:
> On Fri, May 20, 2011 at 4:09 PM, DJ Delorie <[1]dj@xxxxxxxxxxx> wrote:
>
>> I would love an easier way to generate footprints.
>
> Now that we're pre-parsing all the M4 footprints anyway, perhaps we
> could allow for a range of scripting options in the Makefiles that
> generate the library? There have been a few footprint-specific
> languages developed over the years.
>
>>> In all cases, one key problem is that there are so many potential
>>> heavy symbols that we cannot possibly have "all" of them.
>>
>> Nobody needs all possible heavy symbols, and disk space is cheap.
>
> No, but if we choose a subset, we pretty much guarantee that there
> will be users who need something we left out. I don't want to be
> replicating Digikey's database, for example, but any part I leave
> out
> is a part someone else might need.
>
> You could collect users' statistics anonymously and let it be a
> popularity contest. Especially if the databases were centralized.
>
>>> defer the problem to the user, who only puts effort intothe
>>> symbols they needed.
>>
>> Which puts many (often novice users) to the task of creating their
>> own symbol/footprints, and probably doing it wrong.
>
> Hmm... but does this mean we should do the work for them, or does
> this
> mean we need to come up with a better way for them to do the work?
>
> I'm hoping for "a better way for them to do the work" or even,
> "machine does most of the work" Teach them to fish and all that.
>
>>> * New users should find it easy to make their first PCB.
>>
>> Yes! New users, casual users, experienced users, all users.
>
> This is why I see no clear win between "just heavy" and "just light"
> -
> different users at different levels need different solutions. A new
> (to geda) user should be able to pick common parts from a list and
> make *something* that works, but an experienced user will eventually
> need to make their own.
>
>> Don't ship gSchem or PCB with any. At first run, and in preferences,
>> and in config files, give users the ability to choose their own
>> poison. Use git to
>
> If we go with the idea of "more than one library", we can ship a
> starter library (like, Radio Shack 500-in-1 parts list, or "Spice
> 101"
> with examples) and let the user import libraries from, say,
> gedasymbols.
> With my scheme, that would be a "starter database" instead, but
> similar results.
>
> Actually, with gedasymbols, *anyone* can make a small self-contained
> heavy symbol library. The problem happens when you want to make a
> self-contained *light* symbol library, then you need more logic in
> the
> tools to heavyify them.
>
>> synchronize with a (set of) master symbol and or footprints, and or
>> something else databases. Include options to use others' symbols /
>> parts (gedasymbols, luciani, etc). Include options for users to
>> share their own symbols via git. Create online symbol and footprint
>> generators that create standard footprints (at least for JEDEC
>> standard stuff) properly (according to best practices).
>
> hmmm... think about how a simple http:// changed the way we share
> information across the Internet. Think of how Facebook changed the
> way people manage their social lives. Are we prepared to put the
> effort into making something of *that* scale, for EDA? It would be
> cool if we got it right, but a pain if we didn't.
>
>
> Here's some pie-in-the sky for you. I can imagine a database with which
> a small number of users has full commit privileges, others' symbols /
> footprints (perhaps even by default / automatically) will be submitted,
> which would in turn generate a vetting request whereby a user with full
> access could approve or deny the new or modified files. Some effort
> would also be spent getting a machine to look for common mistakes and
> automatically reject them. I'd love to see it get all Web2.0-ish, and I
> think it could work very well. (if I only knew how to make it so).
>
> This also allows for footprints-by-cgi, another level of scripting
> them. Or
> script://$prefix/pcb/[2]dip-generator.pl?pins=16&width=300mil
> etc.
>
> Yes, this too. I've naively wished a thousand times or more for a
> machine that could take as its input a pdf datasheet, and produce as
> its output, symbols and footprints in some magically standardized
> format.
>
>> By the way, if you guys decide to tackle a big re-write, the IPC and
>> NIST tried to tackle this problem a few years ago.
>
> We've been using "standard" names for new footprints at least. When
> we can :-)
>
> Don't take any of this personally. I have a great affection and
> appreciation for gEDA and it's principles and goals.
>
> References
>
> 1. mailto:dj@xxxxxxxxxxx
> 2. http://dip-generator.pl/?pins=16&width=300mil
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user