Author Topic: Need testers for Eagle to KiCad ULP scripts  (Read 9855 times)

0 Members and 1 Guest are viewing this topic.

Offline lachlanA

  • Contributor
  • Posts: 12
Need testers for Eagle to KiCad ULP scripts
« on: March 29, 2015, 12:45:54 pm »
Hi,  I have a number of Eagle ULP's which convert Eagle 6.xx  SCH to KiCad SCH lib/mod's.
It's Alpha stage  at the moment,  and I have only testing it on Linux.
So need's some one who has windows version of Eagle version 6  to test it.
It's hosted on GitHub.

https://github.com/lachlanA/eagle-to-kicad


Lachlan
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #1 on: March 29, 2015, 12:56:04 pm »
I think KiCad is working on this on their side...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #2 on: March 29, 2015, 01:12:00 pm »
Be about a year I expect,  from talking to there developers, before they have it embedded in KiCad.
Until then your stuck with external tools, like this one, for SCH,  and lbr,  the nice thing about  this one, is dose Sub sheets and multi part gate's,  which most others don't do.
KiCad Eagle's PCB import is already done and I'm using that to PCB side.

Lachlan
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #3 on: March 29, 2015, 01:23:32 pm »
Ah, fair enough. I wasn't sure about the state on the schematic side. Perhaps I should have popped into #kicad to ask first ::)
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #4 on: March 29, 2015, 10:12:49 pm »
Yar the lib side of Eagle is a pain in the neck  |O ,  for KiCad,  as it's so easy to Make Conflicting part name's in Eagle with the Technologies (*) and package (?) options in the Lib editor, and it never check's !  :-//

PS:  I  see KiCad developers have announced a freeze for the next version !    So with luck will have a new stable version with the Push and Shove router !  :)

Lachlan
 
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #5 on: April 01, 2015, 01:00:06 pm »
CERN's roadmap got merged into KiCad one and it includes interoperability features, but those require a massive refactorization first, so it might take a year to become reality.

It's a shame great projects like KiCad are so massively underfunded, it could improve in an extreme way just if some small companies and big publicly funded science institutions invest a part of the money they spend on commercial EDA licenses. Seriously I consider they overprice products for buggy software that not improves yearly enough compared to the total cost.

Thanks a lot for your script, it's very useful!
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #6 on: April 21, 2015, 06:07:51 am »
KiCad needs some major rework on the Sch side,  and computer nerds  with the time and skill to manager a big project like this are
as rare as hen's teeth.   And those which do are most likely working 24/7 and pulling in big bugs some where else, with no time to even
sleep.   Let alone manage all the problems which go along with a project like KiCad.

If the scrip works for you on windows let me know,  as it meets my needs, but could do with some major clean up, and work on the eagle too KiCad lib section,
but I have had zero interest apart from you email, and I was waiting for some repose/bug reports before I posted it more widely in Eagle chat/sites groups.

Lachlan

 
« Last Edit: April 21, 2015, 06:11:36 am by lachlanA »
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #7 on: April 21, 2015, 06:45:25 pm »
KiCad needs some major rework on the Sch side,  and computer nerds  with the time and skill to manager a big project like this are
as rare as hen's teeth.   And those which do are most likely working 24/7 and pulling in big bugs some where else, with no time to even
sleep.   Let alone manage all the problems which go along with a project like KiCad.

If the scrip works for you on windows let me know,  as it meets my needs, but could do with some major clean up, and work on the eagle too KiCad lib section,
but I have had zero interest apart from you email, and I was waiting for some repose/bug reports before I posted it more widely in Eagle chat/sites groups.

Lachlan

 
That's why I hope KiCad goes the LibreOffice way, but with electronics companies, research labs (CERN is a great start) and education institutions instead.

"Eat your own dog food", that's what hardcore Linux developers say about doing a capable piece of software.

I would imagine something would happen like with LTSpice, but Open Source. Major contributors would get better reputation and a tool they can improve to their needs, they can reduce costs once the development is shared by a big enough community and support could be done in-house by properly trained people.

They say 500K USD investment would make it surpass Altium Designer. How much 20 seats of AD licenses cost to a company?  What would bebthe TCO if KiCad would provide these features? Training, documentation, support.
 

