kicad-developers team mailing list archive

[Andy Peters <devel@xxxxxxxxx>]

> On Jan 14, 2015, at 7:46 PM, Fat-Zer <fatzer2@xxxxxxxxx> wrote:
>> 
>> Sorry about accidental send previous message.
>> 
>> 2015-01-14 18:53 GMT+03:00 Andy Peters <devel@xxxxxxxxx>:
>> > 2. Different images of the same schematic component.
>> > There are already such variants for some common components like CP, also there are "small" variants for some components.
>> 
>> Who cares about a symbol variant? Pick the one you prefer and use it.


> yep, but for user can be able to easily chose it, kicad library should provide them out of the box... And I propouse a way to store them in library more straightforward IMO.

I guess I don't see the point. How many components have different symbols? Perhaps passives, where resistors can either be a rectangle or the v^v^v^v we all know and love?
> 
>>  
>> > In both such cases we can keep information about the component in single symbol.
>> > Also as a bonus we can easily support both IEC and US symbols and use it in some other cases.
>> 
>> Why? I think that a lot of advanced users will choose one symbol type and leave it at that, and not go the route of switching between one symbol variant and another.

> yep, but it's a suggestion in case of open hardware environment. It may be usefull in case you are reusing somebody's else workarounds. but it's not a first goal, just a suggestion for a bit more distant future...
> By the word, I'm not really experienced in that and may be totally wrong.

If you are reusing someone else's work, the simplest path is to just use whatever symbol that person chose. Why complicate matters, to little, if any, benefit?

>> > 3. To store pin number of component in additional field.
>> > Now cvpcb guesses pin number according to the pins displayed on the schematics. Which is wrong if some pins are not connected/not present in the schematics at all.
>> 
>> That problem is solved by not using CvPCB at all, and doing as I suggest above.
> 
> Yep... From your words the getting rid of cvpcb sounds great... if you can handle such a work (taking in mind that schematic and footprint library are nearly two different pices of data for now) I, personally, will appreciate it... and I believe it will be appreciated by a lot of other members of the community... I won't have enough time and (honestly speaking) skills to do that on my own...

That the symbol libraries and footprint libraries are separate doesn't bother me at all. In fact, I think that it makes perfect sense. How many parts use an SOIC-8 footprint? A zillion. So why carry the footprint around with each of these zillion parts, when each part can just point to a library and a footprint? 

I honestly don't see how setting up library _COMPONENTS_ (defined as a marriage between a symbol, a footprint, and something that points to, or is, an orderable part number) just once is more difficult that drawing a schematic with generic symbols and then using an intermediate tool to marry a symbol with a footprint _for each symbol_ and _for each new design_.  Sure, the _component_ is "represented" by a symbol in the schematic library, but in most designs the schematic is the master (the "source code," if you will).

>> OK, I realize that the point is to somehow improve library sharing. I think that's an excellent goal. But I also think that at some point, it breaks down. Unless all shared libraries adhere to the same standards, inevitably you have problems. And I know you can't please everyone, so perhaps the correct way to go is to support the hobbyists who don't want to create a complex library system for a small design, and the advanced/professional users will build company/vetted libraries.
> Yes, that is... IMO the main audience of the kicad will be hobiest and some more experienced people from openhardware world for the nearest future. So the idea to support there needs doesn't sounds so crazy, isn't it? ))

I'm not sure the main audience for Kicad is hobbyists. I can't be the only "do it for a living" EE who needs a quality EDA package and would like to buy Altium but can't afford it and just simply hates EAGLE.

oh, and for what it's worth, I don't give a shit about the whole Open Hardware movement. I mean, I think it's cool, and I think it's great that hobbyists are interested in electronics. (And my 6-year-old son is turning out to be quite adept at soldering the couple of things he got from Adafruit for the holidays!) And I certainly am not opposed to throwing a design or two out there to the community to do with what they will. I just don't want to get caught up in the whole support aspect; I don't have the time.

(I participate in this mailing list because I am truly interested in helping the developers get the OS X port functioning as well as possible, so I test the patches and do what I can. I'm not a deep applications programmer so I don't delve into the code.)

---------

If anyone is still reading this far down, you may have noticed that I keep saying that I my schematic symbols include both the footprint pointer AND a custom field called "PN." This is my "in-house part number." I have created a simple spreadsheet, organized by PN, which takes the PN and maps it to a vendor and vendor orderable part number. For each part number I also list the schematic symbol, the footprint, the libraries in which both can be found, a quantity-25 price, and how many of the parts I have on hand.

I export this parts list as a CSV. Then I export a BOM for the design from eeschema. A python script reads the parts list and the BOM and spits out a CSV file which contains total number of each part, vendor and vendor P/N, a list of reference designators for each, and a total BOM cost for the design.

At some point I will add a feature which creates an order sheet to buy parts that I don't have in stock. (This is all really veering off into MRP world, isn't it?)

The spreadsheet is in Apple's Numbers format. The goal is to figure out how to read the spreadsheet directly in an OS X program, but that's a project for when I have absolutely nothing else to do. And I wish I was clever enough to somehow embed a link to DigiKey or Mouser's price for each part, so then the BOM cost would be more accurate.

If anyone wants a copy of the spreadsheet and the python script, hit me off-list.

-a