-
This is straight from the developers website so it has not even been announced on http://kicad-pcb.org/ yet.
The RC1 stable release is a snapshot of version R6188. You should see an official announcement soon and should be able to download the RC1 release from the website above.
Please download it and try it out. Thanks.
P.S Here is the official announcement.
http://kicad-pcb.org/post/2015-release-candidate/
The link for downloading the software is on this page. -
I upgraded, and it seems this release changed the default size and look for the capacitor and resistor symbols in the standard library.
So when I started eeschema and loaded a schematic that I was working on yesterday (using a July release 07-21 BZR5971), it popped up a warning that my schematic was built with older library parts, and showed me the cached part and the updated library parts side-by-side. This dialog is a "Rescue" dialog, it offers to clone my parts from the cache into a new library. It showed 4 parts had changed... R, C, CP and ZENER.
Since I did not want to clone my parts, and instead wanted to use the new parts from the new library, (the CP part was better, in particular), I unchecked all 4 parts and that would make it NOT clone the old parts from the cache, and instead load the new parts into my schematic.
Well it did this, and replaced all my resistors and caps with their smaller versions from the new library, but it left all the nets unconnected
grrr.. I think I understand what they did here... it seems they standardized on the schematic symbol part size for all these parts now. This is good, but the tool just swapped the part in and left all the parts unconnected if they were different size (smaller now).
Clearly it needs to be smarter about this. I have to reconnect everything
See attachment.
-
I upgraded, and it seems this release changed the default size and look for the capacitor and resistor symbols in the standard library.
So when I started eeschema and loaded a schematic that I was working on yesterday (using a July release 07-21 BZR5971), it popped up a warning that my schematic was built with older library parts, and showed me the cached part and the updated library parts side-by-side. This dialog is a "Rescue" dialog, it offers to clone my parts from the cache into a new library. It showed 4 parts had changed... R, C, CP and ZENER.
Since I did not want to clone my parts, and instead wanted to use the new parts from the new library, (the CP part was better, in particular), I unchecked all 4 parts and that would make it NOT clone the old parts from the cache, and instead load the new parts into my schematic.
Well it did this, and replaced all my resistors and caps with their smaller versions from the new library, but it left all the nets unconnected grrr.. I think I understand what they did here... it seems they standardized on the schematic symbol part size for all these parts now. This is good, but the tool just swapped the part in and left all the parts unconnected if they were different size (smaller now).
Clearly it needs to be smarter about this. I have to reconnect everything
See attachment.
That's one of the things annoy me a lot about KiCad. Nets get unattached for whatever reason
I hope they fix it. . -
I upgraded, and it seems this release changed the default size and look for the capacitor and resistor symbols in the standard library.
So when I started eeschema and loaded a schematic that I was working on yesterday (using a July release 07-21 BZR5971), it popped up a warning that my schematic was built with older library parts, and showed me the cached part and the updated library parts side-by-side. This dialog is a "Rescue" dialog, it offers to clone my parts from the cache into a new library. It showed 4 parts had changed... R, C, CP and ZENER.
Since I did not want to clone my parts, and instead wanted to use the new parts from the new library, (the CP part was better, in particular), I unchecked all 4 parts and that would make it NOT clone the old parts from the cache, and instead load the new parts into my schematic.
Well it did this, and replaced all my resistors and caps with their smaller versions from the new library, but it left all the nets unconnected grrr.. I think I understand what they did here... it seems they standardized on the schematic symbol part size for all these parts now. This is good, but the tool just swapped the part in and left all the parts unconnected if they were different size (smaller now).
Clearly it needs to be smarter about this. I have to reconnect everything
See attachment.
That's one of the things annoy me a lot about KiCad. Nets get unattached for whatever reason
I hope they fix it. .
Well, the reason in this case is pretty obvious: the new symbols are not as wide as the old symbols.
It's also a library issue, not a core Kicad issue. -
I upgraded, and it seems this release changed the default size and look for the capacitor and resistor symbols in the standard library.
So when I started eeschema and loaded a schematic that I was working on yesterday (using a July release 07-21 BZR5971), it popped up a warning that my schematic was built with older library parts, and showed me the cached part and the updated library parts side-by-side. This dialog is a "Rescue" dialog, it offers to clone my parts from the cache into a new library. It showed 4 parts had changed... R, C, CP and ZENER.
Since I did not want to clone my parts, and instead wanted to use the new parts from the new library, (the CP part was better, in particular), I unchecked all 4 parts and that would make it NOT clone the old parts from the cache, and instead load the new parts into my schematic.
Well it did this, and replaced all my resistors and caps with their smaller versions from the new library, but it left all the nets unconnected grrr.. I think I understand what they did here... it seems they standardized on the schematic symbol part size for all these parts now. This is good, but the tool just swapped the part in and left all the parts unconnected if they were different size (smaller now).
Clearly it needs to be smarter about this. I have to reconnect everything
See attachment.
That's one of the things annoy me a lot about KiCad. Nets get unattached for whatever reason
I hope they fix it. .
Well, the reason in this case is pretty obvious: the new symbols are not as wide as the old symbols.
It's also a library issue, not a core Kicad issue.
I'm not a KiCad expert, at all but the wiring behavior is widely known. Many are used to it and justify it, others dislike it.
I'm obviously totally against it, it's too cumbersome to me. -
Well, the reason in this case is pretty obvious: the new symbols are not as wide as the old symbols.
It's also a library issue, not a core Kicad issue.
The reason for the disconnect is clear, yes. The new library parts are smaller than the old ones. However, that does not make it acceptable, nor justifiable, to leave it like that.
How can you say it's a library issue, not a kicad issue? the Rescue dialog offers to give me the choice of keeping my old parts or switching to the new parts. When I decide to switch, it disconnects nets that were connected before.
I say it's a kicad issue since they should make a best effort attempt to reconnect nets that were already connected to parts that are being replaced. Maybe I'll make the code changes and submit the code myself, instead of complaining
-
Well, the reason in this case is pretty obvious: the new symbols are not as wide as the old symbols.
It's also a library issue, not a core Kicad issue.
The reason for the disconnect is clear, yes. The new library parts are smaller than the old ones. However, that does not make it acceptable, nor justifiable, to leave it like that.
How can you say it's a library issue, not a kicad issue? the Rescue dialog offers to give me the choice of keeping my old parts or switching to the new parts. When I decide to switch, it disconnects nets that were connected before.
I say it's a kicad issue since they should make a best effort attempt to reconnect nets that were already connected to parts that are being replaced. Maybe I'll make the code changes and submit the code myself, instead of complaining
It's a common behavior that can be changed by some hotkey. But it's messy most of the time to me.
Oh, please send some patches!
-
didnt someone tell them to establish file format and data structure in the first place? file format changes is the last thing anyone's want...
-
In the Library manager load your whateverproject-cache.lib from your project folder. Then put it the first on the libraries list.
Eeschema will load that symbols first and the problems will solve. -
In the Library manager load your whateverproject-cache.lib from your project folder. Then put it the first on the libraries list.
Eeschema will load that symbols first and the problems will solve.
That's not the problem. I didn't accidentally get new libraries, I wanted the new ones.
I upgraded and didn't want to use the cached symbols anymore. So I said "No" to the question to use my cache, and instead I chose to use the new symbols from the new library, and it did that quite blindly in fact, and left the nets disconnected on the schematic because the new symbols were smaller (in length).
The new symbols still have 2 pins like the old ones, the nets should stay connected. That's my complaint. Especially in simple devices like R's and C's that have only 90-degree orientations, so wires generally come from the left or the right or the top or the bottom. Extending these wires to meet the new pins should be done in a best-effort manner.
It's almost as if the update code simply popped the new symbols onto the schematic with the new (smaller) X/Y positions, and because a wire doesn't end where a pin from a device starts now, the net became disconnected. This makes me think the netlist is derived from the wiring. I think that's wrong, and probably leads to many special cases with named nets and nets that go off the schematic onto another hierarchy. These don't have wires, so they probably special case them (I'll have to look at the code to be sure before I resort to name calling )
However, I realize that changing this might be hard if it means a file format change to better support this use-case, which won't come up that often for 90% of the users anyways. Library changes like this are not done often enough to make it an issue worth supporting. There are, indeed, bigger fish to fry here. -
I upgraded and didn't want to use the cached symbols anymore. So I said "No" to the question to use my cache, and instead I chose to use the new symbols from the new library, and it did that quite blindly in fact, and left the nets disconnected on the schematic because the new symbols were smaller (in length).
The new symbols still have 2 pins like the old ones, the nets should stay connected. That's my complaint. Especially in simple devices like R's and C's that have only 90-degree orientations, so wires generally come from the left or the right or the top or the bottom. Extending these wires to meet the new pins should be done in a best-effort manner.
For the trivial case where the legs of the new symbol are shorter than the old symbol, the reconnect is obviously simple.
What if the new symbol made those legs longer? What if the designer of the new symbol decided to unhide hidden power pins (because hidden power pins are fucking stupid)? What if the symbol was a simple box with pins, and the designer decided that the pin names needed to be understandable so the box was made larger to accomodate the pin names? What if the pins on the symbol moved?
What then?QuoteHowever, I realize that changing this might be hard if it means a file format change to better support this use-case, which won't come up that often for 90% of the users anyways. Library changes like this are not done often enough to make it an issue worth supporting. There are, indeed, bigger fish to fry here.
There is no file format change involved. This was a style decision, and again it points to the reason why the experienced folks like to say, "USE YOUR OWN VETTED LIBRARIES." -
I realize there is no file format involved IN THIS CHANGE. What I was implying there was a possible file format change to better support this specific use case, and I concluded that it was hard or impossible if it meant a file format change (i.e. to support net lists independent of the wiring lists -- as it appears now that the net list is DERIVED from the wire list, which in my opinion wiring connections is merely a display issue, the net connections should be independent of that, and I don't think it is )
Yes, the other cases you mentioned would be difficult, I know. Power pins suddenly becoming un-hidden, or pins moving about in a box...
That's why I said it would probably require a file format change, to separate the net list from the wire list. And I did say "best effort" to reconnect them. Things like boxes growing or shrinking are equally trivial. Pins and wires moving about can be handled by the same display algorithms that move connections above, below and around things when you move a wire interactively. It's all possible, but I concluded that to support it might require a file format change that is likely not going to be done, simply because this use-case is not going to affect many people. For myself it was a one-time thing, and I'm past it now. And definitely using you're own vetted libraries will further shield people from this too.
So my conclusion is that it's not worth it, and I'm happy with that. As I said, there are other areas in Kicad that need work, and that are worth more to more people than this one time event.
-
OMG!!!
We can only hope that developers and other contributors will push the same cart and will make this a wonderful release.
Hopefully everyone goes, tests the crap out of it, reports bugs and makes bug fixes and enhancements to existing features! -
So what is the situation with libraries now, have they got their act together and produced software that looks like i can stake my business on it or should I stick with equally crappy diptrace that have spent over a year making a new version that adds a couple of feature I don't need?
-
So what is the situation with libraries now, have they got their act together and produced software that looks like i can stake my business on it [...]?
It's free open source software, so if you want good libraries, contribute. Of course it's no excuse for them to be crappy, but you're not a client and they don't work for you.
In the meanwhile I'm looking other software for the business side of things since KiCad isn't there yet and even if I hope, I'm not expecting it to be there yet in this first stable either.
It all depends upon how much skillful people they get to develop it that all are working together for the same goal. Difficult to achieve when you're not paying them anything for their time and effort. -
I was using it happily and was going to use it for business until they redid the way libraries are managed and suddenly i didn't have any libraries as they were all pulled in from online or something and there were no instructions. I liked it as a program, but i need some security.
-
Nothing special with the libraries being online on a git repo. You can download them and use them offline as well.
Alexander. -
Nothing special with the libraries being online on a git repo. You can download them and use them offline as well.
Alexander.
but it didn't help that there were no instructions so I just gave up and went and paid for software. This is the first official release in years -
I was using it happily and was going to use it for business until they redid the way libraries are managed and suddenly i didn't have any libraries as they were all pulled in from online or something and there were no instructions. I liked it as a program, but i need some security.
The security is:
<broken record>
Create and use your own libraries.
You can copy parts from community supplied libraries, you can make your own, you can hire someone to make the parts for you, but don't rely on any library you haven't vetted and can't control.
</broken record> -
but when you see the whole software take a turn the wrong way you steer clear of it. No updates for years and no documentation of new features..... I'm glad they are back on track, might get diptrace to pull their fingers out of their assholes
-
but when you see the whole software take a turn the wrong way you steer clear of it. No updates for years and no documentation of new features..... I'm glad they are back on track, might get diptrace to pull their fingers out of their assholes
I sure hope so! A few years ago I was very deep in in DipTrace, but the lack of updates and the slow pace forward by the developers killed it for me... -
Create and use your own libraries.
You can copy parts from community supplied libraries, you can make your own, you can hire someone to make the parts for you, but don't rely on any library you haven't vetted and can't control.
I always create my own libraries even if I get a library part that's made perfectly. Why? Because then I know it's been checked and double checked by me, and those parts that have been checked and found to be good, go into my own internal library.
I basically expect only the basic stuff to be there in the libraries provided by the software. Standard resistors capacitors and inductors and JEDEC accepted footprints etc. Maybe 2.54mm and 1.27mm headers etc.
But all the micros, custom packaged crystals, mems devices BGA's.. you anme it. They're double checked if taken from the library or made from scratch to be sure.
This is why any good package has very efficient and powerful footprint wizards etc. that help you to save time when making parts.
Eagle for example is quite hopeless in this regard. KiCad has some basics down, but needs a lot more work.
One thing I've always wanted to see in KiCad is to be able to create pin mapping by open spreadsheet format. You have rows of pins and each column is "name of the pin" "direction" "description" "alternative functions" etc. and when you've made your device with wizard, you'll give this file to it and it'll attach everything to their proper places.
This way even manufacturers can release this file with their products and you can just create the footprint and package, then add the manufacturer provided file and off you go.
This way you can use text editor and more suitable tools to edit this information and just link it in when you want to put it to the CAD program.
-
I also tend to create my own parts but I don't loaded a version about a year ago or more and could not work out how to tell it where to get even my own libraries, it was a mess. It now seems to incorporate libraries off the shelf again and hopegully be easy to add your own like before.
-
I basically expect only the basic stuff to be there in the libraries provided by the software. Standard resistors capacitors and inductors and JEDEC accepted footprints etc. Maybe 2.54mm and 1.27mm headers etc.
They still have a LONG way to go before all of the JEDEC-accepted footprints are there, longer still before they are all harmonized in terms of solder-mask clearance and so on. Pretty much all I can use are the standard xxyy two-terminal footprints, and maybe some of the 0.1" headers. Sometimes I get lucky and find a QFP or SOIC that matches.
Really, the main problem in their libraries is one of hygiene. The situation would improve markedly if they just got rid of 95% of the footprints and schematic symbols, or exiled them to some legacy container. The existing libraries are chock full of truly ancient and obscure parts, like Xilinx Virtex-2, and a hundred-and-one versions of 78xx and 79xx regulators. None of this gets fixed/organized because it is exactly like documentation: the last priority on the typical engineer's list.
The best thing about KiCAD, IMO, besides the fact that it is free, is that you can write footprints in a text editor. I actually dread making new schematic symbols more... so tedious compared to the footprints! And that's using the rohrbacher web tool.
-
The situation would improve markedly if they just got rid of 95% of the footprints and schematic symbols, or exiled them to some legacy container. The existing libraries are chock full of truly ancient and obscure parts, like Xilinx Virtex-2, and a hundred-and-one versions of 78xx and 79xx regulators. None of this gets fixed/organized because it is exactly like documentation: the last priority on the typical engineer's list.
That's part of it, but if you dare suggest that they remove the 74LSxxx parts because you can't buy them, invariably someone on the user list will complain, "WHAT HAPPENED TO THE 74LS154!!!"
And as such the librarians are loathe to remove any part.