Hello All:
Please comment on recent experiences with KiCAD. We are considering using it under windows for PC Boards with at least 4 layers.
Are there any limitations? Any funny file format issues? Are the generated Gerber files in a standard format? Is it easy to add new components? Will it accept schematic files from LTSPICE?
Thanks, TomC
Is this some KiCad campaign? Anyway I've tried it and I didn't like it. Drawing traces is cumbersome.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
It's free, so download it and try it on your applications. I've done six layer boards with it; worked fine. File formats are all ASCII-readable, it creates netlists in several formats, including SPICE. I've not tried the SPICE netlists with LTSPICE, myself, as when I do run simulations it's for a small snippet and not an entire board. Does not (AFAIK) back-import from LTSPICE.
Gerbers and drill files are standard. I've sent them out to Sunstone, Advanced Circuits, and Alberta Printed Circuits with no issues.
The biggest complaint (ping Joerg ;-) seems to be that the schematic frame is not editable and so may not comply with company or agency requirements for a specific title block, etc.
Also, since they are ASCII the schematic and board files are easy to handle in revision control systems.
-- Rich Webb Norfolk, VA
And I might add, Kicad installed very fast and painlessly.
Yep, that's almost my only gripe. When I tried Kicad years ago I really liked the schematic editor and the library editing. Very nicely done. But since I cannot use a CAD with a fixed drawing frame I have never tried again. I will though, once that's fixed.
There were some minor issues with auto-numbering in that it occasionally re-assigns parts among packages where you don't want them swapped. But not nearly as bad as gEDA was in that respect. If Kicad and gEDA would join forces we could have a really nice open source CAD. But that's unlikely to ever happen.
As for layouts, I farm all those out so I did not try that part.
-- Regards, Joerg http://www.analogconsultants.com/
If this is the case, can't you just POST process the schematic file to replace the drawing frame elements with something suitable to your liking? Or, is the file not "structured"?
Yet another aspect of FOSS... :<
While there are only 3 (mainstream) *BSD's, how many Linux distros are out there? Has anyone ever CANDIDLY explained the (personality!) differences that led to their individual origins? :-/
No, the drawing frame isn't a part of the schematic file at all; how it's drawn is truly "hard-coded" into the program.
Yeah, but there's really only a small handful of application packages, e.g., *.deb and *.apt. The vast majority of Linux distributions will work with one of those two, so many of the various Linux distributions can really just be considered to be "theming" -- which apps come pre-installed, which GUI is used, the color/widgets scheme, etc.
Sure you could, same as other suggestions such as print to bitmap or PDF, strip the frame, add new frame, kludge in all the info. But that's clumsy and also not allowed in a controlled environment. The frame information must remain "married" to the very file. It is highly likely to result in an error if you wanted to re-load such a doctored file back into Kicad. Agency auditors would raise their hackles if they see stuff like that. Can't do it.
The issue is that the frame is embedded in the software code. That makes no sense at all and I have no idea why that was done. It's like if the resistor symbol was embedded without being able to switch between US and European notation.
The number of users I have encountered over the last decade who use Linux in an EE environment inside a business is ... zero. Apple OS'es ... zero. Windows OS'es ... 100%. At home it's different, there I've met a few (very few) who use Linux at home. And one whose girfriend used the Mac OS.
Whether we like it or not, those are the facts. I'd even venture to predict that gEDA will never come into widespread use because the movers and shakers seem to be rather Windows-hostile.
[...]-- Regards, Joerg http://www.analogconsultants.com/
Spoken like a non-user of Linux. The Linux culture is absolutely batscat about dynamic linking, which is its weakest point IMO--perfectly good programs die of bit rot due to incompatible changes in some library you never knew existed. Statically-linked executables last more or less forever--my favourite Linux editor was compiled in 1998--but there are a lot of weird incompatibilities between distros.
Cheers
Phil Hobbs Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203 Briarcliff Manor NY 10510 845-480-2058hobbs at electrooptical dot net
For Linux on the desktop [Lotd], it's certainly low, but you really should get to know more IC designers (that's the most common example I know of where you find EE with Lotd). You certainly know Phil Hobbs, right?
A very large percentage of EEs today likely use servers at their companies that are running Linux; both here and at my PPOE this was true.
True, there isn't much in the way of EE software on Macs. You'll definitely find Macs in technology companies, though -- they're plenty popular for graphics and industrial design these days.
Apple is gaining market share these days, which is significant. See, e.g.,
Also here and at my PPOE the CEOs used iPhones.
So Apple very much has their foot in the door, even if you won't be likely to find a Mac on a EE's desk very often.
I agree with you that effectively 100% of EEs do use Windows somewhere at work... but AFAICT there's a growing percentage of them that make use of some alternative OS as well. These days PCs themselves are dirt cheap and operating systems are all quite capable; it's often just the choice of, e.g., spendy CAD software that determines which OS you install.
---Joel
Well, at least one, namely yours truly. Eagle and LTSpice, both under CentOS 6.2.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
I'm a lazy Linux user: I use Ubuntu. :-)
Uggh. Well, these days disk space is so cheap I guess the best solution would be to encourage static linking!
I couldn't agree more. All the software I deliver is linked statically so its just click & play. No need for endless installers or updating libraries.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
One of my customers uses Geda and PCB (stupid name for a PCB layout program if you ask me..) to make rather complicated stuff. Linux only. For FPGA work I already switched to Linux and I also do a lot of programming work on Linux.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
Um, no?
There's a definitely tradeoff there, with regards to security.
If somebody finds an exploitable security loophole in a commonly used library (and this isn't uncommon on Linux, Windows, *BSD, MacOS, etc), and a fix is produced, then...
- Systems which have apps linked dynamically with this library, can be secured by simply downloading and installing the updated version of the dynamic library.
- Systems whcih have apps linked statically with this library, must download re-linked versions of all of the applications involved. The latter is a much larger burden on both the "build software" and "distribute software" infrastructures.
What I've observed in the Linux distribution I use most frequently (Debian) is that non-backwards-compatible changes to a shared-library API are almost always accomplished by generating a new and different library and package name. Apps linked against the older version of the library continue to use that one; apps linked against the newer, incompatible version end up requiring the newer library. I've seen as many as three different versions of a library present on my system at once, depending on when app packages change (I run the "testing" distribution, which updates things fairly frequently but not all at once).
--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Huh? So, any changes made to it apply to each *rendered* schematic page (i.e., print the sheet today and it looks one way; upgrade software and print it tomorrow and it's *different*? AND, you can never get back to the original form??)
The drawing should encode whatever is needed to recreate it AT IT'S CURRENT REV LEVEL. If I make no change to a schematic BUT UPDATE THE SOFTWARE, I should still be able to get the same document out of it. Without worrying that fonts are suddenly too large to fit between signal traces, etc.
(seems like a really silly "optimization" to have made!)
I assume you mean "package management SYSTEMS"? (not "applications" themselves)
I was under the impression that file system layout wasn't cast in stone between distros, etc. I.e., some could hide mail under /usr/spool while others opt for /var/spool, etc. (as well as which mail service is installed, yadda yadda...)
Regardless, it sure seems like a silly reason to split development/maintenance efforts! (at least the BSD camps had philosophically different goals to rationalize their differences!)
One of the problems with static linking is that an OS can't "economize" on a "shared library" to reduce the VM footprint. As libraries have grown far beyond the "nominal" standard libraries, this can become a real PITA.
It also means you can't upgrade the library as a component without rebuilding the executable. Imagine having to rebuild
*every* executable on your system when a new libc or libm is released... :-(If you adopt the *convention* of naming your (dynamic/shared) libraries uniquely (e.g., libc_2.1, libc_2.2, etc.) then you can regain some of these capabilities.
E.g., link "libc" to "whatever the -CURRENT version happens to be (so, anything that binds to *just* "libc" gets that library WHICH MIGHT CHANGE OVER TIME.
Anything that must be linked to a specific version can then either explicitly *name* the version that they are interested in
*or* put a symlink to that version in a place that the library load path will find and associate with the binary in question.
From comments elsewhere (in this thread), it looks like you can't even upgrade the software without risking the potential of (at least COSMETIC) changes to the document -- e.g., if the "hard-coded" material is altered in any way (an unavailable font is replaced with some other, etc.)
Agreed. The document is what you are controlling. Not the (document, tool) pair (the tool is controlled separately). One wonders what other things are not represented in the document... and, who got to decide *why*!
Blech. Good luck to anyone trying to rule the world (or even my bank account) by hacking a text editor. Static linking for me.
My electromagnetic simulator code uses FFTW v2, which has disappeared from sight in recent distros, but since I maintain a copy of the FFTW2 source and link it statically, there's no worries. In 2012, the need for dynamic linking of most programs has passed.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
A statically linked executable doesn't need to drag in the entire library, just the parts it uses. And with terabyte HDDs, static linking is not a significant contributor to bloat--particularly not the kinds of programs that I use. I don't need a statically linked Firefox, but I do need my text editor and circuit simulator to keep working indefinitely.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.