← Back to team overview

kicad-developers team mailing list archive

Re: Re: Problems in Ratsnest


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

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

Follow ups