kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 08/10/2016 à 19:20, Nox a écrit :
> Well you got a point there regarding the netlist reparsing.  One can work around this issue (like
> almost every other issue). I.e. the copying connections can be of course renamed by placing them on
> a valid connection point and trigger the auto relabeling. But does this feel intuitive?

I don't know your exact problem, but if you place a track on a not valid connection point (this is
already a bug), you'll have lot of issues (cleanup functions not working as you are expecting,
incorrect ratsnest and many other issue)
A track on a not valid connection point is a malformed track, regardless its net name.
Relabeling this malformed track by hand does not suppress the issue.

> 
> The proposed patch is of course more useful if one gives the user the chance to decide if apperently
> orphaned elements should be automatically delabeled or not ( see
> https://bugs.launchpad.net/kicad/+bug/999057 ). I.e.  one can get a bit more straight forward
> solution to the via problem (as users would be abled to modify the name of vias/track and decide if
> vias/tracks would lose their label automatically or not - an approach which works relatively good in
> eagle).

Well, "relatively good" make me nervous: a board is good or not good. It cannot be "relatively good"


> 
> I beg your pardon if the following might be offensive but my first thought than i realized that
> kicad is relabeling stuff at its one will (might it be reasonable or not) and that I have no way to
> tell it not to do so was strange. After I realized that the user has no way to intuitively overwrite
> labels afterwards was a real wtf moment. It is likes microsoft decision to enforce automatic updates
> on win10 and introduce the "active hours" as a "convenient solution" - in the end the user has no
> real decision power about the updating itself.

I do not see offending things here.
But trying to relabelling floating vias or tracks breaks zone filling algorithm and the legacy
connection calculations.
These algos are expecting a track (or a via which is a vertical track) is connected and not floating
to decide if a copper pour is insulated (and therefore removed) or not.

Stitching vias are an other problem, and cannot be created by the current vias
They must be a specific type of vias, if they allowed to be "floating.

Any attempt to try to keep netnames (I am not sure keeping netnames has an interest, because there
are also cases where it is not good) without taking in account zone filling algorithm, connections
and DRC calculations will create bugs (I mean *broken* boards).

The issue for stitching vias is not keeping netname (this is a very minor problem).
Stitching vias must be owned by some entity (for instance a zone), which manage all editions related
to a *group* of vias (create/edit/move/delete and much more like DRC properties)
I am talking about "group of vias", because only for few vias, vias + tracks connected to pads work
fine.

When this entity is defined, netnames will be no more a problem.

So: first, define what is this entity (The best choice is not trivial for me, and deserves to think
about it), how vias are linked to (or owned by) this entity, how they are taken in account by DRC
and zone filling algorithms, and only after see if net names issues still exist.


> 
> Of course one can argue about the need of such modifications. There are many different, elaborated
> proposals about that topic and of course as many thoughful concerns. As this issue is around for
> many years and no solution seems to fulfill all needs I was thinking: Is not Kicad a tool for the
> user? Why cannot the user be allowed to do a change and decide about the "automatic" modifications
> if she or he thinks it is reasonable? Why cannot the user overwrite kicads decisions intuitively? Or
> should the user have the feeling to work most of the time around things which are done implicitely
> and/or are feeling weird (Or would anyone claim that the current workflow is fine in the face of
> heat and frequency of related topics) ?
> 
> Sorry if some parts might be taken as an offense-they are not meant to be. Actually I switched to
> kicad because of its nice push&shove feature and the ability to have unlimited boards and I think
> kicad is a good alternative to other solutions. In my humbled opinion what stops kicad from being
> great are some issues which are around and all are aware of it since years. I think a tool which is
> developed under the permise of being open and from users for users might deligate some more decision
> power during workflow to the end users and increase accessability on the data.
> 
> best regards,
> Nox
> 
> Am 08.10.2016 um 18:23 schrieb jp charras:
>> Le 07/10/2016 à 21:12, Nox a écrit :
>>> Hello Orson,
>>>
>>> You are completely right and I am aware of this fact. Tbh this modification is in the current state
>>> only of limited use. Some of the few occasions I encountered was then I moved/copied some routed
>>> parts around or then I changed one pin from one net to another in the schematic for an already
>>> routed board. After reading in the new netlist the already existing tracks got not the desirable
>>> name (as they are now connected to two different pins/names) so I had to remove the tracks and
>>> replace them again to get them properly connect IIRC.
>> You do not need to remove the track: just remove the incorrect segment (only one is enough and you
>> know what segment is wrong after changing you schematic), and after rebuild the connectivity.
>>
>> Remaining tracks will be correctly updated with the right net name.
>> No need of a new tool to rename track nets. Pcbnew does that very well
>>
>> (or you can choose the automatic deletion of bad tracks when reading the netlist)
>>
>>> Actually I would love to discuss as well if auto renaming needs to be a mandatory step or if it
>>> could be a tool instead or if one could implement a option to preserve names of not or ambiguous
>>> connected elements during the auto renaming.
>>>
>>> Regards,
>>> Nox
>>>
>>> Am 07.10.2016 um 19:14 schrieb Maciej Sumiński:
>>>> Hi Nox,
>>>>
>>>> Tracks & vias obtain their nets through the net propagation algorithm:
>>>> they inherit nets from the pads they are connected to. Manually assigned
>>>> net names will be overridden every time the algorithm is executed.
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> On 10/07/2016 05:09 PM, Nox wrote:
>>>>> Hello,
>>>>>
>>>>> what do you guys think about enabling edit of net names for tracks&vias
>>>>> via the property dialog? Is it silly to allow that?
>>>>> I thought about something like that: http://codepad.org/F2sGzw7u .
>>>>>
>>>>> best regards
>>
> 
> 


-- 
Jean-Pierre CHARRAS