kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/08/2011 03:50 PM, jean-pierre charras wrote:
> 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 seems plausible.  I don't know off the top of my head if Freerouter is using a more
tolerable connection test than "track ending exactly at pad center".

When I get some time, I will do some more investigation.  The simplest test is to re-route
those traces in Freerouter, which should in any case re-center the track ends on pads.

Thanks Jean-Pierre.

Dick



> 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.
>
>