I’d like to use a tool (VeroRoute) that can only import netlists in Protel 1 / Tango format. Looking at an example netlist in its distribution, it’s not a complicated format, but it’s different from all the ones KiCad can produce. Apparently gEDA can export to that format, but I’m not familiar with gEDA.
Can anybody recommend a conversion tool, a script, or a way to use gEDA to convert a KiCad schematic into that particular netlist format?
quick google search turned this:
http://wiki.geda-project.org/geda:gnetlist_ug:netlist_backends
http://manpages.ubuntu.com/manpages/bionic/man1/gnetlist.1.html
not an expert by any means.
Right, gnetlist seems to be the right tool for the job. But how do I feed it a KiCad schematic?
If I read those gEDA Resources correctly gEDA appears to be directly compantible with KiCad.
The tool a bit down the page mentioned altium2kicad tool should do the trick.
Apparently they (http://repo.hu/projects/pcb-rnd/) have what you need (KiCAD -> Protel), I have never use it (but they are a fork of gEDA)
I’m the developer of VeroRoute. I am planning to add support for other netlists. I see that KiCAD can export a netlist in Orcad format and an aiming to introduce support for that.
Note that regardless of format, you will not be able to import if the format contains unknown footprint/package names.
So even if you go the pcb-md conversion route, you have to follow certain conventions on those names. Read the document “Using TinyCAD with VeroRoute” on
https://sourceforge.net/projects/veroroute/files/
as it defines the expected footprint names.
Also look here. This is the email chain from when someone first asked for gEDA support. I list all the footprint names I had in the tool.
https://sourceforge.net/p/veroroute/discussion/general/thread/b6b69439/
Since then it is now possible to define your own components in VeroRoute along with the footprint name to be used during netlist import, but you cannot alter the default footprint names in the tool. I am working on making the netlist import more flexible so if it encounters an unknown footprint name, it will list known footprint types in VeroRoute and ask how to treat the unknown footprint.
VeroRoute will be able to import netlists in Orcad2 format in the next release.
Probably within a week. So you will be able to export a KiCAD netlist in that format and import to VeroRoute.
I’ve done some simple tests and it seems to works OK.
You have to set correct footprint names on your parts in KiCAD so VeroRoute understands them. I don’t have time to provider a parts library. The main thing to watch out for is pin numbering on transistors. I have labelled pins on the transistor packages in VeroRoute following whatever info I could find in the JEDEC standards. So hopefully it will be OK.
It does not really make sense to talk about “a transistor” on the footprint side. The footprint will be of the TO-92 package. That packages lead numbering is defined by JEDEC. JEDEC does not define which of these leads will map to what function (so it does not say “lead one is gate”).
In fact you will be able to find a product for any of the 6 possible mappings. This is why kicad has 6 generic symbols to map to the standardized packages as required. (We also include a number of fully specified symbols where the symbol is valid for one part and has the footprint already mapped in the library.)
Meaning if you really meant to say “transistor” and not “package typically used for transistors” then you will need all 6 possible mappings on the footprint side. (Especially if you somehow indicate on the footprint which pad will have which function. For example by including a transistor symbol on some documentation layer connected to the leads. Or by having letters indicating the lead function near them.)
You will never be able to provide a library for all parts. There are just too many out there. I would assume your tool comes with a library editor such that users can make their own ones if theirs is missing. In which case adding a new part should really be considered as one of the first skills to learn.
Yes, to clarify what I meant, I was trying to say that the transistor packages in VeroRoute (TO92,TO220,etc) follow the JEDEC pin numbering. I know E,B,C map to the pin numbers 1,2,3 in a part-specific way.
I have seen at least one schematic editor (I cannot recall which one) where the pin numbers on all transistors were reversed. For example, they had a 2N3904 in TO92 package with the emitter labelled as pin 3, when in fact it should be pin 1. I assume the person who created the symbols didn’t read the datasheets for the parts.
You can create you own library of custom parts in VeroRoute, but I dont want to force a user to have to do that just to get a netlist imported. So during import, I will list all problematic (unknown) footprint names in a dialog, and give the user the option of assigning each one to a known footprint type.
Lol. I wonder if they numbered the pins alphabetically…
This IMHO is one of the big failings of Fritzing. Creating custom parts was complicated and needed to be done with an external tool and then hand managed. I so wanted to really like Fritzing for the schematic to breadboard functionality, but the steep learning curve to create parts that I wanted to use but weren’t in the library turned me off.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
