EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => KiCad => Topic started by: homebrew on July 06, 2014, 07:38:14 am
-
<RANT MODE ON>
I'm really pissed off by KiCAD under Linux!
Why on earth is it so much broken?
1) Default KiCAD under Ubuntu 14.04 completely broken
-> Known bug and probably Ubuntus fault (http://ubuntuforums.org/showthread.php?t=2221823&p=13012571#post13012571 (http://ubuntuforums.org/showthread.php?t=2221823&p=13012571#post13012571))
2) Ok, used the compile-by-script method from the download section of the KiCAD website. Two hours compile time!
3) No footprints available. Why? Because I was working offline! WTF? Ok, at least there is a session cache but ... AARRGH! Ok, handy eevblog-forum is a great help here and someone posted a python script to manually download all the git repositories for the components.
(https://www.eevblog.com/forum/open-source-kicad-geda/kicad-new-footprint-libraries-(-pretty)-packet/ (https://www.eevblog.com/forum/open-source-kicad-geda/kicad-new-footprint-libraries-(-pretty)-packet/))
4) I CANNOT PRINT A SINGLE SHEET OF MY SCHEMATIC!!! And that is a known bug in KiCAD for over two years!!!
(https://bugs.launchpad.net/kicad/+bug/1089027 (https://bugs.launchpad.net/kicad/+bug/1089027))
An I have not talked about using it under OSX. I gave that idea up very fast!
</RANT MODE OFF>
But as usual under M$-Windows everything works like a treat:
A nice installer, done in some minutes.
Components, all there, including footprints.
And I can print! Woohoo!
But I don't want to use Windows anymore !!!!!!!!!!!
To my perception this is a very bad attitude for a development team that does open-source-software. It shouldn't be such a pain in the ass to use it under a free operating system!
-
hhm, I'm using it with debian wheezy and tried version installed out of the wheezy repository and some of the ready build packages.
But I never felt the need of printing, so I'm biased.
I'm really wonder what is running under w$ as usual.
You mean the shitty excel or the bloody shitty outlook? This is my daily annoyance.
You are right this is bad as usual >:D
Maybe trying another distribution could be solution for you.
-
<RANT MODE ON>
I'm really pissed off by KiCAD under Linux!
Why on earth is it so much broken?
That is not Linux-specific. I find it equally broke under Linux and Windows. Their footprint, sorry, their fscking "module" management goes on my tits. Their sluggish screen repainting, their user interface, their broken idea of a one-way workflow, their constantly breaking something that worked for the last few years, their invention of an own terminology, ...
And the worst: They just don't learn.
1) Default KiCAD under Ubuntu 14.04 completely broken
-> Known bug and probably Ubuntus fault
Also KiCad's fault. When you make building your shit annoying then package maintainers rather not bother to update the package. And, if they would really care, they would not only improve the build procedures, but actually maintain the package on their own. Instead of, for example, doing that shit git-based footprint, sorry, fucking "module" management.
-
Their footprint, sorry, their fscking "module" management goes on my tits. Their sluggish screen repainting, their user interface, their broken idea of a one-way workflow, their constantly breaking something that worked for the last few years, their invention of an own terminology, ...
And the worst: They just don't learn.
Well, that might be their attitude of developing an EDA tool. I can only compare it to Eagle which I used for the last 15 years (!OMG!). The management of the footprints is a big improvement compared to the eagle workflow, where you have a gazillion copies of the same footprint in each library ... That is soo bullshit, too!
I also like the Idea of not bothering footprint selection when I do the schematic. But sadly It is also flawed in KiCAD as you have to select a symbol with the correct pinout for a particular package... Think about Atmegas in DIP or QFP packages for example with their different pinouts that you have to have in mind when doing your schematics. Thus in KiCAD you have to create two identical schematic symbols for the same component depending on its package variants. Flawed ...
The rest you are talking about equally applies to Eagle: Very logical example ... use the cut symbol to perform a copying action ... for over 15 years at least!
Maybe the are all not learning, because they still don't have to...
-
Think about Atmegas in DIP or QFP packages for example with their different pinouts that you have to have in mind when doing your schematics. Thus in KiCAD you have to create two identical schematic symbols for the same component depending on its package variants. Flawed ...
This is very good practice. Two similar devices in different packages are different components with have different part numbers, and the fact that they're electrically similar is irrelevant - especially once you've designed one of them into a schematic and given the BoM to a customer.
Is it really a big deal to have both variants in a library? Really?
I used KiCad for a design a few years ago, being the best of the free tools I could find at the time. I soon gave up on it, though, when stupid, unforgivable bugs started showing up in essential features like BoM export. The Linux version had some fatal flaws, while the Windows version had others. I ended up having to dual boot and use both versions to complete the design.
If I'd carried on, I'd have easily incurred the price of a copy of Orcad just in wasted time.
Does Kicad still have the ridiculous, painful limitation that a schematic can only consist of one page at each level of hierarchy?
-
This is very good practice. Two similar devices in different packages are different components with have different part numbers, and the fact that they're electrically similar is irrelevant - especially once you've designed one of them into a schematic and given the BoM to a customer.
Is it really a big deal to have both variants in a library? Really?
No, It is not a big deal. But from a theoretical perspective a schematic should be a more abstract model of your product than the pcb-design. And when talking about pinouts and package variants during schematic capturing you are mixing the two levels of abstraction.
Of course at some point in the design process it is necessary to decide upon the particular part you are going to use and -of course- this should than be back-annotated to the schematic.
-
<RANT MODE ON>
I'm really pissed off by KiCAD under Linux!
man i thought its only me when running it under windows. makes me wonder then under what OS KiCAD specialized into?
-
But from a theoretical perspective a schematic should be a more abstract model of your product than the pcb-design. And when talking about pinouts and package variants during schematic capturing you are mixing the two levels of abstraction.
We'll have to agree to differ on this one. I regard the schematic as the absolutely definitive, specific reference document that prescribes which components are used in a design and how they are connected.
When I send a customer a schematic, I accept responsibility for that design working if, and only if, it is manufactured using the exact components I've specified. Swap in a cheaper alternative for this, or a different package for that, and you're building something which is no longer my design - and unless you checked with me first, you can't blame me if your part overheats, fails EMC or dies within a year.
Therefore, my design workflow begins and ends with uniquely identified components, whose specifications I check to ensure they will work in a given circuit. Once a circuit makes it off my whiteboard, there is no abstraction.
-
...
man i thought its only me when running it under windows. makes me wonder then under what OS KiCAD specialized into?
From an objective point of view, it makes sense to put ~95% of the effort into Windows releases:
(http://i159.photobucket.com/albums/t156/jaxbird/osshare_zps8e5b7a17.png)
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 (http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0)
-
From an objective point of view, it makes sense to put ~95% of the effort into Windows releases:
If those stats are representative for the target demographic, sure.
-
If those stats are representative for the target demographic, sure.
These are global, where Linux is of very insignificant size. They might have some download stats that are more representative, but still I'd be surprised if Windows doesn't count at least 75% of their user base.
-
From an objective point of view, it makes sense to put ~95% of the effort into Windows releases:
Why? They are not commercial. They don't earn money for providing their software. Their development effort is mostly driven by the idea of providing an open system. If I would develop software with this ideology I would naturally also target a free operating system as a reference platform.
I also don't buy the argument that 95% of the hackers, makers and hobbyists are using windows platforms. Maybe more a 60/40 ratio or even less. Companies are another story as they usually don't give a sh*t about open source EDA tools. They just buy one of the shelf...
Therefore I can't understand why their reference platform is apparently M$-Windows...
BTW, wouldn't that be a nice idea for a dedicated Ubuntu version? There are versions for musicians for example (Ubuntu Studio http://cdimage.ubuntu.com/ubuntustudio/releases/14.04/release/ (http://cdimage.ubuntu.com/ubuntustudio/releases/14.04/release/)).
Why not make a version for electronic engineers, with all the stuff preconfigured like cross-compilers, KiCAD, gEDA, qcad, simulators etc. etc.
-
Why? They are not commercial. They don't earn money for providing their software. Their development effort is mostly driven by the idea of providing an open system. If I would develop software with this ideology I would naturally also target a free operating system as a reference platform.
...
Making a piece of software, surely your goal is as large a user base as possible. Otherwise they should target something like MINIX (designed by Andrew Tanenbaum, probably the first open source OS, and the main inspiration for Linux), but it's not very popular these days, so to get a larger user base it makes more sense to target Windows, Linux and OSX.
And it makes most sense to distribute the effort based on popularity.
-
BTW, wouldn't that be a nice idea for a dedicated Ubuntu version? There are versions for musicians for example (Ubuntu Studio http://cdimage.ubuntu.com/ubuntustudio/releases/14.04/release/ (http://cdimage.ubuntu.com/ubuntustudio/releases/14.04/release/)).
Why not make a version for electronic engineers, with all the stuff preconfigured like cross-compilers, KiCAD, gEDA, qcad, simulators etc. etc.
Ubuntu UER, but they gave up after a few releases.
Fedora also has something, I don't think it is maintained recently.
-
Making a piece of software, surely your goal is as large a user base as possible.
Now that went straight into my heart as a software engineer!
No it is not, it never was and it will never be! Having the largest possible user base is something for marketing people.
Having identified your target users and designing a software according to their particular needs is what software engineering should be all about. The larger the user base is, the more difficult it becomes to design something that actually gets accepted and is appreciated. "One size fits all" most often does not work!
However, reading all the rants about KiCAD maybe those people sadly might in deed work towards that goal ...
-
However, reading all the rants about KiCAD maybe those people sadly might in deed work towards that goal ...
1 happy user here on both Windows and Linux.
-
Now that went straight into my heart as a software engineer!
No it is not, it never was and it will never be! Having the largest possible user base is something for marketing people.
Having identified your target users and designing a software according to their particular needs is what software engineering should be all about. The larger the user base is, the more difficult it becomes to design something that actually gets accepted and is appreciated. "One size fits all" most often does not work!
However, reading all the rants about KiCAD maybe those people sadly might in deed work towards that goal ...
So you'd prefer developing for some obscure OS with a tiny number of users?
Using that logic they should target only e.g. MINIX (mentioned in my previous post, google for details) as it is the original open source OS. Sure you might only have 10 users, but that does not matter?
Why would you not want to target the largest possible user base available?
If you are indeed a professional software developer, you do need a reasonable number paying users to provide you with a salary, or you wont be able to pay your rent and food.
-
So you'd prefer developing for some obscure OS with a tiny number of users?
Using that logic they should target only e.g. MINIX (mentioned in my previous post, google for details) as it is the original open source OS. Sure you might only have 10 users, but that does not matter?
If you are indeed a professional software developer, you do need a reasonable number paying users to provide you with a salary, or you wont be able to pay your rent and food.
No, I don't. But I prefer to know the specific requirements of the application's target users and design an artifact matching their needs. For me that would be a successful design. It has nothing to do with the size of the user group, except that his goal is harder to reach if the group size increases.
You mentioned the paying and salary aspect. Sure you need to earn money. But in an open-source context there are no paying users. At least not for the code. Maybe you get donations if you are lucky. If you don't have funding than this type of development is for your spare time unless you work in an academic context. To me, there are no other reason than money or reputation to argument the desire for a large user group. Even not for quality (think of openssl)!
And no, KiCAD should not shoot for MINIX. MINIX never was designed as an operating system for the average user. It was specifically designed as an educational system for Tannenbaum's lectures on operating system development. I'm glad you brought this example as it clearly shows how successful a design can be with the right target users in mind. Thousands of students read his book about MINIX (including myself) and one of them created Linux in the end. What a great success! Had the aim of the project been to maximise the user group size, Tannenbaum might have been better off developing a DOS clone instead...
However KiCAD does the other way round! They already have found their niche and have developed a pretty decent system that could be working on other platforms than Windows equally well for a large group of users. But instead carrying about those platforms they willingly accept to shrink their community by pissing off non-Windows user (Yes, under OSX it is equally bad as on Linux).
As I already said: Building open source software that is only useable on closed source systems is a contradiction to me ... regardless of the size of potential users ...
Anyway, happy coding ...
-
Using that logic they should target only e.g. MINIX (mentioned in my previous post, google for details) as it is the original open source OS. Sure you might only have 10 users, but that does not matter?
If the claim to support MINIX it should work well on MIMIX, even it has only 1 user. If they don't have the resources they should drop it from the supported OS's list.
-
I'm happy my post made you read up on Minix ;) Just used as an example, but as far as I know, it does have a production version, so it can be considered a fully featured OS.
I think there are some misconceptions on the origins of open source software, it is a huge (multi billion $) industry, the majority of the code is produced by paid developers and the money is usually earned back by selling hardware or added services (consulting etc) .. It's only a tiny portion developed by individuals in their spare time.
But if you want a better Linux KiCad, you could join the team and use your spare time to fix all the bugs instead of complaining about them :)
-
But if you want a better Linux KiCad, you could join the team and use your spare time to fix all the bugs instead of complaining about them :)
killer phrase :--
-
the majority of the code is produced by paid developers and the money is usually earned back by selling hardware or added services (consulting etc)
To be fair, this does explain a lot. Good quality, reliable, intuitive and capable software doesn't generally need support. Software that's difficult to use, buggy or downright perverse in the way it works, does.
If fixing problems and improving my product would actively cut off my revenue stream, I wouldn't fix them either.
But if you want a better Linux KiCad, you could join the team and use your spare time to fix all the bugs instead of complaining about them :)
I'm sure this is intended in jest, but it does bring up another very important point. An unreliable car that comes with a toolbox in the boot is not a substitute for a reliable car. However helpful other owners might be at helping you diagnose problems - assuming you're in the slightest bit mechanically minded to begin with - they're not much consolation when you're stuck by the side of the motorway in the pouring rain with smoke pouring out from under the bonnet, again.
-
But if you want a better Linux KiCad, you could join the team and use your spare time to fix all the bugs instead of complaining about them :)
killer phrase :--
Why is that?
You want high quality free software, but you don't want to contribute anything?
-
But if you want a better Linux KiCad, you could join the team and use your spare time to fix all the bugs instead of complaining about them :)
killer phrase :--
Why is that?
Because it is the standard response from open-source programmers when they want to tell you to shut up and fuck off. First they make it incredibly hard to contribute (e.g. because the software is hard to build, convoluted and undocumented, they have hundreds of obscure rules how to submit and then ignore or reject 99% of all submissions), then they tell you to fuck off when you tell them they have a problem but don't rub their back exactly the way they want.
-
But if you want a better Linux KiCad, you could join the team and use your spare time to fix all the bugs instead of complaining about them :)
killer phrase :--
Why is that?
Because that demonstrates the attitude of behaving irresponsible for the software one creates just because it is labeled open-source. Like openssl two moth ago:
Oh we fucked up the entire privacy of the whole internet ... sorry your fault! You didn't contribute!
That is a bullshit argument! From an end user perspective (thus not an active developer of that particular system) you almost never directly contribute, neither in open source, nor in closed source. The effort of diving into the code to fix a single bug is just too high if you are not a regular developer of that system, especially if those bugs are non-trivial. It would cost you a large amount of time, where the person familiarised with the source code would find a solution in minutes ...
However, you can still write bug reports and point the developers to the defects. But if the developers don't care about them for years ...
Now what should you do?
-
Why is that?
Because it is the standard response from open-source programmers when they want to tell you to shut up and fuck off. First they make it incredibly hard to contribute (e.g. because the software is hard to build, convoluted and undocumented, they have hundreds of obscure rules how to submit and then ignore or reject 99% of all submissions), then they tell you to fuck off when you tell them they have a problem but don't rub their back exactly the way they want.
Ok, fair enough, I guess with open source projects it can be difficult to contribute directly. That also somewhat ruins the whole concept because of the overhead involved in managing a largeish project and the basis for deciding which pieces makes it into the main branch.
But still, complaining about a free piece of software seems very counter productive.
-
I was using Kicad up until the point they broke their library.
I can't even open old projects because some of the same components have been changed, when this should never have happened.
I don't have enough invested to even care however.
Internet based library is just asking for trouble, this is completely rediculous, i'm not even going to bother trying to make that work
In my opinion, the library should be redesigned to be similar to how multisim handles it. with each part being both a schematic symbol, a specification, part number, link to pdf datasheet (this is great, kicad has this, but most of them are broken)
anyway, the actual design flow of kicad does make sense to me and i can use it, but they broke it repeatedly.
furthermore, the library and part editors never had a few key features, such as moving parts around from one library to another, or revision tracking.
-
But still, complaining about a free piece of software seems very counter productive.
Yes, complaining is never productive, as the problem does not go away ...
But then what would be a productive action in that case?
-
Quality
(http://imageshack.com/a/img845/6568/utge.png)
-
KiCAD is a really good free alternative. Maybe the only one that could be used by an average user.
The biggest problem is the code documentation. Also, the majority of the devs doesn't even bother to change the status of the bug they fix. Or they will commit a bug report fix without even saying what issues is addressees in the description of the commit.
Personally I like KiCAD under GNU/Linux. I build it almost daily (really simple processes) and track down bugs.
Alexander.
-
Another happy kicad user on linux. The only unsolved bugs I have noticed are the occasional drawing issue, which can be fixed in about 1/10th of a second by moving the mouse wheel down and then up again, and the fact that printing schematics doesn't work well. The former issue seems to be getting less common with time.
To work around the printing issue, the only fix I have found is plot to pdf. This IS an annoying bug, and heeds to be fixed!
-
As some of you have suggested, Debian might be the best matching platform to run KiCAD under linux.
Therefor I prepared a tiny howto for setting up a complete Debian/KiCAD environment inside virtual box.
1) Create a VM (8-XXGB depending on your needs)
2) Install debian normally (netinstall-image, deselect all extra package groups)
3) Add sudo rights to your user:
$ su -
# apt-get install sudo
# usermod -a -G sudo YOURUSERNAME
log out and back in! Now you should have sudo rights ...
3) Install X-Windows, xfce4 (or whatever you prefer) and some tools:
$ sudo apt-get install x-window-system xfce4 evince gv xterm iceweasel cups
3) Install the guest-additions to get better performance and resolution etc, etc...
$ sudo apt-get install build-essential module-assistant
$ sudo m-a prepare
Insert virtual media by clicking "Devices -> Insert Guest Additions CD image”
$ mount /media/cdrom
$ sudo sh VBoxLinuxAdditions.run
4) Start your X-Server
$ startx
You should by now have a fully working XFCE with dynamic window resizing etc etc.
5) install KiCad
Download kicad-install.sh from the kicad homepage
Open a terminal
$ cd
$ cd Downloads
$ chmod u+x kicad-install.sh
$ ./kicad-install.sh --install-or-update
Lean back for the next 1-2 hours ...
6) Install the kicad-repo-tools from the forum to workaround the stupid online footprint repository:
Download kicad-repo-tools.zip from https://www.eevblog.com/forum/open-source-kicad-geda/kicad-new-footprint-libraries-(-pretty)-packet/msg384444/#msg384444 (https://www.eevblog.com/forum/open-source-kicad-geda/kicad-new-footprint-libraries-(-pretty)-packet/msg384444/#msg384444)
$ unzip kicad-repo-tools.zip
$ sudo mkdir /usr/local/share/kicad/github-repo
$ sudo python clone-kicad-repo.py
I had to tun the script several times as github seemed to be unreliable at the time, giving me random connection errors …
As we ran the python script as root, we have to manually copy the fl-lib-table into our homedir
$ cd
$ cp /usr/local/share/kicad/template/fp-lib-table.for-pretty fp-lib-table
7) Set the KISYSMOD environment variable to point to the correct repository:
echo "export KISYSMOD=/usr/local/share/kicad/github-repo" >> .bashrc
Close the terminal and open a new one.
8) Finally start kicad
$ kicad &
That should be all …
Printing still does not work directly in eeschema (in pcbnew it however does ...), however the following workaround actually produces reasonable PDFs: Instead of using the Print command from the menu just use the Plot command and select PDF as output type. Credits to: https://bugs.launchpad.net/kicad/+bug/1051109 (https://bugs.launchpad.net/kicad/+bug/1051109)
Happy engineering!
-
Think about Atmegas in DIP or QFP packages for example with their different pinouts that you have to have in mind when doing your schematics. Thus in KiCAD you have to create two identical schematic symbols for the same component depending on its package variants. Flawed ...
This is very good practice. Two similar devices in different packages are different components with have different part numbers, and the fact that they're electrically similar is irrelevant - especially once you've designed one of them into a schematic and given the BoM to a customer.
Is it really a big deal to have both variants in a library? Really?
Every professional organization I've worked for or with has separate library parts for things which come in more than one package. As in: we usually use this dual op-amp in SOIC-8, and we need the smaller MSOP version, so you absolutely need two entries in symbol library (or integrated library if you're an Altium user). This is especially true if your symbols include some sort of company part number field which is used by the downstream BOM tools.
Oh, and Kicad's CvPCB program -- fucking stupid. Sure, let's put a dozen transistor symbols on a schematic, and then have some intermediate tool map those symbols to one of the myriad possible footprints (excuse me, modules) one might need, and then not fuck it up. There are Kicad users who actually defend this lossage. (At least one can include a footprint identifier in the symbol which is stored in the symbol library, so you don't actually have to use CvPCB.)
-
An I have not talked about using it under OSX. I gave that idea up very fast!
For what it's worth, the most recent BZR versions build and run well on OS X 10.9.4. They actually have a developer now who doesn't hate the platform.
-
I was using Kicad up until the point they broke their library.
For what it's worth: most users maintain their own libraries and simply do not depend on libraries provided by the tools. This isn't even limited to Kicad; at the day job we use Altium and we have a company-standard (vetted, with company part numbers in the symbols, etc) library everyone uses. That Altium has all of these vaults and what-not is not relevant. (Our PCB guy does go to the vaults to see if Altium has provided a component already; if so, it's copied out of that library, vetted, and sometimes the symbol is changed to something that doesn't suck.)
Oh, and so the Kicad developers have created this git-based system to pull library parts from ... somewhere. Oh, great. That goes against the whole idea of a user's standard vetted library, but I guess enough users think that sort of thing is OK.
-
I was using Kicad up until the point they broke their library.
For what it's worth: most users maintain their own libraries and simply do not depend on libraries provided by the tools. [...]
Oh, and so the Kicad developers have created this git-based system to pull library parts from ... somewhere. Oh, great. That goes against the whole idea of a user's standard vetted library, but I guess enough users think that sort of thing is OK.
this is what i'm talking about:
the topology of how their schematic symbol, linked to a part file, linked to a footprint, i can understand, and work with it, and its annoying.
the filters never worked properly, filter by pin number doesn't even work reliably, etc.
and then they went and changed a bunch of things and we ended up with the root installation installing non modifiable library files in a root system directory.
and the library table editor doesn't make any logical sense.
you can't move parts from one library into another without an external library editor (one of which was written by someone on this forum)
" set the KISYSMOD environment variable to point to the correct repository:"
yeah, i'll get write on that..
even if i had to go and individually vet every single iota in the library, i can understand that, and put up with it, but the entire topology is just too "french" might be a good word
-
Oh, and so the Kicad developers have created this git-based system to pull library parts from ... somewhere. Oh, great. That goes against the whole idea of a user's standard vetted library, but I guess enough users think that sort of thing is OK.
They came so close to getting this right it's really disappointing. If they had just put the entire library in a single git repository, this would've been almost ideal. You can clone the upstream libraries, make your local adjustments in your own github (or local git) and then easily pull improvements from upstream without breaking your changes. The UI is obviously not there yet, but will come I think. The big problem is that every category is a separate git repo, so you can't easily clone it wholesale.
Oh, and Kicad's CvPCB program -- fucking stupid. Sure, let's put a dozen transistor symbols on a schematic, and then have some intermediate tool map those symbols to one of the myriad possible footprints (excuse me, modules) one might need, and then not fuck it up. There are Kicad users who actually defend this lossage. (At least one can include a footprint identifier in the symbol which is stored in the symbol library, so you don't actually have to use CvPCB.)
I don't necessarily like this, but I don't consider it a big deal either. When you select a designator in CvPCB, it is highlighted in the schematic editor, and if package selection is critical you would have put it into the properties while capturing the schematic. I would really like to see it work more like Altium, however, where each symbol can be associated with multiple footprints and have different pinouts depending on the package. Then you will know the symbol and footprint match.
-
Oh, and Kicad's CvPCB program -- fucking stupid. Sure, let's put a dozen transistor symbols on a schematic, and then have some intermediate tool map those symbols to one of the myriad possible footprints (excuse me, modules) one might need, and then not fuck it up. There are Kicad users who actually defend this lossage. (At least one can include a footprint identifier in the symbol which is stored in the symbol library, so you don't actually have to use CvPCB.)
I don't necessarily like this, but I don't consider it a big deal either. When you select a designator in CvPCB, it is highlighted in the schematic editor, and if package selection is critical you would have put it into the properties while capturing the schematic. I would really like to see it work more like Altium, however, where each symbol can be associated with multiple footprints and have different pinouts depending on the package. Then you will know the symbol and footprint match.
We use Altium at the day job, and we don't do the mutliple-footprints-per-symbol thing. That's because our system has a part number embedded in the symbol, and that part number is used by a downstream database to generate BOMs against which we order parts. It's not like we have a thousand parts in the library so it becomes unwieldy. So it's easy enough to have RES0805 and RES0603 as separate symbols, or perhaps LM317EMP and LM317T. The designer chooses the desired part at entry time. That's because package selection IS critical. You have to know what you're putting on the board and you have to know what you're ordering.
-
We use Altium at the day job, and we don't do the mutliple-footprints-per-symbol thing. That's because our system has a part number embedded in the symbol, and that part number is used by a downstream database to generate BOMs against which we order parts. It's not like we have a thousand parts in the library so it becomes unwieldy. So it's easy enough to have RES0805 and RES0603 as separate symbols, or perhaps LM317EMP and LM317T. The designer chooses the desired part at entry time. That's because package selection IS critical. You have to know what you're putting on the board and you have to know what you're ordering.
That's perfectly reasonable, but as a hobbyist it serves me no purpose and just generates extra effort creating/editing symbols. Filling out the pin map takes seconds, while editing each individual pin is kind of a pain in the ass, especially for a part with many pins. I can't think of any sane way of implementing the multi-package support which would prevent you from doing it your way, yours is just a special case with each symbol having one footprint. For example there's nothing stopping you from doing something similar to what you do at work in KiCad; each symbol has a list of packages and CvPCB's auto package assignment will use it, so if you go to the effort to set up your custom symbols library it's an extra click or two but achieves the same basic workflow.
When I used to use (pirated) Altium, I did find it nice to be able to e.g. select a TQFP instead of TSSOP footprint in the schematic editor and have the nets and PCB all updated relatively seamlessly. As someone with a comp sci background, it also seems like rather a good abstraction to handle it that way, since the logical idea of the part on the schematic has nothing to do with its physical expression, and the two are linked by a pin map. For me, it made it easy enough to just enter all the pin mappings for every package when I created the symbol, then during layout time if I decided I needed a smaller one or whatever, it was just a matter of changing it instead of going back to the datasheet, creating a new symbol, editing every single pin on it etc.
-
That about then exchange project with others. Do Kicad work like Protel(Altium).
It is enough to exchange SCH, PCB and (not necessary > projekt file)
Will all the symbols be usable and easy to save in you own library. Or is it important that all libraries and maybe other files also must bee include then exchange with others ?
-
KiCad stores the used symbols in a cache file in the same folder as the project file, this file is searched for the symbols before the default libraries. This ensures that the symbols in the schematic is the same as when it was created.
To use this you need to share the project file as this file determines the name of the cache file, preferably the whole project folder (without the backup files) should be shared in a archived format. This archive will be small enough for emailing and so on...
To use a "shared" symbol you just open that symbol in the library editor and sets the default library then save it.
-
Thanks Thor-Arne
If every user know that info then it is not a problem.
So nice to know.
-
KiCad's project manager has a File->Archive menu option just for this, which pulls all the necessary files and symbols into one .zip file for distribution.
-
Lol, I forgot that since I generally uses winrar to archive revisions of my project. :palm:
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
What easy software is there to draw a schematic then make a PCB. And I'm not looking for something that will necessarily import everything from schematic. I don't mind doing everything manually on the PCB design and just looking at the schematic for reference. I just want something that I can design in without spending an entire DAY trying to get it working.
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
What platform? What BZR version? Help us help you.
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
What easy software is there to draw a schematic then make a PCB. And I'm not looking for something that will necessarily import everything from schematic. I don't mind doing everything manually on the PCB design and just looking at the schematic for reference. I just want something that I can design in without spending an entire DAY trying to get it working.
If you decide to give KiCad one more chance and let the guys on here help you then go for it.
Otherwise, DipTrace and Eagle are the next logical programs. I like DipTrace and feel it is more intuitive. Others love Eagle just as much. Both have free versions with their own restrictions (Eagle: 100x80mm board, unlimited pins, 2 layers ; DipTrace: 500 pins, unlimited size board, 2 layers).
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
You just need to add the libraries to the PCB side of the software as well. Nothing is broken in that sense. Slightly cumbersome yes.
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
You just need to add the libraries to the PCB side of the software as well. Nothing is broken in that sense. Slightly cumbersome yes.
Agreed, he should really just read the doc.
http://bazaar.launchpad.net/~kicad-developers/kicad/doc/view/head:/doc/help/en/cvpcb.pdf (http://bazaar.launchpad.net/~kicad-developers/kicad/doc/view/head:/doc/help/en/cvpcb.pdf)
-
Oh, and so the Kicad developers have created this git-based system to pull library parts from ... somewhere. Oh, great. That goes against the whole idea of a user's standard vetted library, but I guess enough users think that sort of thing is OK.
They came so close to getting this right it's really disappointing. If they had just put the entire library in a single git repository, this would've been almost ideal. You can clone the upstream libraries, make your local adjustments in your own github (or local git) and then easily pull improvements from upstream without breaking your changes. The UI is obviously not there yet, but will come I think. The big problem is that every category is a separate git repo, so you can't easily clone it wholesale.
Well, the idea is that you might only need a couple of the .pretty libs. Aslo you can use the scripts to download the library, e.g. scripts/library-repos-install.sh for linux and osx. The scripts/library-repos-install.bat is very dumb and hardcoded, that might only work partially.
-
KiCAD is a really good free alternative. Maybe the only one that could be used by an average user.
The biggest problem is the code documentation. Also, the majority of the devs doesn't even bother to change the status of the bug they fix. Or they will commit a bug report fix without even saying what issues is addressees in the description of the commit.
Personally I like KiCAD under GNU/Linux. I build it almost daily (really simple processes) and track down bugs.
Alexander.
What kind of code documentation are you talking about? The code is doxygen formatted. You can generate the C++ doc with make doxygen-doc and even the python doc with make doxygen-python.
Alsp, in the last few months the devs has been better to mark bugs as fixed and often but not always write the bug id in the commit log.
-
Oh, and so the Kicad developers have created this git-based system to pull library parts from ... somewhere. Oh, great. That goes against the whole idea of a user's standard vetted library, but I guess enough users think that sort of thing is OK.
They came so close to getting this right it's really disappointing. If they had just put the entire library in a single git repository, this would've been almost ideal. You can clone the upstream libraries, make your local adjustments in your own github (or local git) and then easily pull improvements from upstream without breaking your changes. The UI is obviously not there yet, but will come I think. The big problem is that every category is a separate git repo, so you can't easily clone it wholesale.
Well, the idea is that you might only need a couple of the .pretty libs. Aslo you can use the scripts to download the library, e.g. scripts/library-repos-install.sh for linux and osx. The scripts/library-repos-install.bat is very dumb and hardcoded, that might only work partially.
You can and it's not that hard, but this basically makes using git in the first place pointless. You're throwing away the centralized management and change control that would be extremely valuable for a negligible reduction in bandwidth/disk space. Not worth it, IMO. I certainly don't want to be the one keeping track of a dozen different git repos that basically all contain the same information. We need to consider that the repos will need to be branched, merged, possibly with changes pulled from multiple origins, etc. That just breaks down completely when you expect the user to do that manually for every single repo.
I'm not an expert on git though, I believe there may be a way to set up dependencies so that a parent git repo can automagically integrate all of these children once set up, to reduce the management overhead. If this is possible, I'd love to know how.
-
For a single-seat hobbyist or a one-man shop, I don't see what advantage is in having a centralized git repository (or repositories). I cloned all the git repos from Kicad's github locally and only use those (this makes possible working while commuting, for example). I have my own custom libraries created locally but pushet to my own github too, "in case something wrong happens".
However, if sometimes Kicad gets adopted by a multi-engineer team, a centralized company-wide repos can be very interesting to have. For me, this modification goes in the right direction, opening horizons for "big houses" adoption.
-
For a single-seat hobbyist or a one-man shop, I don't see what advantage is in having a centralized git repository (or repositories). I cloned all the git repos from Kicad's github locally and only use those (this makes possible working while commuting, for example). I have my own custom libraries created locally but pushet to my own github too, "in case something wrong happens".
For one thing it facilitates sharing. Find something wrong with a builtin library? Fix your local repo and submit a pull request upstream. For another, it lets you easily maintain local modifications of the stock libraries while still being able to track upstream changes, and even merge them with your modified libraries if that makes sense. As a way to distribute the "official" libraries, or a community set of libraries, it seems pretty ideal.
You could also then pin your project to a particular git commit to ensure the libraries you used are identical in the future, even if you have to pull down the sources again. I don't think the UI for this exists, but it would be a useful feature to integrate (project is tied to a certain git commit present at creation) and not difficult to do manually.
Lots of this breaks or becomes unwieldy when you split the thing into a billion repositories though...
However, if sometimes Kicad gets adopted by a multi-engineer team, a centralized company-wide repos can be very interesting to have. For me, this modification goes in the right direction, opening horizons for "big houses" adoption.
I don't think companies are the only place where collaboration occurs. Even two DIYers fooling around with a simple project could make use of it. Bonus that all of KiCad's other files are plain text too and can be managed sensibly in git.
-
Everyone angry at the current state of KiCad should be developing it right now. It's not going to get any better by being angry on forums, there's no big company or organization behind the project, they don't really have any project outlines or a plan in motion as to what KiCad will be or should be. They lean heavily on the free contribution of volunteers without any real organization of the project. Developers are free to take it to a direction they wish to.
It's really bad way of handling a project, I know, but if you wish that to change, take a lead. Start organizing, start developing code, start laying out a plan and goal posts and managing the development.
Or shut up. It's easy to be angry and criticize, it's harder to do something about it.
If KiCad had some sort of organization behind it, I would be angry too. As of now, i'm just frustrated that they've let the project go to this situation over the years.
But the thing is, professionals need tools that work, and none of those who really need KiCad to be a tool haven't got the time or need to work on it to get it better. Because professionals can afford the industry standard tools that are very advanced and highly usable for their work.
Now with CERN giving KiCad some incentive and money (they need donations, obviously) it's perhaps going to be better than before, but without your help it's not going to go there very fast.
It's your choice if you need a tool, that if you wish to pay for it, or develop a free one for everyone.
-
I am building and testing kicad almost daily. All kicad team has to do is a code freeze. I was wating for it after finishing the "kiway".
Alexander.
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
You just need to add the libraries to the PCB side of the software as well. Nothing is broken in that sense. Slightly cumbersome yes.
Agreed, he should really just read the doc.
http://bazaar.launchpad.net/~kicad-developers/kicad/doc/view/head:/doc/help/en/cvpcb.pdf (http://bazaar.launchpad.net/~kicad-developers/kicad/doc/view/head:/doc/help/en/cvpcb.pdf)
Usability is something that KiCad really needs people to organize and work on with a clear plan in mind, it's not very good at the moment and it will not get much better until some ground work is done. There's been dozens of hacks to make it better, but to really make KiCads usability good one needs to make fundamental work on better systems to manage how the libraries, PCB and schematic data is handled between the programs.
In CERN branch there's a clear plan for that frame work and I hope it'll put an end to the usability problems when it's easier to make stuff integrate and behave well together.
KiCad's many programs that are trying to work as one, but the integration between them isn't very tight by design, they're separate programs that are bundled together in a package called KiCad and they're not really one integrated solution for making professional PCB's. It's nice and modular by engineering perspective and fits well with general Linux and open source style of making programs, but it's not very good for usability and integration in mind.
When people need to read the doc to get libraries to work from schematic to layout it's a clear sign that there's something to be fixed about the flow of the program in general.
In many other programs I just press "I want a PCB" and the back and forth annotation works mainly without a hitch or any input from the user.
-
That it is! |O >:(
I just finished drawing several schematics with it and when I went to create the first PCB I started getting the constant errors stating that footprints can't be found, libaries can't be found, etc., etc., etc.
Today I've officially given up on Kicad. It's just too broken.
What easy software is there to draw a schematic then make a PCB. And I'm not looking for something that will necessarily import everything from schematic. I don't mind doing everything manually on the PCB design and just looking at the schematic for reference. I just want something that I can design in without spending an entire DAY trying to get it working.
I hear you brother!
With Eagle, Altium, (everything else?) you share your schematic and pcb files, and that's it. Opens in any editor, anyone can re-use it.
With KiCAD, fergeddaboudit! I often work on my laptop at home, and then email the files to myself at work to tinker with at lunch time. Tried KiCAD at home, half way through, emailed the files to myself at work, logged into my work account and found half my schematic missing. |O
KiCAD has a loooong way to go before I'll try it again. Don't get me started on the munted three click shuffle to do a simple copy / paste....
-
With Eagle, Altium, (everything else?) you share your schematic and pcb files, and that's it. Opens in any editor, anyone can re-use it.
With KiCAD, fergeddaboudit! I often work on my laptop at home, and then email the files to myself at work to tinker with at lunch time. Tried KiCAD at home, half way through, emailed the files to myself at work, logged into my work account and found half my schematic missing. |O
Which (BZR) version are you using? (How old is it?) Do you have the same version installed on both machines? Do both machines have the same libraries installed?
-
...Do you have the same version installed on both machines? Do both machines have the same libraries installed?
Forget which BZR, but yes both machines have the same version. But you know what? Altium doesn't care - AD14 can open AD10 files, no worries etc. Is Eagle so temperamental about versions?
But that's a moot point, if you need to keep versions the same, fine, ok, I can manage that.
As for both libraries? Nope. Especially if I've updated one lib at home at 2AM.
BUT WHY SHOULD THAT MATTER? Why not embed the freaking symbols in the schematic? Again, Eagle / Altium happy to open a schematic from *some where else*, without the same libraries, and show you a complete schematic.
-
In Protel and later Altium you dont have to care about the libraries. It is like included in the file.
Think about why PDF are so popular ..... It a single file, No need for include JPG and fronts if you need that to.
Quote from: Bassman59 on Today at 10:02:05 AMDo both machines have the same libraries installed?
-
Kicad uses an Archive function for sharing projects.
Alexander.
-
Nice tip, thanks.
-
Now can someone show me how to re-bind the keys (windows)?