I'm moving to KiCad

[Anonymous]

http://kicad.sourceforge.net/wiki/Main_Page

I'm a long time Eagle fan but I just looked at the prices for the
latest version and they're just outrageous! The standard version now
costs $820 for a single-user licesne and a size limitation of 160 x
100mm.

Kicad is free, open-source, and runs on multiple platforms, including
Windows, Mac and Linux. It has no limitations of any kind and it's
continuously being updated. It's also relatively easy to use, although
not as easy as Eagle.

But since Kicad has a long term future I see it overtaking Eagle within
a couple of years.

 

[Don Y]

http://kicad.sourceforge.net/wiki/Main_Page

I'm a long time Eagle fan but I just looked at the prices for the
latest version and they're just outrageous! The standard version now
costs $820 for a single-user licesne and a size limitation of 160 x
100mm.

Of course, *you* have to decide what's expensive/outrageous for *you*.
How many hours are you likely to spend learning/troubleshooting/and
supporting <whatever>? What is your time worth?

Schematic and PCB tools are notoriously expensive. That's a
consequence of the market. Users who have bean counters to put
dollar figures on their time can more easily rationalize an
expense than "hobbyists". small-shops, etc.

What do you plan on doing when you stumble across a bug? Post
a message on a forum and *hope* that someone with the skills
to fix it considers it important enough to address *now*?
(How long can you hold up releasing artwork while you wait for
a fix? How sure will you be that it is tested thoroughly?)

[Of course the same is true of COTS software -- but, there, you
have the leverage of having put your money on the table and
suggesting that you might, later, take it *off* the table!]

How are you planning to support the Kicad effort? $500 cash
donation (if $820 is too much for Eagle, maybe $500 is more
appropriate)? Will you be submitting *patches* to the
code base? Or, just expecting a free ride?? :-/

Kicad is free, open-source, and runs on multiple platforms, including
Windows, Mac and Linux. It has no limitations of any kind and it's
continuously being updated. It's also relatively easy to use, although
not as easy as Eagle.

But since Kicad has a long term future I see it overtaking Eagle within
a couple of years.

How do you come to the conclusion that "Kicad has a long term future"?
Have you never encountered ABANDONED open source projects? (I have
a few TB of these archived, here :> ) Have you never encountered
FOSS projects that had different priorities than yours?

