kicad-developers team mailing list archive

[jean-pierre charras - INPG <jean-pierre.charras@...>]

Dick H. a écrit :
> I put a png file showing the problem in the files section of this
> (developers!) list called dicks_board.png.
>
> If you look at pad K10, you see that I did a partial layout connecting
> K10 through two short tracks to a VIA, then stopping. I wanted to
> place this work on the board after I knew where the chip would go. So
> the remainder of the tracks would be completed later.
>
> K10 is a ground pad. It has a net name and netcode properly. But the
> grey Via is not connected and has netcode=0. I believe this came
> about because I made 15 or so *very short* (small distance) block
> moves of the chip and all its short tracks and eventually the Via
> became disconnected. I cannot say precisely when or how this happened
> as I did not notice until later.
I saw ...
> Initially the tracks were disconnected also when I first noticed it. 
> Then I found the track operations under "Miscellaneous | Clean
> Tracks". I tried the "connect to pads" option and this connected the
> tracks to the pads, often introducing an almost zero length short
> track exactly on top of the pad.
I wrote this feature because some time ago I had to convert some pcb 
created by orcadpcb to pcbnew boards.
Its can be usefull for other conversions.
> Yet I see no options to re-connect (yes, reconnect!) the vias, and
> there are quite a few vias.

> Is there an aspect of this design I do not understand?
>
>
> Should we add an additional "track operation" which would reconnect to
> vias?
It can be usefull to solve your problem (For me, this problem did not 
exits when i wrote the cleaning and reconnect functions).
> Should there not also be an additional "track operation" which would
> update the netcode for all tracks as well, essentially reconnecting
> them base on their eventual copper extent and conductivity?
No, for computation time reasons, in code used to compute connectivity, 
tracks (and vias) are saw as connected only
if via position and track ends coordinates have same value.

Change it and keep a fast computation time (for large boards) is not 
trivial.
(When I wrote this code, first algorithms where not optimized and the 
computation times was more than 100 times slower...)
For example I used a fast locate pads algorithm using a sorted list by X 
value and a dichotomic search.
Take in count copper extent is not very simple (but possible...).
Do not forget to find if 2 tracks are connected , considering their full 
copper extent ) can cost computation time, when a track is not 
horizontal or vertical.
(this is also true for pads).
But , of course, algos can be enhanced to partially take in count a 
small copper extent ( like min dimension for pads, or min track width) .

I plan to translate connect.cpp t(which handle most of connectivity 
computations) , this week, and perhaps clean to code.
Recalcule_all_net_connexion() was non used because 
WinEDA_BasePcbFrame::test_connexions( wxDC* DC ) does the same thing.
I'll remove Recalcule_all_net_connexion() when i clean this code.



--
Jean-Pierre CHARRAS
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
46, Avenue Félix Viallet
38031 Grenoble Cedex