Offline geggi1

  • Contributor
  • Posts: 32
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #8 on: July 24, 2015, 11:02:52 am »
I have tested the script for converting lib, but the components in Kicad is presented in a scale that is about 10-15 times larger than the ones from the other librarys.
What am I doing wrong? :-//
 I have attatched a print screen and the converted LIB
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #9 on: September 08, 2015, 04:24:11 am »
I think there was a scaling change to eagle, so this one only scales correctly for version  6.xx  and 7.xx
I have update the script a bit,   and add example library from sparkfun, it's  a big lbr,   so give it a try and see if your results match
The link is   https://github.com/lachlanA/eagle-to-kicad-libs
There you can see the original eagle and the 2 Kicad lib/mod.
Here is also the latest build for kicad.. still alfar thou http://downloads.kicad-pcb.org/windows/    I assum your using windows.
Note: I don't get on this web site much, so best if you post any problem's your having to my github site.   https://github.com/lachlanA

Lachlan




« Last Edit: September 08, 2015, 09:48:54 am by lachlanA »
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #10 on: September 08, 2015, 05:51:06 pm »
What about making this in the KiCad side by using Python? Would be too difficult?

What do you think about ULP vs Python?
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #11 on: September 09, 2015, 05:37:13 am »
For eagle libs/lbr no need, as eagle freeware vertion will convert any size lib to kicad libs/mod and it runs on the mac/linux/windows
And as far as I understand there is no limit as to how you use the libs which come with eagle,
For extracting libs from sch/pcb eagle, thing are much harder, if your lbr is  pree 6.xx as there are binary, so you need eagle to read them, and if you have not perchased the full verion of eagle, you have the  limits of the freeware version.  Of corse you can ask online
Who has the full version to do the covertion for you.   So python would be best option if were not for pree 6.00 files being binary

Lachlan
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #12 on: September 10, 2015, 09:28:38 am »
For eagle libs/lbr no need, as eagle freeware vertion will convert any size lib to kicad libs/mod and it runs on the mac/linux/windows
And as far as I understand there is no limit as to how you use the libs which come with eagle,
For extracting libs from sch/pcb eagle, thing are much harder, if your lbr is  pree 6.xx as there are binary, so you need eagle to read them, and if you have not perchased the full verion of eagle, you have the  limits of the freeware version.  Of corse you can ask online
Who has the full version to do the covertion for you.   So python would be best option if were not for pree 6.00 files being binary

Lachlan



What about this?

https://github.com/uid89626/Eagle



https://github.com/richard-clark/eaglepy
http://richard-h-clark.com/projects/eagle-python.html
http://richard-h-clark.com/projects/dxf-to-eagle.html

https://github.com/storborg/pyeagle


https://github.com/ghallsimpsons/pyEagle


https://github.com/alexer/pyeagle

https://github.com/upverter/schematic-file-converter

It seems there's code available to parse both binary and XML formats :D

It seems I didn't explained correctly. So you know how to program in both Python and ULP? What are the differences, advantages and disadvantages? Would you consider Python as a good scripting language for an EDA tool?




 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #13 on: September 10, 2015, 09:08:05 pm »
Have not tried any of the above program's.   if they work for you, that's all that matter's.  :)
As far as programming Lang go,   ULP is only from Eagle/Cadsoft.   And not a good Lang full stop...   no muit dimension arrays,  etc.. etc..
Python is much better Lang.   8)

Lachlan





 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #14 on: November 06, 2015, 06:22:36 pm »
Have not tried any of the above program's.   if they work for you, that's all that matter's.  :)
As far as programming Lang go,   ULP is only from Eagle/Cadsoft.   And not a good Lang full stop...   no muit dimension arrays,  etc.. etc..
Python is much better Lang.   8)

Lachlan

So why are you still making this script instead collaboring on native Eagle import-export support in KiCad? Maybe you have a reason, but I think depending on the Eagle software for the export to KiCad makes things painful.
 

Offline electrolust

  • Supporter
  • ****
  • Posts: 398
  • Country: us
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #15 on: November 19, 2015, 09:03:49 am »
They say 500K USD investment would make it surpass Altium Designer. How much 20 seats of AD licenses cost to a company?  What would bebthe TCO if KiCad would provide these features? Training, documentation, support.

Who says that?  Not a chance.   :-DD

500k would just about pay for a team to write proper documentation.  A good developer costs about 200-250k per year (after benefits, office space, CPUs, proper software tools, etc).  A great one is give or take double that.  This isn't the kind of software that can be written as a 1 man show.  So you also need a good PM.  Don't forget QA.  (Although Altium seems to have.)  And to actually git er dun, you need to have a single location where the team sees each other every day, not a loose band of remote code monkeys.

