← Back to team overview

kicad-developers team mailing list archive

Re: Re: saving zone edges in pcb file



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 some code) 2 - must we save zone parameters (net name, zone clearance, grid ... ) with the zone or use the current zone parameters (which can differ from initial parameters)
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 refilled, 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 creates difficulties: 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:

class ZONE
1) edgeList: list of zone edge segments EDGE_ZONEs, comprising the zone's boundary = "closed polygon".
2) segList: list of zone segments, SEGZONEs.
3) netname
4) netcode
5) layer number
6) ...

add HitTest(), Save(), Draw() etc. functions, where HitTest() does a check if a point is inside the closed polygon.

class BOARD
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 only.

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 BOARD.vector[m_CurrentZone].edgeList.

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.

Best Regards,

Dick Hollenbeck