kicad-developers team mailing list archive
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
I wrote this feature because some time ago I had to convert some pcb
created by orcadpcb to pcbnew boards.
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.
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.
It can be usefull to solve your problem (For me, this problem did not
exits when i wrote the cleaning and reconnect functions).
Is there an aspect of this design I do not understand?
Should we add an additional "track operation" which would reconnect to
No, for computation time reasons, in code used to compute connectivity,
tracks (and vias) are saw as connected only
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?
if via position and track ends coordinates have same value.
Change it and keep a fast computation time (for large boards) is not
(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.
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
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
46, Avenue Félix Viallet
38031 Grenoble Cedex