kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

-------- Message transféré --------
Sujet : Re: [Kicad-developers] Feature Request: ViaStiching
Date : Sat, 28 Mar 2015 21:00:06 +0100
De : jp charras <jp.charras@xxxxxxxxxx>
Pour : Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>

Le 28/03/2015 19:33, Tomasz Wlostowski a écrit :
> On 28.03.2015 07:55, jp charras wrote:
>> Le 27/03/2015 22:39, John Beard a écrit :
>>
>> John,
>> Currently, vias not connected to a pads (by tracks) are considered as
>> not connected (i.e. have the net 0) as soon as the board connections are
>> recalculated
>>
>> This is true also for tracks connected to nothing, and I am thinking
>> this is the right way to handle not connected track segments (vias are
>> also track segments) when the board connections are recalculated.
> 
> Hi Jean-Pierre,
> 
> The proprietary software that I used (Eagle, Altium, PADS) does not
> change the nets of any item on the board without the user explicitly
> allowing such a change. This - in my humble opinion - gives more control
> over the design and reduces the chances of accidentally breaking it.

I never used PADS, but I used Altium to design a tricky board (8 layers,
and strong mechanical and electrical constrains, to help guys who
recently buy 2 Altium licenses).

I alsu used Eagle but just few minutes to test some features.
I was not impressed by the way arcs in tracks are handled.

I am just able to talk about Altium (which have some very great features
like rooms, 3D export and visualisation, not better features than Kicad
like zone handling (different but not better), and some features I did
not like (poor features or complicated features to do basic things) ).

> 
> I find the current connectivity calculation algorithm a bit too invasive
> - but this I could live with. The worse part is that net code
> recalculation is silently called in many places without the agreement of
> the user and cannot be undone. For example, when I design PCBs, I often
> leave some 'snippets' (e.g. some trace/via patterns) aside, for later
> use. I would prefer Kicad to not change or reset their nets unless I
> tell it to...

During a session, nets are not changed, unless you read a netlist or
rebuild the full connectivity.
However if you save and read the board, nets of not connected tracks are
reset, because the connectivity is rebuilt.

Altium keeps and saves the nets of unconnected tracks/vias.
(I have to say I frequently see bugs in netlist imports when nets were
changed in Altium.
So I was not impressed by the way Altium manages netlist changes)
You can see that like an advantage or an inconvenient.
It mainly depends on the problem you have to solve.

For instance, I found not easy in Altium to just swap 2 tracks between 2
pads of a Xilinx, which just needed to delete and redraw only 2 small
track segments.
But perhaps this was due to the fact I did not made a lot of boards with
Altium.

In Kicad you just have to modify the schematic, disconnect the 2cpads
which are swapped and reread the netlist to change the nets of tracks.

> 
> The cases where the net of an item may be changed (except for editing it
> in the item's properties) IMHO are:
> 1) Netlist update (propagated from the pads of the changed components,
> just like the current algorithm does).
> 2) Removing net completely on the schematic causes removal of the
> corresponding nets on the PCB.
> 3) Placing a pad (or module) over a set of board items (tracks, vias)
> causes the latter to inherit the pads' nets only if not connected to
> another pad.
> 4) Placing a set of board items (excluding components) over pads with
> assigned nets causes the former to inherit the pads' nets. This one is
> particularly useful for copying & pasting via fanouts under big BGAs
> (route one row/side of a BGA, paste over other BGA pads)
> 5) Zone nets may be changed only if the net no longer exists in the
> schematic.
> 
>>
>> Moreover, these tracks are removed by the board cleaning functions.
>>
> 
>> Via stitching is not a thing which is easy to add.
>> Be sure this feature requires a lot of work (DRC, filling zone
>> algorithms ... )
> 
> I agree we would need to modify the DRC (but AFAIK it only means
> producing errors on vias that are not connected to anything instead of
> removing them).
> 
>> and needs file format changes.
> What file format changes would be required to support stitching vias if
> the items' nets are changed only in the situations pointed above?
> 

Stand alone vias/tracks and stitching vias are very different things (I
said that in a previous mail)

Stitching vias need to be handled by a zone (I am thinking this is the
case in Altium).
Therefore you have to store this info (parent zone and stitching
parameters like pitch, size ...
At least to edit/remove/recreate them all in once.
You cannot seriously expect to store these vias like now (like tracks),
and remove them one by one when you want to remove the zone stitching.

Please, also consider the fact you have to test and remove insulated
copper islands.
The algo which removes insulated copper islands needs to be rewritten.
And it must be fast enough to be usable.
The current algo is not correct with these vias.

If I remember the very long calculation time in Altium to place these
vias, it is not obvious.

I want to be clear:
I am not opposed to add stitching vias to pcbnew (I am thinking this is
a good feature)
But I am saying the code is not a basic training work for beginners.

And you have to define the behavior of Pcbnew when the zones with
stitching vias are refilled, and the DRC behavior:
Are new tracks allowed to be placed inside stitching vias ?
Are the stitching vias replaced and vias colliding with tracks removed ?

Be sure adding stitching vias is a serious work which cannot be made in
five minutes (at least if you want something else than create bugs).

> Cheers,
> Tom
> 


-- 
Jean-Pierre CHARRAS