I'd say $10MM +/- $2MM, and 2 years.

Then, if you actually want something companies will use, it needs to have some kind of long term support.  Just being open source isn't enough, there has to be A TEAM to answer questions and be able to actually prioritize bugs that aren't interesting to developers that work only for fun.  Add another $10MM.

And since it will miss budget on cost and time, let's call it $30MM and 3 years.

Now let's say that at the Altium level you can sell a seat for $4000.  (Ultra cheap, for what it is.)  You need to sell 15,000 seats just to start.  I think there are easily that many seats out there, and easy pickings.

So once you have all that, why in the hell would you work on open source kicad?  You'd do better to protect your IP and churn out yet another proprietary EDA software.
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #16 on: November 19, 2015, 11:00:05 am »
They say 500K USD investment would make it surpass Altium Designer. How much 20 seats of AD licenses cost to a company?  What would bebthe TCO if KiCad would provide these features? Training, documentation, support.

Who says that?  Not a chance.   :-DD

500k would just about pay for a team to write proper documentation.  A good developer costs about 200-250k per year (after benefits, office space, CPUs, proper software tools, etc).  A great one is give or take double that.  This isn't the kind of software that can be written as a 1 man show.  So you also need a good PM.  Don't forget QA.  (Although Altium seems to have.)  And to actually git er dun, you need to have a single location where the team sees each other every day, not a loose band of remote code monkeys.

I'd say $10MM +/- $2MM, and 2 years.

Then, if you actually want something companies will use, it needs to have some kind of long term support.  Just being open source isn't enough, there has to be A TEAM to answer questions and be able to actually prioritize bugs that aren't interesting to developers that work only for fun.  Add another $10MM.

And since it will miss budget on cost and time, let's call it $30MM and 3 years.

Now let's say that at the Altium level you can sell a seat for $4000.  (Ultra cheap, for what it is.)  You need to sell 15,000 seats just to start.  I think there are easily that many seats out there, and easy pickings.

So once you have all that, why in the hell would you work on open source kicad?  You'd do better to protect your IP and churn out yet another proprietary EDA software.
What's wrong about remote code monkeys? Can't they be as efficient as local ones? What about the Linux project? They are a giant Open Source project with people collaborating worldwide and they are providing good results with a giant codebase.

I agree about Project Managers, I think a good project needs at least one or two of very experienced full time ones, probably maybe over per subsystem for big projects. I believe Open Source projects requires a lot more skilled and talented than most proprietary software.

I don't see the point of having a place with people working on them:
- No secrets: This doesn't need a super secret project place and security to avoid means, it's open after all.
- Less resources/money needed:
* You save lots of money by people working at home or even collaborating institutions in the case of CERN. You save the costs of buying or renting a place.
* You can save money by working on institutions with their workstations, but can also provide good and diverse hardware to the developers specially if requiring testing and compatibility.
- Compiling and automated testing: It could be done with one of these cloud services to have big iron for it.
- Documentation: It could be done by the programmers themselves if providing a good management and managers having a strong discipline about that. It could annoy developers until they get used to this different workflow and management, but newcomers would welcome to have a good documented codebase.

User documentation and didactical resources:
- I agree it needs a dedicated team and/or skilled collaborators that provide them updated and supervise translation. There can be volunteers too.

Protecting "Intellectual Property":
- There's crazy reverse engineers everywhere, you can make the effort more difficult but your product is going to be reverse engineered is there's enough interest. I also don't trust on proprietary software that requires Internet for license activation, like with Altium Designer.
- Most professionals and even researchers in the industry design their PCBs based on commercially available electronic components.
- I think the artificial " Intellectual Property " concept only benefits the big corps to make oligopolies. Ideas aren't a property but knowledge, they must be shared for the sake of progress. Anyway, I don't see a benefit tandake your own EDA unless you are Intel.
- By combining efforts and saving unneeded costs, you can make a more customizable tool that is even cheaper to maintain and use.
« Last Edit: November 19, 2015, 02:20:44 pm by timofonic »
 

Offline electrolust

  • Supporter
  • ****
  • Posts: 398
  • Country: us
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #17 on: November 19, 2015, 09:32:34 pm »
I'll leave the rest of your comments to stand.  I don't agree with all of them but it's all fair commentary.  This one however ...

- Documentation: It could be done by the programmers themselves

 :-DD :-DD :-DD

I take it you don't work in the software field.
 

Offline hendorog

  • Super Contributor
  • ***
  • Posts: 1420
  • Country: nz
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #18 on: November 19, 2015, 10:12:40 pm »
So you also need a good PM.

And since it will miss budget on cost and time...

Of course it will - because you put a PM in there. :-DD
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1245
  • Country: us
  • Yes, I do this for a living
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #19 on: November 19, 2015, 10:14:33 pm »
I'll leave the rest of your comments to stand.  I don't agree with all of them but it's all fair commentary.  This one however ...

- Documentation: It could be done by the programmers themselves

 :-DD :-DD :-DD

I take it you don't work in the software field.

He has zero professional experience in the software, hardware and other related fields. He's a kid.

-a
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1245
  • Country: us
  • Yes, I do this for a living
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #20 on: November 19, 2015, 10:29:06 pm »
I believe Open Source projects requires a lot more skilled and talented than most proprietary software.

On what basis do you make that assumption?

Do you realize that most proprietary software is not released to the general public, but rather is written for customers who have specific needs?

Quote
I don't see the point of having a place with people working on them:
- No secrets: This doesn't need a super secret project place and security to avoid means, it's open after all.
- Less resources/money needed:
* You save lots of money by people working at home or even collaborating institutions in the case of CERN. You save the costs of buying or renting a place.

Wait, read that again.  You don't see the point of having a place with people working on them, then you say, "you can save lots of money by people working at collaborating institutions in the case of CERN." And do you realize that operating CERN costs actual money (and lots of it)?

