For example we use DIP-20 in protel99se but in proteus it's DIL20....
Has some way to solve this problem?
How to export a netlist for protel99se?
How to export a netlist for protel99se?
I compiled netlist in tango format,but I found it can't be imported in protel99se correctly,because most package names are different!
For example we use DIP-20 in protel99se but in proteus it's DIL20....
Has some way to solve this problem?
For example we use DIP-20 in protel99se but in proteus it's DIL20....
Has some way to solve this problem?
Unfortunately not.
There is no standard between CAD Vendors on naming conventions for PCB footprints. This does mean, as you say, that you must tell the receiving software which footprint to use. This can either be done by opening up the netlist file and replacing the package names with ones used in the receiving software or, dependant on the software, can be done at the point of import.
We are hopeful that the introduction of the IPC-7351 standard (which includes naming terminology) will be adopted generally by CAD vendors and that this problem will then go away.
It is likely that Proteus V7 will implement this standard.
Iain.
There is no standard between CAD Vendors on naming conventions for PCB footprints. This does mean, as you say, that you must tell the receiving software which footprint to use. This can either be done by opening up the netlist file and replacing the package names with ones used in the receiving software or, dependant on the software, can be done at the point of import.
We are hopeful that the introduction of the IPC-7351 standard (which includes naming terminology) will be adopted generally by CAD vendors and that this problem will then go away.
It is likely that Proteus V7 will implement this standard.
Iain.
Another approach is to use ASCII Data Import in ISIS to build a translation table for the packages you use.
You can then apply this to any ISIS schematic prior to netlist generation and the netlist will contain the translated packages.
The script would look something like this:
DATA PACKAGE : PACKAGE
DIL20 : "DIP-20"
...
END
John.
You can then apply this to any ISIS schematic prior to netlist generation and the netlist will contain the translated packages.
The script would look something like this:
DATA PACKAGE : PACKAGE
DIL20 : "DIP-20"
...
END
John.
Haha,that's maybe the only way by now,I think it's not a very hard work for labcenter to establish this process,as it's very important to our customers.JohnJ wrote:Another approach is to use ASCII Data Import in ISIS to build a translation table for the packages you use.
You can then apply this to any ISIS schematic prior to netlist generation and the netlist will contain the translated packages.
The script would look something like this:
DATA PACKAGE : PACKAGE
DIL20 : "DIP-20"
...
END
John.
-
Zvonimir Rudomino
- Professional User
- Posts: 37
- Joined: Thu 2006-03-09 23:04
Doing all the parts in libraries would be anything but trivial. And what happens when Protel/Altium decide to make changes to their libraries? Nightmare!
Fortunately, the industry is moving towards IPC 7351, in which there is a common standard for package names. We certainly hope to adopt this standard for Proteus, and - assuming other vendors do the same - this will mean that the whole issue of package names being different in different tools should go away.
This, of itself, is reason enough for us not to devote precious development time to creating and maintaining large translation tables. In particular, there is the thought that just when we've made a table for Protel 99SE or whatever, they issue new IPC7351 compliant libraries with totally different names and render the whole effort worthless.
Also, most of our users use ARES, and of those that don't, it will be divided between Protel, Orcad, Eagle and others. So the cost benefit analysis of the feature doesn't look good either.
Meanwhile, for a given customer to create a small ADI script for the packages they use it is a probably ten minute job. And for a second or subsequent design, you'd probably only be adding a few more packages to your script.
John
Fortunately, the industry is moving towards IPC 7351, in which there is a common standard for package names. We certainly hope to adopt this standard for Proteus, and - assuming other vendors do the same - this will mean that the whole issue of package names being different in different tools should go away.
This, of itself, is reason enough for us not to devote precious development time to creating and maintaining large translation tables. In particular, there is the thought that just when we've made a table for Protel 99SE or whatever, they issue new IPC7351 compliant libraries with totally different names and render the whole effort worthless.
Also, most of our users use ARES, and of those that don't, it will be divided between Protel, Orcad, Eagle and others. So the cost benefit analysis of the feature doesn't look good either.
Meanwhile, for a given customer to create a small ADI script for the packages they use it is a probably ten minute job. And for a second or subsequent design, you'd probably only be adding a few more packages to your script.
John