EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => KiCad => Topic started by: firewalker on November 30, 2015, 05:53:47 am
-
Wayne Stambaugh:
I just finished rolling out KiCad 4.0.0. Many thanks to everyone who
made this possible. Each and every one of you deserve to sit back and
enjoy this accomplishment. I have a few minor requests before I make a
trip to my refrigerator to grab a cold one to celebrate.
Someone please add an announcement the to blog page on the KiCad website?
The footprint, symbol and 3D model library, documentation, and
translation repos need to be tagged 4.0.0 so future package builds can
pull the proper version. At some point in the future we may need to
create 4.0.0 branches of the library, documentation, and translation
repos but for now the tags should suffice. Please do not make any
commits to these repos until after they are tagged.
What do we need to do as far as creating automated builds for the
correct version of the documentation? I know packagers on some
platforms will need pre-built documentation for the 4.0 release. This
shouldn't be a significant issue until we start documenting new features
during the next development cycle.
Please do not swamp me with patches and new feature merge requests over
the next few days. I have some of my own coding that I need to get done
for the next development cycle so I'm not going to have a lot of time to
do code reviews and I would like to reduce the number hours a week I've
been spending working on KiCad for a few weeks.
Thanks again everyone!
Cheers,
Wayne
-
So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?
Profoundly dysfunctional development.
-
No, it's structured. Each "department" does its things.
-
So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?
Profoundly dysfunctional development.
Come on.
-
It may be 'out' but it's not actually 'out'. The download still pages still give you 4.0.0 RC2, while the documentation date back to April. Who knows when they will actually finish releasing it?
-
It may be 'out' but it's not actually 'out'. The download still pages still give you 4.0.0 RC2, while the documentation date back to April. Who knows when they will actually finish releasing it?
I guess it's called a release when the final commits and tags are made to the git repo.
Compiling and packaging binaries for different platforms is another process. For unix variants (e.g. Ubuntu) this can be more or less easily automated and the binaries should be out real soon I think. Windows binaries are not so straightforward I suspect and the solution is to just stop using Windows :-DD
-
There are Windows binaries practically on a daily basis.
-
So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?
Profoundly dysfunctional development.
Why should one person handle it all? Wayne is the lead developer and the project head. He delegates documentation and "PR" to other people. If you think that is "profoundly dysfunctional" your head is profoundly far up your ass.
-
So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?
Profoundly dysfunctional development.
Why should one person handle it all? Wayne is the lead developer and the project head. He delegates documentation and "PR" to other people. If you think that is "profoundly dysfunctional" your head is profoundly far up your ass.
It's not coordinated very well though, now is it?
It explains a lot about how the tool works, though.
*shrug*
Give 'em another couple years..
-
There seems to be a 4.0.0 build in the js-reynaud/kicad-4 ppa (https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-4) now :-+
-
The only thing released so far is the announcement of the release - they haven't published any release binaries.
This is typically Kicad - users are an afterthought!
-
The only thing released so far is the announcement of the release - they haven't published any release binaries.
This is typically Kicad - users are an afterthought!
If you read the post previous to yours you will see they that they have released the source code.
So your statement is just bullshit.
Please acknowledge your error, and in future try criticise what you don't like more fairly.
-
Well this will be interesting.
I figure it is time to get off my backside and learn one of these programs.
Might as well start with Kicad...
-
The only thing released so far is the announcement of the release - they haven't published any release binaries.
This is typically Kicad - users are an afterthought!
Yay, Kicad is mentioned and the Kicad bashing brigade is on it in full force again ... Guys, you don't have anything better to do with your time? If you don't like it, why are you wasting your time with it?
I have downloaded the source and built it yesterday evening, compiles and works just fine :-+
Just be prepared to "forward port" older projects because there were some changes in the libraries.
-
Last time I tried Kicad I completed the schematic, switched to the layout editor and got an empty screen. This is where I went back to Eagle. Is this still the case? I would like eventually to switch to Kicad.
-
Well, it's certainly not a known problem at the time, but I can't rule out weird graphics issues that nobody else has seen. Graphics stuff is annoying like that.. I'd suggest giving it a try, at least (and if it doesn't work, and you're feeling generous, perhaps sharing some info on your graphics configuration? ;))
-
So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?
Profoundly dysfunctional development.
[pedantic mode on]well it's open source. if you don't like it : fork it, try to compile it . you got the source ....[/pedantic]
-
Well, it's certainly not a known problem at the time, but I can't rule out weird graphics issues that nobody else has seen. Graphics stuff is annoying like that.. I'd suggest giving it a try, at least (and if it doesn't work, and you're feeling generous, perhaps sharing some info on your graphics configuration? ;))
It was not a graphic issue, just an empty editor with no components and air wires. I remember somebody mentioning that a two way sync between schematic and board, similar to eagle, is in the plans. When I tried it, the schematic editor and layout editor seem to be disconnected from each other.
Edit: found it here https://www.eevblog.com/forum/open-source-kicad-geda/kicad-gripes-list-post-gripes-here/?nowap (https://www.eevblog.com/forum/open-source-kicad-geda/kicad-gripes-list-post-gripes-here/?nowap)
So what I mean is: is the two-step export-netlist/import-netlist mechanism in Kicad really that awful? That said, I think it's on the roadmap to make it the one-step process after the upcoming stable is released.
-
Did you loaded the netlist file produced be the schematic editor?
Alexander.
-
Ah, yes. Schematic and PCB still behave as separate applications (for hysterical raisins). Click the netlist button on the toolbar in schematic to export data, then click the netlist button on the toolbar in PCB to import it. It's a bit clunky, I'll admit - I'm not sure of the extent of any plans to change that. Tom (one of the CERN dudes) had a patch to fix that up a bit, a few months ago. It was never merged, I suspect because it was too large and risky to merge before the release and risk introducing bugs. Perhaps he'll bring it up again now that the release is out.
-
i like raisins ^-^ not sure about historical, or hysterical, ones though
-
I suspect because it was too large and risky to merge before the release and risk introducing bugs. Perhaps he'll bring it up again now that the release is out.
Thanks. Streamlining the user experience end to end is very important, even before introducing advanced features.
-
I kinda like the separate process. :D :D :D
Alexander.
-
They aren't even separate anymore, though. That went away with the _last_ release - they sit in the same process now, so they can easily pass each other data. They just... don't.
Those raisins sure are hysterical.
-
Last time I tried Kicad I completed the schematic, switched to the layout editor and got an empty screen. This is where I went back to Eagle. Is this still the case? I would like eventually to switch to Kicad.
You need to assign footprints, then generate a netlist. The netlist is imported into the layout editor.
This may seem cumbersome, but it's actually quite nice because it makes it easy to have multiple layouts for the same schematic in one project.
-
This may seem cumbersome, but it's actually quite nice because it makes it easy to have multiple layouts for the same schematic in one project.
Not anymore.
-
You need to assign footprints, then generate a netlist. The netlist is imported into the layout editor.
This may seem cumbersome, but it's actually quite nice because it makes it easy to have multiple layouts for the same schematic in one project.
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
Whereas to be honest, that was what did annoy me about Eagles when I chose a component, I had to decide on the footprint, so for example I place an electrolytic capacitor in a schematic, now I have to stop and look up what size, and dimensions the capacitor I want to use is, check my calculations to cover voltage etc.
-
If you look in the download folder under stable, there is one that says "almost there" 4.0.0, this binary was released recently, I suspect it isn't fully packaged yet, just tested and committed as the "final" release.
The PCB editor will show a blank screen if you don't import the netlist, this part is not as seamless as EAGLE, and i'm sure this will be addressed in future releases as the components become more integrated and share data, for now, a few extra clicks of the mouse doesn't really make much difference (to me anyway)
Certainly cannot complain for the price!
-
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
This is a very error prone and cumbersome workflow. The CAD package I'm using has a database which connects a symbol, footprint, part numbers, etc together. Creating a new part in the database is a one time job. When I draw a schematic I pick components from that database so I know the footprint is right, the part numbers are right. Generating a bill of materials is just a matter of one click. It would be really nice if Kicad (eventually) has something similar.
-
They aren't even separate anymore, though. That went away with the _last_ release - they sit in the same process now, so they can easily pass each other data. They just... don't.
A was referring to the process the user must take. Not the computing term. ;D ;D ;D
Alexander.
-
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
This is a very error prone and cumbersome workflow. The CAD package I'm using has a database which connects a symbol, footprint, part numbers, etc together. Creating a new part in the database is a one time job. When I draw a schematic I pick components from that database so I know the footprint is right, the part numbers are right. Generating a bill of materials is just a matter of one click. It would be really nice if Kicad (eventually) has something similar.
Everybody I have ever seen has been sufficiently pessimistic to have a different database/library for each design, and to copy everything relevant into that "design local" database. Makes it easier to archive and hand over the design, and avoids the problems of subsequent changes to a component affecting previous designs.
None of that is specific to any schematic/layout tool, of course.
-
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
This is a very error prone and cumbersome workflow. The CAD package I'm using has a database which connects a symbol, footprint, part numbers, etc together. Creating a new part in the database is a one time job. When I draw a schematic I pick components from that database so I know the footprint is right, the part numbers are right.
Kicad for quite a long time has allowed you to embed a footprint reference into your schematic library symbols. No need for the error-prone CvPCB process. All of the symbols in my schematic libraries have footprints set in this manner.
Yes, the schematic libraries are separate from the footprint libraries. While the devs could possibly cook up something like Altium's integrated libraries, I am not sure that there's a benefit to doing so.
Generating a bill of materials is just a matter of one click. It would be really nice if Kicad (eventually) has something similar.
Kicad does let you generate a BOM with one click. OK, two clicks. You end up with a CSV file, which you can import into whatever you like.
-
Last time I tried Kicad I completed the schematic, switched to the layout editor and got an empty screen. This is where I went back to Eagle. Is this still the case? I would like eventually to switch to Kicad.
You need to export the netlist from the schematic, and then import it into the PCB editor.
-
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
This is a very error prone and cumbersome workflow. The CAD package I'm using has a database which connects a symbol, footprint, part numbers, etc together. Creating a new part in the database is a one time job. When I draw a schematic I pick components from that database so I know the footprint is right, the part numbers are right. Generating a bill of materials is just a matter of one click. It would be really nice if Kicad (eventually) has something similar.
Everybody I have ever seen has been sufficiently pessimistic to have a different database/library for each design, and to copy everything relevant into that "design local" database. Makes it easier to archive and hand over the design, and avoids the problems of subsequent changes to a component affecting previous designs.
You don't quite understand how it works. Search for how Orcad Capture CIS works and you'll see this workflow makes a lot of sense. Orcad allows to select which fields (part numbers, manufacturer, etc) are copied into the schematic from the database (which in my case is an MS Access database) so it can be handed over without needing the component database.
I have written it before but I will repeat myself: many low end CAD systems don't seem to understand that a component consists of a symbol, footprint and several other fields (properties if you like). You can't get away with just linking a footprint to a symbol because that just doesn't make it a component! For me it is necessary to have a database which has the components which then can be selected by the schematic package. No way I am going back to putting BOMs together manually or discover I choose the wrong footprint for a component I might have used many times before.
BTW: I don't mind having to create a netlist first and then read it into the PCB package. The ancient Orcad package I'm using works that way as well.
-
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
This is a very error prone and cumbersome workflow. The CAD package I'm using has a database which connects a symbol, footprint, part numbers, etc together. Creating a new part in the database is a one time job. When I draw a schematic I pick components from that database so I know the footprint is right, the part numbers are right. Generating a bill of materials is just a matter of one click. It would be really nice if Kicad (eventually) has something similar.
I disagree, I find the create the component once work flow cumbersome and unwieldy, so there you are deciding what component you will use, and then you also have to finalise power rating, package etc?
so you guess you need a 1/4 Watt resistor, sketch up the schematic, do the sums and then decide a 5W fits the bill?
or you have to decide on one package, then get to thinking about PCB layout and decide another package would work better?
I far prefer the work flow of:
1) work out schematic, get the circuit right
2) workout layout and component size
3) design PCB
- and besides Kicad does do a BOM, pretty well in one click, once you have designed the circuit.
i find I get more errors and end up stuffing about way more, If I have to decide on component and footprint at the schematic stage, so I do have to strongly disagree, the Eagles work flow is far more prone to errors, and way cumbersome than doing the design in a more logical order.
-
Kicad for quite a long time has allowed you to embed a footprint reference into your schematic library symbols. No need for the error-prone CvPCB process. All of the symbols in my schematic libraries have footprints set in this manner.
Yes, the schematic libraries are separate from the footprint libraries. While the devs could possibly cook up something like Altium's integrated libraries, I am not sure that there's a benefit to doing so.
No don't do it - the schematic, then PCB design work flow works much better for me, and makes much more logical sense.
-
I disagree, I find the create the component once work flow cumbersome and unwieldy, so there you are deciding what component you will use, and then you also have to finalise power rating, package etc?
so you guess you need a 1/4 Watt resistor, sketch up the schematic, do the sums and then decide a 5W fits the bill?
I would imagine that most experienced engineers know the power requirements for resistors by the time they start capturing the schematic. I'll do a sketch in the notebook and work all of that out, before I even open the CAD package.
Same thing with op-amps. Same thing with voltage regulators. You pretty much know what you're going to use before you start the schematic-drawing program.
or you have to decide on one package, then get to thinking about PCB layout and decide another package would work better?
Well, that happens. Say there's a mechanical constraint that requires a different-size connector, or maybe the purchasing people tell you that you can get a part in package A a lot easier than package B.
But here's the thing: LM317 in a TO-220 has a different manufacturer part number from LM317 in SOT-223. So, thinking about how you'd change from the TO-220 to the SOT-223, isn't it easier to have both LM317T and LM317EMP in your library? Each component in the library knows the correct footprint AND has a part number that the purchasing people can use to buy the correct parts. Changing from one to the other, at the design level, is a simple matter of deleting the LM317T from the schematic and replacing it with LM317EMP.
Then you regenerate the netlist (in Altium, you recompile the design and then update the board, in Kicad, like the old Accel, you generate a new netlist and import it into the PCB). You then generate the BOM from the schematic. No hand-fiddling is necessary, and stupid mistakes are eliminated (parts in the library are vetted, right?).
i find I get more errors and end up stuffing about way more, If I have to decide on component and footprint at the schematic stage, so I do have to strongly disagree
How can you get "more errors" if you place components on a schematic, instead of symbols which have no part number or footprint information?
I honestly don't understand.
-
There are clearly two schools of thought regarding component workflow, and I would respect the fact different engineers have different preferences. Ideally, the user should be able to choose the workflow they prefer.
Kicad could support both I think, if there were "generic" libraries with unspecified footprints, and fully associated libraries.
-
KiCad definitely supports both workflows - I use Bassman59's workflow. I just didn't comment on that because I know it always turns into a flamewar >:D
-
KiCad definitely supports both workflows - I use Bassman59's workflow. I just didn't comment on that because I know it always turns into a flamewar >:D
Probably a wise decision. Judging by this post of bassman59
https://www.eevblog.com/forum/microcontrollers/beginner-fpga-dev-board/msg811642/#msg811642 (https://www.eevblog.com/forum/microcontrollers/beginner-fpga-dev-board/msg811642/#msg811642)
he does appear to have a tendency of knowing The Single True WayTM of doing things.
-
a component consists of a symbol, footprint and several other fields (properties if you like).
Actually, in many cases there's multiple footprints. Not only this, but the different footprints (e.g. soic vs ssop) have different pinouts and pin counts. While you can pick one up front during the capture ideally you want to wait to the layout phase to determine which package makes most sense. At least where you don't have a hard need or requirement for one or the other.
-
usability of ~2005 Gimp, whats not to like?
-
I actually prefer this work flow, where I can focus on getting the circuit designed first, then work out the details required to decide on the footprints, such as power ratings of components, voltage ratings for capacitors etc etc.
This is a very error prone and cumbersome workflow. The CAD package I'm using has a database which connects a symbol, footprint, part numbers, etc together. Creating a new part in the database is a one time job. When I draw a schematic I pick components from that database so I know the footprint is right, the part numbers are right. Generating a bill of materials is just a matter of one click. It would be really nice if Kicad (eventually) has something similar.
I disagree, I find the create the component once work flow cumbersome and unwieldy, so there you are deciding what component you will use, and then you also have to finalise power rating, package etc?
so you guess you need a 1/4 Watt resistor, sketch up the schematic, do the sums and then decide a 5W fits the bill?
I click 'link database part' in Orcad and all the information for the part gets changed immediately without needing to remember I decided to use a 5W resistor instead of 1/4W. Circuits quickly consist of 100s of components so you can't just remember every one of them. Recently I cleaned a schematic in which there where several different voltage rating 1uf capacitors in 0603 size. Orcad has a part manager which lists all the components so changing many of them in one go is just a matter of selecting them and picking another part (in this case a 1uf with a higher voltage rating) from the database. Automating component management really makes life easier and results in less errors. Errors in components can lead a lot of time lost. A couple of years ago I was involved in a project where someone else designed the hardware. He used a manual design flow like you described. The design was for a battery powered device with a couple of hundred SMT components on the board. It turned out the device kept drawing 30mA in standby which was much more than was calculated. I think he spend at least a week trying to find the cause and it turned out he made a mistake in the BOM.
Besides that I find it odd to start entering a schematic into a CAD package before knowing which components are required. For a project I'm currently working on I already have a dummy PCB layout to try and fit the large components but no schematic at all. I do this a lot for space constraint designs: get a PCB mockup first and then work out the (final) circuitry.
-
KiCad definitely supports both workflows - I use Bassman59's workflow. I just didn't comment on that because I know it always turns into a flamewar >:D
Probably a wise decision. Judging by this post of bassman59
https://www.eevblog.com/forum/microcontrollers/beginner-fpga-dev-board/msg811642/#msg811642 (https://www.eevblog.com/forum/microcontrollers/beginner-fpga-dev-board/msg811642/#msg811642)
he does appear to have a tendency of knowing The Single True WayTM of doing things.
Just the Single True Way of doing things that seem to used at most employers with thought-through workflows.
And yeah, two-process state machines suck balls.
-
a component consists of a symbol, footprint and several other fields (properties if you like).
Actually, in many cases there's multiple footprints. Not only this, but the different footprints (e.g. soic vs ssop) have different pinouts and pin counts. While you can pick one up front during the capture ideally you want to wait to the layout phase to determine which package makes most sense. At least where you don't have a hard need or requirement for one or the other.
Right, often you'll wait until layout phase to decide which footprint makes the most sense, and maybe your purchasing person says that one package is readily available and the other is not.
But the point we're making is that it's not difficult to have both LM317T and LM317EMP in the library, and it is dead simple to delete the LM317EMP from the schematic and place the LM317T in its place. And then the component will have the part number for the BOM so purchasing can buy the right part and the kit people can pull the right parts from the bin.
If you just place generic LM317 on the schematic, then at layout time you have to choose the footprint AND go and make sure that you update the BOM so you buy the right parts. The "wait until the last minute" method is error prone.
-
Bassman59 says, "There is One True Way".
Bassman59 exemplifies the "God" approach to quality.
"There is one person in the company who is Never Wrong. So if we all do what He says, there shall be perfect quality. By the way, that person is me. Kneel before me, inferior beings!".
In the real world, there are alternative workflows and quality processes that are equally effective. You know, just in case God/Bassman59 is not one of the employees.
-
But here's the thing: LM317 in a TO-220 has a different manufacturer part number from LM317 in SOT-223. So, thinking about how you'd change from the TO-220 to the SOT-223, isn't it easier to have both LM317T and LM317EMP in your library? Each component in the library knows the correct footprint AND has a part number that the purchasing people can use to buy the correct parts. Changing from one to the other, at the design level, is a simple matter of deleting the LM317T from the schematic and replacing it with LM317EMP.
Here's a better, yet still trivial example. There are far more complex chips that have multiple packages with different pinouts.
(http://www.rockgarden.net/download/pinouts.png)
On the soic, the inputs are at the top and the outputs at the bottom. On the ssop the outputs are on the right, inputs on the left and there are four nc's. (Or, I should say uC-facing vs external-facing.) You really want the freedom to pick one or the other during layout, because you won't know until then if there's any benefit to using the soic over the ssop. Without context switching to the schematic. No tool handles this adequately, but KiCAD and its manual netlist management at least permits multiple exploratory layouts: I can run two copies of pcbnew on Linux side by side, making two exploratory layouts in parallel, for the same schematic. And it's not just pinouts, I can experimentally design for 2 and 4 layer and then see if the benefit of the latter outweighs the cost, or conversely use it to prove my assumptions. All I need to do is generate appropriately named netlists or subdirectories for the different variants, and go to town. In the documentation I then do a writeup of the different variants and why one was chosen over the other (more quantitatively, as in halving the number of vias, or made a 2-layer board possible within the dimensional constraints).
-
downloaded last kicad for os x today.
start a new pcb
program unexpectingly quit ...
so far I'm not using it further !
-
You really want the freedom to pick one or the other during layout, because you won't know until then if there's any benefit to using the soic over the ssop. Without context switching to the schematic. No tool handles this adequately, but KiCAD and its manual netlist management at least permits multiple exploratory layouts: I can run two copies of pcbnew on Linux side by side, making two exploratory layouts in parallel,
But apparently (at least as far as I can tell from the comments in this thread) everyone else decides on the final board layout, BOM, and component choice, before they even design the circuit :-//
-
You really want the freedom to pick one or the other during layout, because you won't know until then if there's any benefit to using the soic over the ssop. Without context switching to the schematic. No tool handles this adequately, but KiCAD and its manual netlist management at least permits multiple exploratory layouts: I can run two copies of pcbnew on Linux side by side, making two exploratory layouts in parallel,
But apparently (at least as far as I can tell from the comments in this thread) everyone else decides on the final board layout, BOM, and component choice, before they even design the circuit :-//
No, 'we' do that before entering the schematic into the CAD package. Going all the way from a schematic to a PCB layout only to find out the circuit doesn't fit or benefits from using different parts is just a waste of time. In my projects I often have a rough PCB layout before starting the schematic. This way I can optimise the schematic for the PCB layout from the very start and not as an afterthought. Sometimes limited PCB space drives other features of a design as well so it is important to start with the size constraints for the PCB layout and go from there.
-
In the real world, there are alternative workflows and quality processes that are equally effective. You know, just in case God/Bassman59 is not one of the employees.
Yes, there are alternative workflows. There are some workflows where you do some work once, up front, and reuse that work across many designs. And there are some workflows where the Very Smart Engineers who post on internet forums like to re-invent the wheel for every design. I suppose they like to re-do the work again and again because they can either bill the client for that work, or they can appear to their bosses that they're very busy indeed.
-
Hey!
been reading this thread and have gotten the impression that this info will add value to the discussion.
Most of the stuff everyone has been asking for or was not happy with is planned to be implemented/fixed
here is a link detailing the efforts and commitments by CERN
http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages (http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages)
-
BTW... 4.0.1 is out (fixes an Os X crash).
I believe that only crash fixes will merge to the 4.x series.
Alexander.
-
And Spanish translation is about 75% now :)
-
Anyone like to talk about KiCAD?
I was thinking the same thing...
I need to get back on that microphone preamp I am designing using KiCad.
-
MODERATOR: I've gone and deleted and/or edited a bunch of off-topic mud slinging. Stick to the topic please.
-
Most of the stuff everyone has been asking for or was not happy with is planned to be implemented/fixed
here is a link detailing the efforts and commitments by CERN
http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages (http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages)
The CERN roadmap is a really positive move for Kicad, it needs that sort of direction. I'm not sure how far these are commitments from CERN, more of a wishlist. I am hoping Item 10, "Improve the UI" happens sooner rather than later. The #1 bugbear of Kicad is the awkward and inconsistent user interface.
4.0.x is really more of a 3.5 beta, there are several features which are half-finished - and create even more confusion for users (e.g. you need to be in the right canvas before certain features are enabled. Of course there is no hint to the user about that). The github libraries are causing a lot of confusion for many people, which could have been easily avoided.
I am still plugging away with 4.0.x, trying to get it configured correctly and a sample project migrated but it is slow going. To get things done I am still using the "old stable" BZR 4022.
-
yes UI must be improved ... no copy-paste thing in many places.
the zoom with the scrollwhell of the mouse is too fast and happening when you don't want to (at least in os x)
there are 2700 or so items in the library, that is way too small to find what you want
I'm not getting further in this version 4, I'll go back to diptrace for now.
-
there are 2700 or so items in the library, that is way too small to find what you want
I strongly recommend not judging any EDA package by its library. Since when can you trust them anyway? I've never seen an EDA package whose library wasn't terrible - yes, KiCad included, as well as Altium, Eagle, DipTrace...
If you can't find a part you need, make it. Making parts is part of the deal with any EDA.
-
there are 2700 or so items in the library, that is way too small to find what you want
I strongly recommend not judging any EDA package by its library. Since when can you trust them anyway? I've never seen an EDA package whose library wasn't terrible - yes, KiCad included, as well as Altium, Eagle, DipTrace...
If you can't find a part you need, make it. Making parts is part of the deal with any EDA.
Over 3 decades ago a potential client asked my company to provide a set of simulation models for TTL/LSTTL logic. Upon asking what their acceptance criteria was, they didn't have any and would automatically accept anything we delivered. Why? Because they had a sales deal hanging on the presence of those models, and it was a case of th famous rag-trade phrase "never mind the quality, feel the width". I declined to quote.
I've never got over the concept that many libraries are like that - unless you are paying significant money to a company dedicated to proving library parts.
-
I was hoping the kicad community was a rather large one.
2700 items is what I found online ready to install in kicad.
I hopped (too much may be) that a long ago installed community would have made many more items
and that you could find the essentials parts in it.
-
Standard libraries are highly overrated. With every CAD package I have used to far I have created my own. Standard footprints are nice and some symbols as well but in the 25 years of using CAD packages every single PCB needed at least 1 new symbol and or footprint. IOW: to get the most use out of a CAD package you have to learn how to make new symbols & footprints.
-
Standard libraries are highly overrated. With every CAD package I have used to far I have created my own. Standard footprints are nice and some symbols as well but in the 25 years of using CAD packages every single PCB needed at least 1 new symbol and or footprint. IOW: to get the most use out of a CAD package you have to learn how to make new symbols & footprints.
very well said :-+
-
What isn't overrated though is Dave Vandenbout's KiPart utility:
http://www.xess.com/blog/giving-back-to-the-community/ (http://www.xess.com/blog/giving-back-to-the-community/)
I've been raving about it before. It's a great script to add components to your library - certainly when the pin count is high and the pin description can be snooped from the pdf datasheet of your component.
Took a few minutes to copy the pin info for the TDC1000 from datasheet to a spreadsheet and generate a component.
-
It would be cool to have that kind of functionality into KiCad, by plug-in or itself.
I did read gEDA people even experimented with OCR and vectorizing to automate footprint creation. I don't have the link, but I can find it if there's some interest.
-
It would be cool to have that kind of functionality into KiCad, by plug-in or itself.
I did read gEDA people even experimented with OCR and vectorizing to automate footprint creation. I don't have the link, but I can find it if there's some interest.
You might be thinking of AutoBGA (https://code.google.com/p/autobga/). It looks pretty nifty.
-
It would be cool to have that kind of functionality into KiCad, by plug-in or itself.
I did read gEDA people even experimented with OCR and vectorizing to automate footprint creation. I don't have the link, but I can find it if there's some interest.
You might be thinking of AutoBGA (https://code.google.com/p/autobga/). It looks pretty nifty.
That's not what I did see, but it seems interesting too. Unfortunately, it seems not updated since 2011 (I checked GitHub mirrors, no forks).
I meant these utils...
http://wiki.geda-project.org/geda:tragesym_tutorial (http://wiki.geda-project.org/geda:tragesym_tutorial)
http://www.penguin.cz/~utx/pstoedit-pcb/ (http://www.penguin.cz/~utx/pstoedit-pcb/)
-
KiPart is nice, an excellent time saver! I particularly like that it can easily break the component up into blocks (power, bus, USB, analog, etc) according to schematic needs. It also permits labeling pins with the function they will actually perform in this particular application rather than all the various functions they could potentially be assigned but aren't.
-
what about merging KiPart into KiCad?
What about KiCad 5.0?
?
-
But here's the thing: LM317 in a TO-220 has a different manufacturer part number from LM317 in SOT-223. So, thinking about how you'd change from the TO-220 to the SOT-223, isn't it easier to have both LM317T and LM317EMP in your library? Each component in the library knows the correct footprint AND has a part number that the purchasing people can use to buy the correct parts. Changing from one to the other, at the design level, is a simple matter of deleting the LM317T from the schematic and replacing it with LM317EMP.
Here's a better, yet still trivial example. There are far more complex chips that have multiple packages with different pinouts.
(http://www.rockgarden.net/download/pinouts.png)
On the soic, the inputs are at the top and the outputs at the bottom. On the ssop the outputs are on the right, inputs on the left and there are four nc's. (Or, I should say uC-facing vs external-facing.) You really want the freedom to pick one or the other during layout, because you won't know until then if there's any benefit to using the soic over the ssop. Without context switching to the schematic. No tool handles this adequately, but KiCAD and its manual netlist management at least permits multiple exploratory layouts: I can run two copies of pcbnew on Linux side by side, making two exploratory layouts in parallel, for the same schematic. And it's not just pinouts, I can experimentally design for 2 and 4 layer and then see if the benefit of the latter outweighs the cost, or conversely use it to prove my assumptions. All I need to do is generate appropriately named netlists or subdirectories for the different variants, and go to town. In the documentation I then do a writeup of the different variants and why one was chosen over the other (more quantitatively, as in halving the number of vias, or made a 2-layer board possible within the dimensional constraints).
I am curious how is that possible? because if you're changing between SO16 and SSOP20 you will need to use 2 schematics right? I mean both IC's pin configurations are different.
To try different layouts for a schematic option, I just renamed the finished layout by the Save as option ( a project file .pro creates automatically in that new name)
did't got a clue to run multiple Pcbnew side by side, how did you do that? am using Win7.
-
That is one of the things I liked about
Eagle other packages, is that you can assign pins to pads separately, I think KiCAD automatically assigns pin1 of the symbol to pin1 on the footprint, not sure if they changed this on newer versions?
-
That is one of the things I liked about Eagle other packages, is that you can assign pins to pads separately, I think KiCAD automatically assigns pin1 of the symbol to pin1 on the footprint, not sure if they changed this on newer versions?
Not sure what you mean here ? - all PCB tools I have seen, communicate via netlists, and they have the general form of RefDes.PinID
That means the PinID and RefDes have to both agree/equate between the SCH and PCB sides.
PinID can be either Number, or Alpha like E.B.C, or A1..G9 on BGA
-
I mean KiCAD assigns symbol "pin 1" to footprint "pin 1". Other packages allow you to link symbol "pin1" to footprint "pin2", or if you have multiple footprints (say DIP and QFN), allows you to assign symbol "pin 1" to DIP footprint "pin 1" but symbol "pin 1" to QFN footprint "pin 2", without changing the names, so the associations change within the library not within the project.
-
IIRC Kicad does force a schematic part pin ID to a footprints ID.
But these don't necessarily have to be numbers.
eg. A Mosfet Part (component?) can have pins marked G, D, S. (instead of 1,2,3)
then the Footprints can have G, D, S too. As long as these match. Otherwise the pad doesn't get a net.
This is useful if you haven't decided whether to go SM or TH. as I think the pin numberings are different on FETs between these packages.
Obviously you cant match a component marked 1,2,3 with a footprint marked G,D,S.
Hope that makes sense.
-
It may be 'out' but it's not actually 'out'. The download still pages still give you 4.0.0 RC2, while the documentation date back to April. Who knows when they will actually finish releasing it?
I guess it's called a release when the final commits and tags are made to the git repo.
Compiling and packaging binaries for different platforms is another process. For unix variants (e.g. Ubuntu) this can be more or less easily automated and the binaries should be out real soon I think. Windows binaries are not so straightforward I suspect and the solution is to just stop using Windows :-DD
Stop using windows?
-
So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?
Profoundly dysfunctional development.
It's an open-source project. If there is an area that you think needs attention, why don't you roll up your sleeves, and join the project to "fix" the things that you think need to be fixed? I'm sure that they could use the help from an expert such as yourself.
Uh, right, that's totally how it works.
-
Uh, right, that's totally how it works.
That's exactly how it works. Unless you are willing to pay someone to do it, of course. Criticizing something but then expecting someone else to do the work so that you can benefit from it for free sounds somehow fair to you?
Pouring non-constructive dismissive scorn on a volunteer run project with zero budget because someone doesn't do things to your standards is making only you look bad, not the project, I am afraid. Why are you even bothering to comment on a project you don't like and don't use? Enjoying trolling much?
FYI, I have built the current Kicad yesterday here and it works just fine, thank you very much. Far cry from "dysfunctional development", IMO.
-
Uh, right, that's totally how it works.
That's exactly how it works. Unless you are willing to pay someone to do it, of course. Criticizing something but then expecting someone else to do the work so that you can benefit from it for free sounds somehow fair to you?
Let me just walk right in and take over. It works that way, totally.
And no, I'm not expecting anyone else to do anything for my benefit.
Pouring non-constructive dismissive scorn on a volunteer run project with zero budget because someone doesn't do things to your standards is making only you look bad, not the project, I am afraid. Why are you even bothering to comment on a project you don't like and don't use? Enjoying trolling much?
Pouring? That tiny little drop? I made an admittedly unnecessarily harsh comment out of surprise at how they handled a release. I will now pay for it for the rest of my life, because I am truly evil.
I actually have great hope for KiCAD, every other option has severely disappointed me with no sign of improvement. KiCAD might get somewhere. Last time I tried it, it wasn't there, but it was on the move at least.
-
I mean KiCAD assigns symbol "pin 1" to footprint "pin 1". Other packages allow you to link symbol "pin1" to footprint "pin2", or if you have multiple footprints (say DIP and QFN), allows you to assign symbol "pin 1" to DIP footprint "pin 1" but symbol "pin 1" to QFN footprint "pin 2", without changing the names, so the associations change within the library not within the project.
I think this is how things are done simply because it's how things are done historically. But in reality, the only mapping between pin function and pin number is in the footprint. There is no reason to propagate the pin number past this; there is no reason to have pin numbers on the schematic whatsoever. The schematic should be a logical/functional description, not a physical one. I should be connecting pin A0 to ground in the schematic, and it shouldn't matter one iota what pin it's on in the package as far as the schematic is concerned. The parts then should be grouped into functionally equivalent families. As an example, a "hex inverter" can be a family from which you pick a logic family and package to suit your needs. The logic family is picked in the schematic (because it has an immediate functional impact), the packaging in the layout (because it's a physical consideration). If the packaging matters functionally, then it's picked in schematic and the layout gets locked to that one. At least that's how I think it should work. IMO. Yours may differ.
-
I mean KiCAD assigns symbol "pin 1" to footprint "pin 1". Other packages allow you to link symbol "pin1" to footprint "pin2", or if you have multiple footprints (say DIP and QFN), allows you to assign symbol "pin 1" to DIP footprint "pin 1" but symbol "pin 1" to QFN footprint "pin 2", without changing the names, so the associations change within the library not within the project.
I think this is how things are done simply because it's how things are done historically. But in reality, the only mapping between pin function and pin number is in the footprint. There is no reason to propagate the pin number past this; there is no reason to have pin numbers on the schematic whatsoever. The schematic should be a logical/functional description, not a physical one. I should be connecting pin A0 to ground in the schematic, and it shouldn't matter one iota what pin it's on in the package as far as the schematic is concerned. The parts then should be grouped into functionally equivalent families.
You can debate this in lengths but for fault finding, debugging and repair it just is easier to represent a part like it is in the package. It makes it unnecessary to look at the outline of a package to figure out where a pin is. In many cases seeing where ground/power pins are make it easy to find a certain pin on large packages. In general this works best for packages with 2 rows of pins (like SOIC) or square packages (like TQFP).
-
I think it depends on the component, I find it extremely useful for example, when assembling a board to see which pin a particular function of a transistor is on, I can tell pin 1 from the package itself, but not necessarily which one is the "collector" unless I look up the datasheet, if the pin numbering is on the schematic, which I usually have in front of me, not the layout artwork, I can use it as a quick reference.
Works for me!