kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

Le 08/11/2011 22:00, Dick Hollenbeck a écrit :
> On 11/08/2011 01:52 PM, Dick Hollenbeck wrote:
> > Jean-Pierre,
> >
> > Regarding:
> >
> > http://tech.groups.yahoo.com/group/kicad-users/message/10739
> >
> > I am still seeing a few ratsnest lines that I do not think should be shown, also with the
> > newer ratsnest algorithm.
> >
> > These are the same 2-3 lines on a board that are shown with the old algorithm.  The two
> > nets, along with the entire board, are a result of a back import from freerouter.
>
> I should mention that if I then re-export again, back to Freerouter, it does not show the
> same 3 "incompletes" (which are Freerouter's ratsnests).
>
> This suggests:
>
> 1) that KiCad and Freerouter have a difference of opinion on whether the 3 nets are
> connected.  Freerouter thinks they ARE connected.
>
> 2) that the "back import" could not have damaged the 3 nets to the point of
> unconnectivity, since the re-export goes back over to Freerouter fine.
>
>
> > I don't currently want to suggest a solution, since I am not up on the cause.
> >
> > However, I simply want to say that I don't think it is appropriate to show ratsnest lines
> > unless there is an unconnected net, it is really that simple.
> >
> > I can pluck out all the tracks in text form, and we can see if they are all tied
> > together.  But if you know of something that can fix this, say, by simply not using XOR
> > mode, then we should talk and think about that.
> >
> >
> > Thanks,
> >
> > Dick

I am thinking we do do talking about the same thing.
Bugs I was talking about report missing airwires, not missing connections.
I am thinking airwires were not missing, but just erased by the XOR mode.

You are talking about connections not seen by Pcbnew, but seen by Freerouter.
This case is very possible:
This is not due to the rastnest algorithm (that calculate only the shorter path between pads),
but to the way connections are detected.
Currently (new algos are faster than old algos but have the same limits) Pcbnew think a track is connected to a pad
if the track end coordinate is *exactly* on the pad location.
This is very restrictive and some other tools are more tolerant to detect a connection and therefore they can see connections
not detected by Pcbnew.
This is also true to detect a track to track connection.

This is usually not an issue when tracks are created by Pcbnew:
during track creation, Pcbnew handle this constraint and align track ends coordinates to the connected item
(pad, other track end) coordinate.

But when importing tracks from an other tool (or when slightly moving a footprint) this issue can happen.


--
Jean-Pierre CHARRAS