I hereby certify that I am not simply asking someone else to design a footprint for me.
This is an auto-generated message that is in place on the “footprints” section of the KiCad.info forum. If I remove it and ask for a footprint to be designed anyway, I understand that I will be subject to forum members telling me to go design my own footprint or referring me to a 3rd party footprint site.
Hello everyone,
Is there any way to add the datasheet link to a footprint in the library rather than the schematic symbol. Consider the generic push button symbol, When i assign a footprint to it I would like to add the datasheet link automatically so that it appears in the BOM.
There is no dedicated field for adding a datasheet link into footprint properties. You could add it to another field like “Description”. However I don’t think that would help you with the BOM as it is managed and generated from the circuit side (eeschema). If you’d reconsider adding datasheet links to symbols you’d be able to generate a BOM which would show you the links for each part in your BOM.
I had a peek at a footprint n the footprint editor, and it looks like you can add custom fields. But even if you do this, then Eeschema would probably not know what to do with it.
As a workaround, the simplest option is probably to make a library with fully customized symbols for Eeschema. Give each button a post-fix with the button type, and then add both datasheet link and footprint link in the normal way.
This request makes very little (or rather no) sense. Datasheets are supplied by device manufacturers and relate to a specific device. The footprint is just one little part of the datasheet.
The correct design flow (if you understand engineering) is design partitioning (= hierachical sheets or single sheet), schematic creation (using the libraries with datasheets), netlist creation and PCB layout.
That someone wants to skip the first steps and go directly to PCB layout is fine, but has nothing to do with datasheet management. It’s just not viable.
And there are other issues with KiCAD that are more important.
But the footprint is described in the datasheet, and there may be a datasheet for the footprint only (for a certain package). It would make sense to have a reference readily available from the footprint.
I think you misinterpreted the original message. It said
so there was a schematic. But maybe the original poster doesn’t know about possible workflows:
It’s possible to create a BOM from pcbnew. But that’s meant only for a very simple BOM which can’t be customized. For a more complex BOM functionality eeschema must be used.
Yes. But every supplier has an own footprint drawing.
Take any SOIC-16 part, and you’ll find that every supplier has an own footprint drawing. We’re talking 100s here Then try to integrate this into PCB layout “datasheets”.
PCB layout is about, well, layout… physical. It has absolutely nothing to do wtih supplier datasheets.
One workflow doesn’t always apply to all domains and companies, there are always different technologies and people involved.
In one company I worked for, our layout engineers always went and grab the part of the datasheet with the package information and added the document to our database.
This does 2 things:
our database was independent from manufacturers server changes (document was stored on our server)
the footprint specification is directly linked to the component, another component from another manufacturer will have a different footprint specification attached to it.
So in fairness with the OP’s question, this is a totally valid concern. Maybe not for you and your workflow.
I understand and accept your reply, but there are several issues that need to be adressed. And they’re not easy.
First, I’ve worked in the semiconductor industry for decades now, and your view on this has… let’s say: difficulties.
The first point is device packaging: this is normally not done by the semiconductor manufacturer, but at outside subcontractors. Changes in dimensions, materials, lead plating etc. are not immediately reflected in the datasheets. Extracting the dimensions page from a datasheet and placing it in the PCB layout file is dangerous.
The second point is, that a component may have multiple suppliers (eg, 74xx parts), each having their own packaging subcontractor and diverging package drawings/material composistion/lead plating etc.
I see this as an umanageable feature not to be pursued further.
A much more severe issue are the datasheet links in Eeschema, where so many are broken (due to supplier web page changes) that no one uses them any more, but look for the devices directly at the supplier web sites. A solution to this is IMHO more important. Where I work, an automatic link check runs overnight to check for broken links, but correcting those requires manpower. Not easy.
Thanks for “accepting” my reply but I wasn’t really trying to depict an “ideal” implementation, just one that our layout engineers stood for. Which is to say: it is not such a bad idea to have a dedicated footprint “datasheet” field as part of the footprint properties.
The consequences of this implementation wouldn’t be so terrible, adding a field only translates into adding a bit more text to the kicad_mod file, maybe a URL validation, that is all
There is definitely a huge step between a custom user field (like @paulvdh mentioned) and hard-coded field, the former can be managed easily, the later clearly needing attention from the KiCad dev team.
My concern is not about adding a field in PCB layout libraries. I’m sure this is pretty easy.
The big question is: who’s going to maintain it?
Already the Eeschema datasheet fields are not being maintained for content.
Have you even discussed this with the library maintainers?
If you read the original post carefully you see that’s not relevant.
The problem of maintaining is the same, big or small, whether it’s in the symbol or in the footprint.
I also don’t understand what you said:
That’s strange, because I have used datasheets to design footprints. I just don’t know where else I can find the relevant information. It’s either one datasheet or another. There just must be some document which is reliable enough. Otherwise PCB design would be impossible. In your insider position you have seen problems which don’t seem to be problems for the majority of EDA users. They just use datasheets.
Let’s leave it that. We see this differently.
My priority as user is more a wish for getting existing features to work properly, instead of adding new features all the time.
But we come from two different perspectives there.
Again, we’re looking at this from opposed perspectives.
I’m with you 100% that a designer has the full responsibility to document and attach all relevant documentation to her/his project. No exceptions. This is also my design philosophy. And I’m legally obliged to document my design decisions (You know, liability)
So:
1: the datasheet links in the Eeschema default library (and this is what people use!) are either good, useless, broken links or out of date. No engineer in her/his right mind would rely on these. So why provide them? Delete that field.
2: extending this to footprint “datasheets”. Even worse. Why add another component to something that’s inherently broken? The footprints are fine as they are, they’ve been generated by people with experience and knowledge about this, and I’m sure they’ve studied the datasheets already.
Investing some time in getting library management right instead of chasing new features all the time would be more productive.
Oh I see, you’re talking about the default library. I’m not using it personally so had no idea about the broken links.
“Delete” is a little harsh, what about users’ custom libraries where the link is all nice and working? I think you mean making the field “blank” in the default library.
Same thing for the footprint properties, what’s wrong with the existence of a blank datasheet field that can leveraged by many users?
Perfect. @eeintech, you understand me 100% now. Bingo!
I don’t care whether there’s a ‘datasheet’ field in the libraries. Make any field you want. (it won’t make KiCad easier to use, but who cares?). Leaving it blank is a good start.
But the default libraries are a mess.
I maintain my own libraries for that reason.
And all this because of a new user with 1 post. Jeez!