Now, certainly there are some projects which are worked on by programmers (and we're talking about programming here, right) working from home across the world. But in most people's professional experiences, you actually do get better results with people working in offices next to each other. There is a lot to be said for those hallway or break-room "conferences" which occur spontaneously.

Quote
* You can save money by working on institutions with their workstations, but can also provide good and diverse hardware to the developers specially if requiring testing and compatibility.

Who is this "you" who can save money? Those institutions pay for the workstations and for the people who sit at them, so one has to realize that time spent on the open-source program eats into time the employees spend on the mission of the organization (which, in most cases, is called "making money").

Quote
- Compiling and automated testing: It could be done with one of these cloud services to have big iron for it.

Who pays for this?

Quote
- Documentation: It could be done by the programmers themselves if providing a good management and managers having a strong discipline about that. It could annoy developers until they get used to this different workflow and management, but newcomers would welcome to have a good documented codebase.

How much working experience do you have, anyway?

Quote
I also don't trust on proprietary software that requires Internet for license activation, like with Altium Designer.

Funny, thousands of organizations and tens of thousands of users do trust it.

Quote
- Most professionals and even researchers in the industry design their PCBs based on commercially available electronic components.

And those components are the intellectual property of the manufacturer.

Quote
- I think the artificial " Intellectual Property " concept only benefits the big corps to make oligopolies. Ideas aren't a property but knowledge, they must be shared for the sake of progress.

BULLSHIT. If you want to be an open-source give-it-all-away coder, that's great (and I use a lot of open-source stuff). But when it comes to paying the mortgage and feeding the kid, you need income. So if I work for a company generating "intellectual property," and we want to keep the lights on and everyone paid, we aren't going to give away the secret sauce that makes the products valuable to customers.

Intellectual property really is the lifeblood of the electronics industry.

Quote
- By combining efforts and saving unneeded costs, you can make a more customizable tool that is even cheaper to maintain and use.


Please tell us which open-source (or other) projects you've worked on where you can point to specific cases where what you assert is true.
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #21 on: June 07, 2016, 01:38:32 am »
Back to topic:

 How's the project progressing?

What about merging it in KiCad itself?

Any hopes KiCad scripting gets improved to make it possible too?
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #22 on: June 07, 2016, 02:00:39 am »
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #23 on: June 13, 2016, 01:01:50 pm »
Back to topic:

 How's the project progressing?

What about merging it in KiCad itself?

Any hopes KiCad scripting gets improved to make it possible too?

Scripts are working ok,  for the most part.
There are problems with lib text in KiCad Pcbnew not getting the text rotation correct,  but that's a limit on How KiCad dose text on lib parts verse free text.
As far as direct import of sch/pcb/lib in KiCad I don't know if any one is working on it.
and it still would have the same limit, you could only do Eagle version 6+.

As far as scripting go's in KiCad, is sounds like a good idea,  but it's a nightmare,  as C++ and scripting Lang view of the world totally diffident.
I think the better option would be to put the sch/pcb/(used lib parts)  info in one file,  and change that file,  and signal the other application that a change have been made.
so they can update.(put in locks of course)   then scripting becomes easy, as you can do you own GUI, if needed, and you can use any scripting Lang you like.
All KiCad need to make is a external call the the script, with a pointer to the sch/pcb file etc.

Lachlan



 
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #24 on: June 14, 2016, 10:17:10 pm »
Back to topic:

 How's the project progressing?

What about merging it in KiCad itself?

Any hopes KiCad scripting gets improved to make it possible too?

Scripts are working ok,  for the most part.
There are problems with lib text in KiCad Pcbnew not getting the text rotation correct,  but that's a limit on How KiCad dose text on lib parts verse free text.
As far as direct import of sch/pcb/lib in KiCad I don't know if any one is working on it.
and it still would have the same limit, you could only do Eagle version 6+.

As far as scripting go's in KiCad, is sounds like a good idea,  but it's a nightmare,  as C++ and scripting Lang view of the world totally diffident.
I think the better option would be to put the sch/pcb/(used lib parts)  info in one file,  and change that file,  and signal the other application that a change have been made.
so they can update.(put in locks of course)   then scripting becomes easy, as you can do you own GUI, if needed, and you can use any scripting Lang you like.
All KiCad need to make is a external call the the script, with a pointer to the sch/pcb file etc.

Lachlan
Would be difficult to improve KiCad to not have these limitations?

What's so difficult for you in KiCad 's scripting? KiCad uses SWIG[/], so other scripting languages are possible other than Python too.

Your project it's great, thanks a lot. But maybe depending on Eagle could be a mountain rather than improve without the application.
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #25 on: June 15, 2016, 03:42:08 am »
Quote
Would be difficult to improve KiCad to not have these limitations?

What's so difficult for you in KiCad 's scripting? KiCad uses SWIG[/], so other scripting languages are possible other than Python too.

Your project it's great, thanks a lot. But maybe depending on Eagle could be a mountain rather than improve without the application.

The problem with scripting is for the most par it's a dynamic language where as for C++ is not.
which means..  managing access to variables is a nightmare.   Just getting this wright in C++ can be bad,  add threading into the mix,   and you have a nightmare of the first order.

The bigest problem in getting Eagle to KiCad conversion to be as simple as possible, came down to two problems.
wire's (sch)  don't retain net informative,   (IE you move the net label away from the wire, and the wire no longer belongs to that net)  where as Eagle it dose.
and in pcb has the same proble..  track's and via's don't retain netinformation if there are not connected to a pad.
I ask KiCad develpers about this,  and they was no intrest in fixing it, as it was a lot of work,  and there intrest's remain in other place's..   which is ok,  arfter all there giving there time
free why should they care about importing Eagle design's  or  other PCB package.
If you look at my nasty nasty hack to get around those 2 problems (and it's really nasty) it works.
But you would still be up for that same nasty hack if you wrote a import plugin for Eagle.
And given how nasty the hack is I very much doubt if the KiCad people would allow it into there code base.
Which mean's me forking KiCad,  which I don't have brain's or time to do.      So given that writing a plugin would not improve thing over the current ULP scrip, which has the down side you need to
install Eagle,  or have a friend do the conversion who has full version of eagle, if your design is too big for the free version.   I give the idea away.
I just don's see the KiCad Developers accepting such a nasty hack,  and they are not interested in change the two problems I had mentioned above, or maybe no even allowing those change's.

So I gave idea of wright a plugin away.

Lachlan


 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 370
  • Country: au
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #26 on: June 22, 2016, 02:11:42 am »
Quote
The bigest problem in getting Eagle to KiCad conversion to be as simple as possible, came down to two problems.
wire's (sch)  don't retain net informative,   (IE you move the net label away from the wire, and the wire no longer belongs to that net)  where as Eagle it dose.
and in pcb has the same proble..  track's and via's don't retain netinformation if there are not connected to a pad.

That's a reasonably common problem. Quite a few CAD packages started life as "polyline editors" with back-end processing...

Quote
I ask KiCad develpers about this,  and they was no intrest in fixing it, as it was a lot of work,  and there intrest's remain in other place's..   which is ok,  arfter all there giving there time
free why should they care about importing Eagle design's  or  other PCB package.
If you look at my nasty nasty hack to get around those 2 problems (and it's really nasty) it works.
But you would still be up for that same nasty hack if you wrote a import plugin for Eagle.
And given how nasty the hack is I very much doubt if the KiCad people would allow it into there code base.

I can see it is non-trivial to change the database, but you can use infrastructure that exists now, to help here.
ie in your case, if Eagle can create a NETIST, and you want to check the quality of the KiCad SCH, get kiCad to create a NETLIST too, and then compare connected-sets.

This simple process of NETLIST  Handover, lets users confirm & find subtle issues like line-overlap.
KiCad (& many others) also has a simple graphical tag for connected or not connected (small circle on terminal)

Once you have NETIST sign-off,  you have a reference design in kiCad, and can modify/change from there.

I can see the appeal of a Converter that is not locked to Eagle, as that opens up pathways from many other CAD packages.
Python seems a natural, as that comes with kiCad?
 

Offline lachlanA

  • Contributor
  • Posts: 12
Re: Need testers for Eagle to KiCad ULP scripts
« Reply #27 on: June 25, 2016, 09:54:22 am »
Quote
The bigest problem in getting Eagle to KiCad conversion to be as simple as possible, came down to two problems.
wire's (sch)  don't retain net informative,   (IE you move the net label away from the wire, and the wire no longer belongs to that net)  where as Eagle it dose.
and in pcb has the same proble..  track's and via's don't retain netinformation if there are not connected to a pad.

That's a reasonably common problem. Quite a few CAD packages started life as "polyline editors" with back-end processing...

Quote
I ask KiCad develpers about this,  and they was no intrest in fixing it, as it was a lot of work,  and there intrest's remain in other place's..   which is ok,  arfter all there giving there time
free why should they care about importing Eagle design's  or  other PCB package.
If you look at my nasty nasty hack to get around those 2 problems (and it's really nasty) it works.
But you would still be up for that same nasty hack if you wrote a import plugin for Eagle.
And given how nasty the hack is I very much doubt if the KiCad people would allow it into there code base.

I can see it is non-trivial to change the database, but you can use infrastructure that exists now, to help here.
ie in your case, if Eagle can create a NETIST, and you want to check the quality of the KiCad SCH, get kiCad to create a NETLIST too, and then compare connected-sets.

This simple process of NETLIST  Handover, lets users confirm & find subtle issues like line-overlap.
KiCad (& many others) also has a simple graphical tag for connected or not connected (small circle on terminal)

Once you have NETIST sign-off,  you have a reference design in kiCad, and can modify/change from there.

I can see the appeal of a Converter that is not locked to Eagle, as that opens up pathways from many other CAD packages.
Python seems a natural, as that comes with kiCad?

I think a example will show up the problem,
The unconnected track problem:
  In Eagle unconnected tracks retain net information,  which is good,   as when you have flood fill's   the unconnected tracks get merged correctly with the unconnected track, if there are the same net.
  while in KiCad this is not the case,  now on a simple board with no food fill's..   no problems,   but take a complex board,  with many layers, and many flood fill's  your in for a really bad time fixing up all the unconnected tracks.
  The only way I handled this was to report all unconnected tracks on 2 eagle layers,  as there is no way to add tracks/via's using python or C++.. etc
  So unconnected tracks are not fixable in any way you can trust by programing.   Where if the change  KiCad to retain net info on tracks  the hole night mare vanishes
  Doing the conversion in a eagle ULP as I do,   or  python or C++ on KiCad make's no diffidence.  you still hit the same brick wall.  |O
  That's why you can't trust the conversion script with unconnected tracks or unconnected Via's (thou I have a nasty hack which converts via's to pad, but it only works in none blind via's, and it has to change the sch file to keep consistent net list from sch to pcb )
 So at the end of the day,  why go to all the trouble for no gain, excepted to use KiCad only and not eagle,  which also has the downside you can't convert any pre 6 version's of eagle sch/pcb/libs ?  So you still need Eagle in those case's
 Sorry, but I can't see it's worth the effort,  It would be much better use of my time fixing the root problem in KiCad,   but as I said,  I don't think it would be accepted,  form the feed back I have received.

Lachlan



 


   
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf