I downloaded the KiCAD r5989 (win) from http://www2.futureware.at/~nickoe/ address .
but I could not find cvpcb draw diagrams in the new version. Will there cvpcb the new version?
Cvpcb has been removed as a standalone exe, it is currently only possible to open it from eeschema when in a project context. That is practically, when you open eeschema from the main kicad app.
Why did they do this. Do you have any idea ?
I would like to know that too. Integrate CvPCB launch from the schematic editor: I can understand why that functionality was added, but not why we lost the ability to launch it stand alone. It is still logically a separate application with its own data file.
Thereâs a couple of reasons:
- The plan is to have a per-component list of predefined footprints in the schematic libraries, avoiding a dedicated footprint assignment step by letting the user pick the footprint (either predefined or custom) while placing the component in SCH.
- The way CvPCB was storing footprint assignments (in a separate .cmp file) was making SCH->PCB annotation complicated - you had to export the netlist from the schematic, switch to PCBnew, import the netlist and the .cmp file. We would like to simplify this process and have at some point a single-click SCH->PCB update feature.
CvPCB will not disappear as such, itâs just integrated in the schematic editor for those who prefer the old-fashioned schematic->footprint assignment->PCB workflow.
Tom
No it isnât, not anymore. It is an accessory to eeschema now, and feeds the selections back to eeschema in the componentsâ Footprint fields.
Please see:
https://lists.launchpad.net/kicad-developers/msg19426.html
https://lists.launchpad.net/kicad-developers/msg19429.html
I donât display footprint fields in the schema editor - it adds too much clutter. As far as I can see the CvPCB module has just been linked to the schematic editor, but is still a separate module with its own I/O.
And to the devs: please do not merge footprints and schematic components. The fact that I have complete freedom to choose the footprint for any component is a main reason why KiCad is better than the competition. If I wanted to do it the way Eagle does it, Iâd be using Eagle.
I have 5 schematic diffrent folder in main folder . If i use eeschem main application. It is open only one sch. that same name to project. I cant open other schm. Therefore i must have diffrent project for each sch. So my opinion this way is wrong.
Nobodyâs going to merge fooprints and components. Youâll still be able to assign them the way you want. All we want to have is a per-component list of footprints that can be assigned in the library by the creator of the component. If you donât want to use it, you are not forced to.
The idea is that components already have âfieldsâ that are used to store information like which footprint is used, and the schematic editor is the place where fields are viewed and edited. Every other sane EDA package is the same way. The schematic editor is the one place that collects non-layout information about the project.
I find it quite tiresome when people use as an argument such as âevery other sane EDA package is the same wayâ. I will ignore the emotive term âsaneâ and just say that the Eagle UI is one of the biggest dog turds around. If the objective of KiCad would be to copy what Eagle does, then I see no reason for KiCad to exist.
The Eagle suite does not have a good UI. It has no consistency, which makes it difficult to learn. And the metaphors it uses are not the best simply because it is long established. IMHO KiCad gives us an opportunity to do something quite different, and attract a new generation of users who donât care about aping what Eagle or Protel did.
In short, I donât care what other EDA packages do.
On the same note: âthe schematic editor is the place where fields are viewed and editedâ is an expression of dogma, not an argument.
Returning to the conflation of schematic parts and footprints: there is no justification for merging the two, in fact doing do ISTM defeats the purpose, like trying to impose geographical knowledge on the London Tube map. The map is a success because it expresses logical connections in a simple way, in part by ignoring geographical complications. For the same reason we shouldnât be contaminating the schematic with footprint selections. Iâm not sure the schematic editor should be involved in footprint selection at all. ITSM if anything that should be the job of PCBnew.
1 Like
Trust me, I have too little experience with Eagle to want to copy it, and in no case would refer to it as âsaneâ anyway. But consistency can be a very good thing, and doing what other packages do can make it much easier for new users to learn a package.
Kicad does not force you to choose the footprints on the schematic. Itâs an option.
In my experience having 1:1 schematic component-footprint link in the library is essential for big projects, with a lifetime of 10+ years or large volume. Associating footprints freely is just too error-prone for professional PCB design, where even a small incompatibility in a footprint (example: how many different shapes of thermal pads for SO-8 are there?) can screw up volume production.
Some people actually do this. I think theyâre crazy, though.
Thanks for the explanation guys. This change makes sense to me now.
How can you be sure that the alternative is unmanagable if you refuse to even consider it?
I would also take issue with the practicality. I donât see how it is even possible to have a library with a 1:1 association between components and footprints. If you have M components each of which have an average N footprints then that means someone has to create M*N library entries, and debug them all too. It would lead to massive frustration with the library having a zillion variations on a theme, none of them quite doing what you want, and many of them having minor errors. I donât see why we need 50 million 8 pin SOIC footprints, I should only need one (ok, may more than one for slight pad variants, but anyway a small number - and the important point is that I look for it in a package library not a component library).
Also, a monolithic component entry would be hugely intimidating to create, both for suppliers and for hobbyists who want to add a component which doesnât already exist.
Well, IMHO thatâs what we had when CvPCB was a separate application. We had a second, explicit and vital step in which I went through all of the âvirtualâ components and decided on their real world instantiation: supplier, package type etc. There is your bill of materials.
The schematic on the other hand does NOT intuitively function as a BOM. What happens if a supplier goes out of business and the replacement has a slightly different footprint? Simple: I would dip into CvPCB, tweak one of the component instantiations, and then feed that change forward into the PCB. I can see no reason why the change would affect the schematic at all, hence I donât see why anyone would intuitively expect this function to be part of the schematic editor. The whole point of a schematic is that it represents the idea of the design: other tools turn the design into a real world expression.
1 Like
You donât seem to understand what I meant.
There are schematic symbol libraries and footprint libraries, and they are separate entities. Currently you have to run CvPCB (or its internalized version) to pick a footprint for each component. What we would like to have is a list of pointers, binding each schematic symbol with one or more (in case of resistors/capacitors) footprints. The footprint itself is not stored along with the schematic symbol, itâs just a reference. For instance, you can have:
LM324D
74HCT00D
74HCT04D
all pointing to âSMD_Packages:SOIC-14â footprint. Thereâs only one footprint entity, but linked from 3 schematic components. Since the linking information is stored in the schematic library, whenever you place an LM324D on the schematic, it automatically contains the reference to a matching footprint.
Of course you will be able edit the footprint associations âthe old wayâ using CvPCB.
Tom
Okay, so the separation of schematic symbols and layout footprints/modules is preserved⌠great! I like that. However, I miss CVPCBâs easy list format of all footprints. Is there a way without CVPCB to show both the assigned schematic symbol and the layout footprint/module in one easy-to-read list?
Cheers!