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. > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
