kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Jean-Pierre,

> 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