kicad-developers team mailing list archive
Mailing list archive
Re: Re: saving zone edges in pcb file
Dick Hollenbeck <dick@...>
Thu, 01 Nov 2007 08:45:33 -0500
Thunderbird 184.108.40.206pre (X11/20071023)
I'll try to work on this topic.
A first enhancement (out of this topic, but desirable) could be consider
zones in ratsnest calculation.
Of course saving edges zone is easy but creates a lot of problems which
must be solved
1 - trivial, but easy: edges must be editable (only a lot of work and
2 - must we save zone parameters (net name, zone clearance, grid ... )
with the zone or use the current zone parameters (which can differ from
3 - How to handle safely the net name of the zone:
An usual case is a ground zone. But many components use GND as
ground name, and many others useVDD.
So, in a schematic including components using GND and VCC, the same
net can have the net name GND or VDD.
Therefore, if a zone initially created with GND as net name must be
and at this time (after some schematic changes) the same net is now
called VDD, what we must do ?
4 - And at last but not at least :
Often, on the same layer a board can have more than one zone. This
What is a edge zone ? Suppose you create 2 zones (for instance a Digital
GND, and an Analog GND) not overlapped.
Later, you move a frontier and now a zone overlaps the other zone.
What refilling must do: fill the new area and overlaps the other zone,
or stops at the frontier of this other zone.
Same problem when creating a new zone overlapping an old one, relative
to the same net : Is the frontier of the first zone is a frontier for
the new one ?
And what we do when refilling zones if a zone was previously deleted and
its edges are kept.
We must have some thoughts about this problems and also about what we want.
I ran into a problem with track bounded zones, so the urgency is back
up. Zones can leak out of a track bounded zone, if there is a net
matching the zone's net crossing the track (netcode=0) boundary. So
that has its problems. Now onto the new design:
So I have some ideas, mostly data structure oriented. I suggest a new
class called ZONE:
1) edgeList: list of zone edge segments EDGE_ZONEs, comprising the
zone's boundary = "closed polygon".
2) segList: list of zone segments, SEGZONEs.
5) layer number
add HitTest(), Save(), Draw() etc. functions, where HitTest() does a
check if a point is inside the closed polygon.
add a vector<ZONE> to BOARD, so we can have any number of ZONE's in
there. Change m_CurrentZoneLimit to:
int m_CurrentZone; // index into the vector<ZONE>, useful when editing
the existing list of SEGZONE's is removed, because SEGZONE's live in
their respective ZONE which in turn are in the vector.
The ZONE::HitTest() function is a key to it all. Rather than hit
testing each SEGZONE, simply test for the polygon interior. The
SEGZONE's may or may not be present for this to work. Also the
integrity of BOARD::Visit() has to be maintained even through the vector
and ZONEs, down to the segList and edgeList.
Also, change the EDGE_ZONE to derive from TRACK, not DRAWSEGMENT. This
way we can make the damn thing visible to us blind guys (with greater
width when editing!), and we can borrow all of the track editing code
such as "move node", "drag segment", etc. The zone edge editing
functions are then really the track editing functions generalized to
work with an arbitrary "track list". Actually the "track list" is then
I would say a ZONE is then essentially a closed polygon. We can consult
established algorithms for hit testing. If a user places a zone
outside the pcb edges, then the zone gets drawn outside the PCB's
edges. (PCB edges can be accounted for at gerber generation.) Each
closed polygon stands on it own, and really does not need to know too
much about other polygons. At DRC time, you could do an overlap test
between "all ZONEs on the same layer with differing netcodes", again
using established polygon overlap algorithms.
When considered in this light, one begins to wonder if SEGZONEs are even
needed, maybe they can be done away with altogether. Only at gerber
generation do the lines come to light. The user then has gerbview to
see the fine details of his zones. Basically, the ZONE is similar in
nature to an odd shaped track at this point, a closed polygon.
I was going to code this in the next 5 minutes. :)
But since you are volunteering, it can be your baby. I'm just glad
that this has been recognized as the highest priority problem.
If you want to keep bouncing ideas around, keep this thread going.