For example, I'm currently looking to interest the PostgreSQL (FOSS
RDBMS) folks in supporting databases on read-only media. Of course,
*they* think that's "silly" -- since they think in terms of corporate
servers, disk drives, full-time DBA's, etc. Yet, I'm sure most
of them have telephone books at home. And routinely rely on
Google (which is read-only -- from *your* perspective!). Of
course, they also don't consider the consequences of deploying
a DBMS on a handheld device ("Ooops! Just dropped my WhatzIt2000!
There goes the disk drive... :< ")

*My* solution is to fork the -CURRENT branch, fund the development
of that set of features and "take ownership" of the resulting
code base (i.e., mine to support until others decide R/O
databases are a cool idea!)

Caveat Emptor. Often you truly *do* "get what you pay for"! :<

 

[Jamie M]

http://kicad.sourceforge.net/wiki/Main_Page

I'm a long time Eagle fan but I just looked at the prices for the
latest version and they're just outrageous! The standard version now
costs $820 for a single-user licesne and a size limitation of 160 x
100mm.

Kicad is free, open-source, and runs on multiple platforms, including
Windows, Mac and Linux. It has no limitations of any kind and it's
continuously being updated. It's also relatively easy to use, although
not as easy as Eagle.

But since Kicad has a long term future I see it overtaking Eagle within
a couple of years.

Hi,

The new version 6 of eagle has XML formats for the schematic/board
/library files which is really good as it might help with import/export
from kicad etc.

cheers,
Jamie

 

[Frank Buss]

How do you come to the conclusion that "Kicad has a long term future"?
Have you never encountered ABANDONED open source projects? (I have
a few TB of these archived, here :> ) Have you never encountered
FOSS projects that had different priorities than yours?

There is a good example in KiCad regarding different priorities: I've
created a patch for an obvious problem, which is ignored for the
official distribution since 1.5 years and still not included:

https://bugs.launchpad.net/kicad/+bug/636830

*My* solution is to fork the -CURRENT branch, fund the development
of that set of features and "take ownership" of the resulting
code base (i.e., mine to support until others decide R/O
databases are a cool idea!)

It is a lot of work to keep it synchronized with the original source, if
you want both, new features from the original project and your patches,
even more so if you are not a programmer.

Caveat Emptor. Often you truly *do* "get what you pay for"! :<

Right, and with open source software at least it is possible to change
it for money. It is impossible to convince Farnell to change something
for you in Eagle, if they don't like it, no matter how much (reasonable)
you are paying for it.

 

[Don Y]

Hi Frank,

There is a good example in KiCad regarding different priorities: I've
created a patch for an obvious problem, which is ignored for the
official distribution since 1.5 years and still not included:

https://bugs.launchpad.net/kicad/+bug/636830

Yup. FOSS groups aren't without "personalities" :>

It is a lot of work to keep it synchronized with the original source, if
you want both, new features from the original project and your patches,
even more so if you are not a programmer.

Correct. In my case, I am waiting until -CURRENT has as many
features (and stability) as I can get. Then, deal with the fork.
If I'm lucky, others may have requested similar features and
-CURRENT may have some groundwork in place. If not, then I've
a big hill to climb!

But, once implemented, others may find similar use for that
set of features and pressure the changes to be formally
maintained/merged. If not, I still end up with "what I want"
(though no forward going support)

Right, and with open source software at least it is possible to change
it for money. It is impossible to convince Farnell to change something
for you in Eagle, if they don't like it, no matter how much (reasonable)
you are paying for it.

Yup. I left the MS world for exactly that reason:

"Yes, that code sample clearly illustrates a bug. A particularly
*nasty* bug, too! Unfortunately, we are no longer supporting
version X of that product. *But*, we can give you a free upgrade
to version Y's set of bugs -- which appear not to include the
bug you've noticed in version X..."

OTOH, if they (MS, Farnell, etc.) lose customers because of
policy decisions like this, then The Market will, eventually,
"fix" the problem (as it seems to have done with so many
other EDA vendors! :> )

 

[Joerg]

There is a good example in KiCad regarding different priorities: I've
created a patch for an obvious problem, which is ignored for the
official distribution since 1.5 years and still not included:

https://bugs.launchpad.net/kicad/+bug/636830

And until that is fixed Kicad will never make it big in the corporate
world. Just like Eagle won't until they finally understand how important
a schematic hierarchy is and make it happen.

[...]

 

[Joerg]

The significantly-non-standard user interface is an awfully tough sell
as well there, Joerg.

That one would be easy to fix. I got used to it pretty quickly, within
less than an hour. The library editor was a whole 'nother story though.

My feel is that something way down in the software architecture is not
allowing a hierarchy. They threw it out the window for two major
releases now and they cannot be blind to the fact that this costs them
serious business. Some engineers like myself won't pay for upgrades
unless it happens, but most of all lots of companies wave off when they
see that deficiency. Tons of money was left on the table over the years.

It's sad, this software is next to perfect except for that (huge)
deficiency of a missing hierarchy.

 

[Don Y]

Hi Joel,

Indeed I have.

I'm actually surprised that while there have been some attempts at
operating forums for PADS users, they never seem to attract much traffic.

If there is such a need, one would think this sort of thing
would spontaneously appear and be an instant hit -- whether
USENET alt. hierarchy, yahoo/google group or a private site...

The price of a software product seems to have little to do with how well
it's supported, though -- I've had several "critical" bugs (meaning that
they crash the product when hit, and are pretty easy to come upon)
listed with Ansys (HFSS, Designer, etc.) for months now and they haven't
bothered to fix them.

I'll agree that the correlation isn't very strong. I've had excellent
support on some ~$1000 compilers (meaning overnight patches!) as well
as many bits of freeware and FOSS (though being an active participant
in some of those domains might have skewed my results).

When I purchased my first "3D modeling" add-on to AutoCAD (decades
ago -- to the tune of $3K) it took me only a few days to stumble on
a critical flaw in the math library (I was perforating a model of
piece of sheet metal with finely spaced "vent holes" -- which
quickly turned into a Dali-esque shape bearing no relation to the
step-and-repeat tools I used to create the "array"). They provided
a patch within days (back then, that meant fedex'ing a stack of
floppies).

[Of course, I suspect it would only have been a matter of a few
*more* days for other customers to stumble upon similar limitations
in the product. "How many t's in 'testing'??"]

My own theory is that many of these big "enterprise" level software
packages that have been around for so long now and have so much crap
code upon crap code that they've become largely impossible to maintain
-- fixing one thing breaks something else.

I think that is especially true in the EDA market. A gets bought
out by B... who mangles A's product "enough" to make it (sortof)
work with B's other products... then B gets bought out by C
(who similarly mangles the A product as well as the B products)...
etc.

Add to that normal personnel changes and general bit rot...

If you combine that with
management that doesn't have a technical background, the software
package is pretty much screwed. Yet, the companies survive because they
live off of maintenance contracts, since their customers have many
man-years invested in libraries, and of course very few of these
packages let you easily export the libraries into any sort of "open"
format.

I doubt that an open symbol/footprint/attribute format will
ever work -- with multiple uncooperating vendors. There's
too much variability in how people build symbols/footprints,
name attributes, etc. Signal spacing/grouping on schematics
varies, different grid pitches, etc.

What is needed is a way to *import* libraries and an entirely
separate mechanism mechanism for creating them. Get the
vendors out of the symbol/footprint business entirely. (No
more "symbol editors", "footprint editors", etc.)

"We've got *our* library organized to *our* corporate standards.
All we need to do is squirt it *into* your tool kit. And, if
we get tired/disappointed with your toolkit, we won't have to
'extract' it -- we'll just squirt it into whatever *other*
toolkit we end up buying!"

E.g., build parts as SGML documents and let a parser reify
them in the tool.

 

[Bill Martin]

Hi Joel,

I doubt that an open symbol/footprint/attribute format will
ever work -- with multiple uncooperating vendors. There's
too much variability in how people build symbols/footprints,
name attributes, etc. Signal spacing/grouping on schematics
varies, different grid pitches, etc.

What is needed is a way to *import* libraries and an entirely
separate mechanism mechanism for creating them. Get the
vendors out of the symbol/footprint business entirely. (No
more "symbol editors", "footprint editors", etc.)

"We've got *our* library organized to *our* corporate standards.
All we need to do is squirt it *into* your tool kit. And, if
we get tired/disappointed with your toolkit, we won't have to
'extract' it -- we'll just squirt it into whatever *other*
toolkit we end up buying!"

E.g., build parts as SGML documents and let a parser reify
them in the tool.

Interesting that CadSoft has sort of gone in this direction with
the 6.xx version of Eagle. Most if not everything is now an XML
document file, including library parts. Just recently found this
very useful, some cut & paste editing of an XML doc and presto, I
have a new part defined. Somehow I could not convince the library
editor to connect up the symbol & footprint for me...maybe someday
I will learn how. But having the data "accessible" in XML was a saving
factor for now.

Bill

 

[Bill Martin]

Hi Bill,



This is *excellent*!


Exactly. Once the structure of the document is made clear to
you (hopefully *formally*), you are free to mangle it with
whatever tools fit your skills/goals. And, the DTD should
catch any obvious screwups you make in violating the
document's structure.

<<<SNIP>>>
Hi Don,
Something you might find intriguing: " Fritzing - from prototype to
product "
www.fritzing.org

This seems to be another attempt at creating a truly open pcb cad
system, also using XML for the nitty-gritty details of description. It
looks to be in it's infancy just now, but it has some good things about
it. Uses Qt for the UI, good because it's a known, stable animal
already. Uses XML for parts and layout, can generate SVG & Gerber
output. I played with it a tiny bit & it was "easy" to get used to,
compared to any other cad I have seen...not that I'm an expert, just the
opposite.

Bill

 

[Don Y]

Hi Bill,

Something you might find intriguing: " Fritzing - from prototype to
product "
www.fritzing.org

This seems to be another attempt at creating a truly open pcb cad
system, also using XML for the nitty-gritty details of description. It

I'll take a peek at it. I'd be particularly interested in what the
DTD/XSL looks like to support "device equivalences/gate swapping"
and how they map devices to packages.

looks to be in it's infancy just now, but it has some good things about
it. Uses Qt for the UI, good because it's a known, stable animal
already. Uses XML for parts and layout, can generate SVG & Gerber
output. I played with it a tiny bit & it was "easy" to get used to,
compared to any other cad I have seen...not that I'm an expert, just the
opposite.

<frown> I fear the emphasis on "interactive" and "arduino" means
it's just a thinly veiled attempt to sell "modules" and "fab
srvices"... we'll see.

Thanks!