Hmm OK. Well first, NO ONE touches my libraries! (Sorry I didn't mean to yell.) Second, nothing would happen unless I had it opened and hit the "update library" button (Eagle) And most of the time once I've sent off the gerbers I never open the file again... well perhaps to print out a schematic. I guess there is sometimes a silk screen change after the first round of pcb's.
Finally I use Eagle. I mostly work within the Eagle environment. Is there some easy way to copy parts and footprints between libraries? (I don't expect you to answer that last one.) 'cause "in theory" I agree with what you suggest.
OK thanks Lasse, I'll give that a try. Maybe my version of Eagle is too old. (4.15) I don't see anything under export that is what I want. (I can export a script of the current library, or a partlist.)
The right click thing in a library works... it's more work than the export thing, as I have to go part by part... Anyway I'll give it a try for the next pcb.
But how do you do it before you enter the schematic? That's what I'm trying to do here.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
Before schematic, there's nothing... what would you librarificate?
...Are you meaning "library" the same way I'm meaning it? (Specifically, Altium has SchLib and PcbLib files, that contain whatever symbols and footprints, respectively, you've put in them. Or a few variations on that theme. Or cromulent, ready-made parts available through their "vault".)
(1) I produce a paper schematic and flat ASCII BOM; (2) BLH does schematic capture and layout; (3) If we're doing protos, we order boards and parts, BLH stuffs a couple, and I test them.
I'm trying to reduce the grunt work in all this. (BLH works a lot cheaper t han I do, but still.) We're going to start outsourcing some of the board st uffing, too.
Work directly in SCH, instead of on paper? (I don't mean that paper goes away completely, just that your final doodle be electronic.) Perhaps investigate tools that are easy to use: emphasis on speed.
1a. Instead of ASCII, use a spreadsheet? Simple database format of some sort? (Probably trivial anyway, say if your ASCII is usefully tab or comma separated.)
1b. Skip schematic and go right to netlist? (Error-prone for human users...) A lot of PCB tools can import netlists, or use them outright as the primary means of data transfer.
2a. Skip schematic and sketch the layout yourself?
2b. Sketch it in something like AutoCAD and send the file straight to the fabricators? (Some accept AutoCAD format!) (Drawing a PCB in AutoCAD sounds /terrible/. Don't take this as a serious recommendation...)
Hand stuffing is okay for protos, but it doesn't take much quantity to get a win from CMs.
MacroFab is one of the cheapest I've ever seen, and they're in TX I think.
As for big ticket professional services, they tend to start at several $k, so you probably won't be looking at many of those until you get into production (qty > 100?).
Still a bit confused about libraries and scripts... once you've created a part, that's sunk time, but re-use is more or less free. I don't see how you could script the schematic capture, at least in life-altering ways. At least until someone comes up with a schematic OCR tool -- which would be pretty cool tech, but probably quite a tough nut to crack as well.
It may be that I'm too thoroughly entrenched in the EDA paradigm to see what you're after. Would you like a toolkit of standard sub-circuits, perhaps? Or something like Verilog for circuits -- analog synthesis?
Thanks. I'm quite unlikely to start doing my own PCB CAD--if I were budgeting time for CAD, I'd certainly start with optomechanics. CAD is so very slow and clunky, though.
The BOMs are in a standard column format at the moment, manually maintained by yours truly. DFH is well along on a MySQL/Python database system for parts and assemblies, which will become the owner of the list and will generate CSVs of the current parts database. The plan is for me to interact with it mostly in that CSV format, still in columns. My text editor is very powerful and flexible, so that works pretty well. I often flip through the list (about 1000 parts so far) to find stuff I have in prototype stock or have used before or have had recommended to me by folks here. I'll maintain that list as well, because not all those parts are going into products just yet (or maybe ever), plus I use it for my consulting work. (*)
The DB program will sanitize my BOMs to (a) if there's an internal part number on the BOM line, make sure it's in the DB and all the other fields match exactly; or (b) if not, let me interactively generate a new part number with a description in standard format and standard vocabulary to make it easily searchable. That's things like
U17-xxxx-xx IC OPAMP 2X BIPOLAR 44 V 8 MHZ 3 nV PRECISION SO8 OP27GSZ AD
The DB will be more flexible in that we can have multiple manufacturers' P/Ns for a single internal P/N. It'll also have a fsck capability like git's, to make sure the DB is internally consistent. It also has the ability to keep track of how much stock of each part is where--that lets us use the simple cardboard-box-per-project inventory method where that makes sense, and then expand with bins in wire racks eventually.
Thanks for the steer for MacroFab--we'll check them out.
Cheers
Phil Hobbs
(*) My consulting customers have historically gone for the paper schematic option too--it's cheaper, and that way they can put it in their own CAD system their own way. BLH has been doing a lot more prototype boards for customers this year, so she's in practice.
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
Perhaps because I have been using CAD for schematics and PCBs since 1985 or so (Futurenet DASH-5 and MSDOS versions of PADS), I think I am much more quickly able to put together a schematic of a non-trivial design using such tools, than pen/pencil and paper. So I am still a bit flummoxed when I hear about those who insist on what I consider less efficient and obsolete methods and tools.
It does take some discipline and a lot of up-front time and effort to build a useful library, but once that is done, it is a simple matter to choose a part, drop it on the page, make duplicates if desired, and make connections. If a part is not in the database, there are "generic" part types for resistors, capacitors, transistors, op-amps, etc., which can be used, and then the specific part details can be added later and linked to the master library. A quick BOM listing will show parts that are missing such items as manufacturer, vendor, part numbers, and cost.
I have also used part attributes to specify what parts are used for alternate designs having the same PCB. For instance, I have a board used for two products: ORTM-4 and BTSA-3. They share much common circuitry but one has an additional section used for a timing function. So I just add "BTSA-3" to the "VERSION" attribute. For any parts used only for the ORTM-3 I label them accordingly. A simple filter in the BOM script creates parts lists for both designs.
Inventory control is a bit trickier, but at one time I designed a MS Access relational database that was able to produce assembly BOMs for various boards, and it could automatically "pull" the parts needed from the master database to update the quantity in stock and show which parts were in short supply. Each part had one or more links to manufacturer and vendor databases so purchase orders could be generated. Some things were tricky, such as accounting for quantity breaks and price changes and valuing inventory (cost averaging or FIFO). But the greatest difficulty came from improper entry of data (human error), especially when things were used by the inch or foot (like wire or metal) or even individual parts like hardware, when purchased by the roll, piece, or pound.
For small quantities and prototypes, such organization is mostly not necessary, but I still find it difficult to maintain control of my stock. The part numbering system makes it fairly easy to keep things in order, and for most SMT parts small coin envelopes work well. But since I use a system like "R_300R_1/8W_0805" and "R_300R_100W_", there needs to be a way to know that they will not be stored in the same place. One simple way is to make a dummy placeholder card indicating the actual location.
Perhaps this won't convince anyone to change, but it may explain why a simple "scriptable pcb package" may not be very helpful to accomplish the OP's goal.
They all stink, we just buy the best one we can afford...
Ok, so you've got a database of inventory (or previously used and approved parts), and want to work from that if possible?
Making a library of those components would be the best help -- place part on sheet, thumb through the list of parts until you find the exact one you need, and there you go.
I don't see the payoff being worthwhile for individual resistors and capacitors -- it's so much library maintenance just for one little chip part, and you'll have hundreds of them, eventually.
But sooner or later your schematic's part choices will have to be cross-referenced against your inventory, so you know which parts to fish out of the drawers and which ones to order (or order more of).
It's an open question, so you can decide how you wish to handle that -- if it's simply peeking at the database when "shopping" for a resistor to place, and making sure that the value you need is in the table (or not), then that's really about it.
Now, this is one thing that the mainstream EDA tools will impress you with, probably -- they can pull all that info from tables, so that, when you generate the BOM, all the columns from any matching components are available in the BOM as well.
So you can have a database link (which, in Altium, can be as simple as a spreadsheet laying around somewhere, or a proper database), and poof, all the stock quantities, numbers, locations, etc. show up. And you can generate the BOM to whatever quantity you want (say you want to buy 10 builds worth), and include Digikey (or etc.) hyperlinks in there, or stuff the data right into Digikey and generate a cart in few clicks.
As for creating component data -- Altium's supplier link system is very handy. Search for a part number, and you get a list of similar parts, from however many suppliers you have set up (there are six default installed suppliers; I don't know if there's a way to write your own interface, not that there are many other suppliers out there who provide internet APIs for searching their catalogs). Link the data into a component, and poof, the parameters are all there -- the dozen or two columns that Digikey has on most of their parts, for example.
You'd have to do some work to cram that data into a technical description, like you gave an example of, above -- but that could perhaps be scripted from the imported fields. (Altium has several scripting languages available.)
Probably, a lot of this can be done in others, even the simpler ones, like in Eagle with .ULP's. I don't know about that stuff (because it doesn't matter to me :) ).
That's one nice thing about Altium; it has a certain degree of industry-standardness.
Every EDA company is still quite greedily locking in their user base (Altium is no exception), but, those users still demand /some/ interoperability, whether by special export or conversion tool (say, saving in an ASCII format), or by direct import (e.g., Altium imports Eagle designs very faithfully).
And obviously, I'm highly biased with Altium, by experience and familiarity, so take that for what it is. Others may not do anything at all (Multisim/Ultiboard can't really import or export anything generally useful*), and others may have varying degrees of interoperability (some emphasize on more export options, etc.).
*With the one peculiarity that, Multisim can /import/ netlists as schematics. Yes, it places components and draws wires automatically! And yes, it's dreadfully slow and painfully ugly in the process! But it's pretty impressive that they implemented it at all...
Ideally automatic. We have to interface with the inventory system at some stage, so it makes sense to me to do it all in one place.
We have that already, coming from the other direction--i.e. the EDA tool doesn't own the database, we do. DFH's MySQL/Python one is integrating this with the inventory system.
I have a script that does most of that already, and it looks like we'll have the rest of it in beta in a couple of days.
Yeah, if you don't mind the steep price, the annual maintenance, and the uncertainty due to their having hived the whole thing off to a new dev group in China.
But doesn't export them again. ;)
As I say, we've been planning this out pretty carefully, and DFH has made a pretty good start. The MySQL/Python combo is pretty well-liked and has a lot of support, and it's easy to change as we learn what works best. I really really don't want to get locked in to an expensive vendor solution when it's apparently so easy to do ourselves in a reasonably scalable way.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.