kicad-developers team mailing list archive

[dick@...]

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

Yes it was helpful converting a fully screwed up pcbnew file to a  
partially screwed up pcbnew file.

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

The standard track continuity algorithm maybe does not need to change  
except for any future bug fixing, but I and any other user needs a way  
for the software to honor what a track looks like. In other words,  
Kicad needs another track operation which can be run under special  
circumstances. (By the way, the "clean tracks" menu option should be  
called "track operations".) The tracks need to be what we say in  
English is "what you see is what you get". You cannot show a track  
overlapping a via, and not give the user a way to make that actually  
be a connection, because in copper it is a connection!

If we cannot find the bug that led to my bad board file, then we need  
a recovery feature, another track operation. It looks like I will  
have to write it.

The speed of the recovery feature is not important, because the speed  
of me re-entering all my tracks is from now to eternity, meaning it  
will never happen. I cannot trust that the 2nd time entering tracks  
and vias will give any better results.

The way forward is clear for me, and Kicad will once again be the  
better for it.



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