Further would be nice. The issue is that there are many CAD programs
out there, with closed file formats. The only thing they all have in
common is that they produce gerber format. So, any type of importing
of gerber we can do, helps migrate people away from closed formats and
to open source, as well as recover "lost" designs. The closer we can
get to "human generated" quality, the better. Of course, something is
better than nothing, too.
Gerber importing is such a tempting project for me, particularly because it would be great to migrate the works of a robotics group that I am involved in over to gEDA. Our kind of collaborative work just cries out for a completely free tool that can be used by everyone.
IMHO the core of the "drc improvement" should consist of two parts:
First, improving the things we check for and how we locate (meaning
X,Y position) the failures, and second, storing the results in an
internal data structure that we can use to inform the user of the
failures.
Once we have the failures, it's up to the GUIs to choose how to
present that information to the user, either as a separate dialog, or
as layers. We could even have a printed report, for example.
I'm pretty unclear about two aspects of this:
1) The way DRC currently works in PCB. I didn't find a c file detailing any DRC related functions, for example, except possibly line.c.
2) To what extent the issue of graphically representing the errors should fall to the GUI.
Hang on, I'll just look at one of your later points and include a screenshot to help discuss both of them:
>1. The "non-copper layers" one. Basically, each layer needs to have a
type and position associated with it, so you can say "this layer is
a paste keep-out for the top" etc. This change is a prerequisite
to a number of other enhancements we're hoping to get to.
Are you familiar with Eagle at all? I've included a screenshot of Eagle with showing it's representation of both keepout layers and DRC violations.
To understand the screenshot:
* The top layer (prefixed by t in related layers) is red filled.
The top layer's keepout/restrict layers are polygons with red dots.
The top layer's DRC violations are polygons filled with red lines.
The bottom layer (prefixed by b) is blue, and the keepout and DRC polygons follow the above, but in blue.
The via layer is green
The via restrict layer has polygons with green lines.
Note that the round turquoise polygon is "bottom restrict" and "via restrict" overlaid on each other.
So Eagle has a keepout layer for each layer, and also apparently a DRC layer for each layer though these cannot be selected or controlled.
So for a third point I'm still unclear on:
3) Layers in PCB. I understand there work going on to change the way layers are handled, for example to allow using more than 8 layers. Will this effect coding these layer based solutions?
I've often suggested that gsch2pcb should create a *script* for pcb,
which does all the things that need to be done. It would mean adding
more actions to pcb, specific to this purpose.
Could you elaborate on "script" please? Are you referring to the idea that gsch2pcb will be executing a series of pcb commands, rather than running the code itself.
> Perhaps this same API could be used to create a program for
> automatic/controlled replacing/updating of PCB elements.
Yup. The element attribute table could keep track of the origin
(file-wise) of each footprint, and perhaps a hash signature or
timestamp.
What's the element attribute table? Does this already exist?
It strikes me that if gsch2pcb is communicating with PCB to perform it's task, two-way communication through D-BUS might make sense. Gsch2pcb could essentially become a full conduit between gschem and PCB. What do you think?
2. Keeping track of which nets each object on the board (trace, pin,
polygon, etc) belongs to. Currently, we have to calculate
connectivity the hard way - by checking for overlaps. This has
many drawbacks. What we should do is have every object have a
"netlist pointer" or something, so comparing pointers is all you
have to do to see if two things should be connected or not.
