kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

> To use the zone filling in connectivity calculations, only a volunteer 
> is needed to create 2 or 3 functions which test zone segments connectivity.
> Tim, currently, you cannot be this volunteer because you have work about 
> eeschema.
> Dick i believe you are not volunteer (am I right ?)
> And i am busy...
>
> But if a volunteer exists, i could help it to start the work.

Jean-Pierre,

It is good that you are communicating well. I had the impression that 
you were working on the whole group of continuity testing primitives. 
So we are making progress in learning that you are willing to let 
someone else move into that role.

As we discussed, currently the "end point" matching on tracks is an 
inadequate test of electrical continuity. What is your starting 
point? Please put a list together and summarize which functions are 
the building blocks if any that you have, so that no duplication of work 
takes place. I would like to look at that before I make any commitments.

Once we have those continuity testing primitives, then we can experiment 
with how to employ them.

The primitives work on following objects:

tracks, pads, via, and zones. Allow me to use "zone" in an abstract 
sense for a moment.

So we have to test continuity between:

track to track (present test is inadequate)
track to pad (present test is inadequate)
track to via (present test is inadequate)
track to zone (no test exists)

pad to pad (no test exists)
pad to via (no test exists, but log is same as pad to pad)
pad to zone (no test exists)

via to via (no test exists, but like pad to pad)
via to zone (no test exists, but like pad to zone)

zone to zone (test exists in polygon library, needs wrapper)


anything missed here?


I had made some remarks earlier about having a series of BOARD_ITEM 
functions, such as

bool TRACK::ConnectsTo( TRACK* )
bool TRACK::ConnectsTo( PAD* )

bool ZONE::ConnectsTo( TRACK* ) (remember ZONE is abstract here!)

etc.

If we had those, we could re-arrange the current code to use them 
immediately. Client code and test primitive implementation could be 
done by two different people, concurrently. In fact for track to track 
testing, the old endpoint tests could be used for a short term, wrapped 
in the new wrapper: bool TRACK::ConnectsTo( TRACK*) . And in that 
short term, the client code can be architected to sit on top of 
TRACK::ConnectsTo( TRACK*) rather than

if track1.start == track2.start || track1.start == track2.end || 
track1.end == track2.start || track1.end == track2.end

This becomes: 

if( track1.ConnectsTo( track2 ) )

In addition to the ConnectsTo() family of primitives, we might need a 
function which returns the nearest point of a polygon:

wxPoint ZONE::GetNearestPoint( wxPoint fromHere )

This one would help in the ratsnest drawing and give the shortest path.


Your offer to give direction is being accepted by me, but before you 
have a volunteer.

Thanks,

Dick