kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 10/8/2016 1:20 PM, Nox wrote:
> 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?
> 
> 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).
> 
> 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.
> 
> 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.

There is nothing here that has not been discussed before.  The reason
that freely assigning nets to vias has not been implemented is that
every implementation is a compromise.  If we allow random net naming of
vias, all manner of bad things can happen that are completely out of the
control of kicad.  Instead of your wtf moment being some tracks and vias
with no associated net being ripped up when you import a new netlist,
your wtf moment is a stack useless pcbs that you just spend money on.  I
promise you that a user whose wtf moment is the latter is going to be
more pissed off than the user who's tracks and vias got ripped up.  I
get it, stitching vias are very useful but being able to assign any net
name to a via (or any other copper feature for that matter) is dangerous
at best.  Selecting a net from a list of available nets is a potential
solution but even that has it's draw backs.  When (if) we ever get
bidirectional netlist support implemented between the board and
schematic editors, it would help with this issue.  At least then we
could warn users when they assign a net that does not exist in the
schematic.  I'm not opposed to a implementing something like this but it
opens up a mine field of issues.  I think we should proceed with caution.

> 
> 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
>>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp