Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 18/10/16 01:47, Wayne Stambaugh wrote:

I created a new entry in the version 5 road map[1] to address this
issue.  Please take a look at it when you get a chance to make sure I
didn't miss anything.

Cheers,

Wayne

[1]:
https://git.launchpad.net/kicad/commit/?id=c483574658c2a57057ab9c6956ad40ef141bfe26

Looks good to me.  Thanks Wayne.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Wayne Stambaugh]

I created a new entry in the version 5 road map[1] to address this
issue.  Please take a look at it when you get a chance to make sure I
didn't miss anything.

Cheers,

Wayne

[1]:
https://git.launchpad.net/kicad/commit/?id=c483574658c2a57057ab9c6956ad40ef141bfe26

On 10/13/2016 12:01 PM, Strontium wrote:
> On 13/10/16 22:21, Wayne Stambaugh wrote:
>> I'm going to keep this brief, please respond in kind.  I'm going to
>> create a new entry in the version 5 road map over the weekend with the
>> pertinent requirements so this will be my last comments on this subject.
>>   The horse is dead.
> Noted.
>> Why the bypass?  Just change the connectivity algorithm to keep the
>> currently assigned nets.  Your patch creates a maintenance issue and is
>> confusing.
> The connectivity algorithm uses the net of an entity set as Unassigned
> as an internal flag to test if the entity is reconnected or not yet. 
> Its global data.  To change that would require changing the global data
> structure that holds entities.  I tired to keep the change minimal and
> self contained. It could be done, as you suggest, with a change to the
> global data structure of entities, if that's the preference.
>> The via net defines to which entity it is connected.
> No, it doesn't, not currently.
>> There are no
>> assumptions here nor would I ever be comfortable with making any such
>> assumptions.
> KiCad currently makes the assumption that the entities net can be traced
> back to a pad and the pads net is the real net of the entity, and if it
> can not, then the Net of the entity is unimportant and therefore
> "Unassigned".  The net assigned to the via or track is currently
> irrelevant to DRC.
> 
> Steven
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Nox]

Okay I respect that decision. I hoped to collect all the made statements 
and sugguestion to wrap it up, to avoid further double doing and maybe 
give a proposal for a common ground agreement but due to an accident I 
am currently not really capable to work on it properly. I wanted to try 
to educe a short term minimal invasive solution (i.e. no change in 
kicads default behavior but introduction of a "su" option) combined with 
a roadmap for a generally improved default behavior as long term goal.



Am 13.10.2016 um 16:21 schrieb Wayne Stambaugh:


I'm going to keep this brief, please respond in kind.  I'm going to
create a new entry in the version 5 road map over the weekend with the
pertinent requirements so this will be my last comments on this subject.
  The horse is dead.

On 10/12/2016 12:16 AM, Strontium wrote:

On 11/10/16 23:35, Wayne Stambaugh wrote:

On 10/11/2016 12:18 AM, Strontium wrote:

On 11/10/16 09:27, Wayne Stambaugh wrote:

I've thought about this for a while and I'm going to try a different
approach.  Please bear with me, this is going to be lengthy but in the
interest of resolving the via stitching issue properly, I think it
needs
to be done.  I'm going to expand on JP's idea that we first define the
problem we are trying to solve before we can arrive at a sound
solution.

For my part the problem i would like to see solved is stated as:

"Do not assign the net of any pcb entity as Unassigned unnecessarily."

That's it.  This behaviour hits on all kinds of use cases, but most
noticeably via stitching, but at its core it is the behaviour of
unsolicited changing of net assignments to Unassigned I object to most
strongly, for any reason.

My opinion is, if there is a pre-existing net assignment there is no
reason to prefer the "unassigned net" to it over the "pre-existing"
one.  The "Unassigned" net is guaranteed to be wrong 100% of the time,
the other choice may or may not be wrong, but its probably correct.  So
"most" of the time you have done the right thing, and for all other
cases you are no worse off than now.

I agree with this.  We should not be changing the assigned nets in any
entity.  We should only be testing for connectivity and generating the
appropriate errors in the drc.

Yes, I agree too, which is why I was surprised by the rejection of the
proposed patch.

Let me summarise the processing the DRC re-connectivity pass CURRENTLY
does:
1. Overwrites ALL Tracks and ALL Vias of their existing Net associations
and sets them to "Unassigned".
2. It then iterates through pads, propagating the net of the pads to
their connected entities.
3. It finishes.

The side effect of this processing is any and all Tracks/Vias that do
not have connectivity to a pad have lost the net assigned to them.  It
has been changed from "the net assigned during design" to "Unassigned".
Step 1 is irretrievable, all entities just have their Net forcibly set
to Unassigned, regardless of what it is currently set to.

My patch adds two steps so the process becomes:
0. Locally Backup all entities Net assignments.
1. Overwrites ALL Tracks and ALL Vias of their existing Net associations
and sets them to "Unassigned".
2. It then iterates through pads, propagating the net of the pads to
their connected entities.
3. Finally Iterate all entities, IF AND ONLY IF the entity has a net of
Unassigned, then recover its Net from the backup stored in step 0.
4. End.

Steps 1 & 2 are unchanged from the original process.

Why the bypass?  Just change the connectivity algorithm to keep the
currently assigned nets.  Your patch creates a maintenance issue and is
confusing.


I did this because a side effect of the current processing is
irretrievably lost net assignments.  The result of the patch is, after
all re-connectivity is established, repair the damage done by step 1.
It does not do any Arbitrary assignment of Nets to Entities, an Entity
can only have one of two nets after this, the net of a connected pad, or
the net it had prior to the DRC pass.

I firmly agree that there could and should be more DRC errors issued out
of the DRC processing, but its a separate issue, and really before we
start issuing errors, we need to agree that we should be throwing net
assignments out the window arbitrarily or not.  If not, then my patch
corrects that in a very simple way with no change to global data
structures.

You can make step 2 as complex as you like, add all sorts of logic to
try and determine the "True" net for an entity, but at the end of that,
it is my stance that any entity that failed to be "reconnected" by step
2, should not have its net left changed to Unassigned.  Because the Net
was Assigned, it was the DRC pass in step 1 that Unassigned it.  Its
cleanup, to correct the damage done by Step 1.  You can see the damage
it causes in the pictures I posted, it is clear damage caused by the DRC
process to the board layout and design as laid down by the designer.

I can easily add a DRC note/warning/error (and I think the 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 13/10/16 22:21, Wayne Stambaugh wrote:

I'm going to keep this brief, please respond in kind.  I'm going to
create a new entry in the version 5 road map over the weekend with the
pertinent requirements so this will be my last comments on this subject.
  The horse is dead.

Noted.

Why the bypass?  Just change the connectivity algorithm to keep the
currently assigned nets.  Your patch creates a maintenance issue and is
confusing.
The connectivity algorithm uses the net of an entity set as Unassigned 
as an internal flag to test if the entity is reconnected or not yet.  
Its global data.  To change that would require changing the global data 
structure that holds entities.  I tired to keep the change minimal and 
self contained. It could be done, as you suggest, with a change to the 
global data structure of entities, if that's the preference.

The via net defines to which entity it is connected.

No, it doesn't, not currently.

There are no
assumptions here nor would I ever be comfortable with making any such
assumptions.
KiCad currently makes the assumption that the entities net can be traced 
back to a pad and the pads net is the real net of the entity, and if it 
can not, then the Net of the entity is unimportant and therefore 
"Unassigned".  The net assigned to the via or track is currently 
irrelevant to DRC.


Steven


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Wayne Stambaugh]

I'm going to keep this brief, please respond in kind.  I'm going to
create a new entry in the version 5 road map over the weekend with the
pertinent requirements so this will be my last comments on this subject.
 The horse is dead.

On 10/12/2016 12:16 AM, Strontium wrote:
> 
> On 11/10/16 23:35, Wayne Stambaugh wrote:
>> On 10/11/2016 12:18 AM, Strontium wrote:
>>> On 11/10/16 09:27, Wayne Stambaugh wrote:
 I've thought about this for a while and I'm going to try a different
 approach.  Please bear with me, this is going to be lengthy but in the
 interest of resolving the via stitching issue properly, I think it
 needs
 to be done.  I'm going to expand on JP's idea that we first define the
 problem we are trying to solve before we can arrive at a sound
 solution.
>>> For my part the problem i would like to see solved is stated as:
>>>
>>> "Do not assign the net of any pcb entity as Unassigned unnecessarily."
>>>
>>> That's it.  This behaviour hits on all kinds of use cases, but most
>>> noticeably via stitching, but at its core it is the behaviour of
>>> unsolicited changing of net assignments to Unassigned I object to most
>>> strongly, for any reason.
>>>
>>> My opinion is, if there is a pre-existing net assignment there is no
>>> reason to prefer the "unassigned net" to it over the "pre-existing"
>>> one.  The "Unassigned" net is guaranteed to be wrong 100% of the time,
>>> the other choice may or may not be wrong, but its probably correct.  So
>>> "most" of the time you have done the right thing, and for all other
>>> cases you are no worse off than now.
>> I agree with this.  We should not be changing the assigned nets in any
>> entity.  We should only be testing for connectivity and generating the
>> appropriate errors in the drc.
> Yes, I agree too, which is why I was surprised by the rejection of the
> proposed patch.
> 
> Let me summarise the processing the DRC re-connectivity pass CURRENTLY
> does:
> 1. Overwrites ALL Tracks and ALL Vias of their existing Net associations
> and sets them to "Unassigned".
> 2. It then iterates through pads, propagating the net of the pads to
> their connected entities.
> 3. It finishes.
> 
> The side effect of this processing is any and all Tracks/Vias that do
> not have connectivity to a pad have lost the net assigned to them.  It
> has been changed from "the net assigned during design" to "Unassigned". 
> Step 1 is irretrievable, all entities just have their Net forcibly set
> to Unassigned, regardless of what it is currently set to.
> 
> My patch adds two steps so the process becomes:
> 0. Locally Backup all entities Net assignments.
> 1. Overwrites ALL Tracks and ALL Vias of their existing Net associations
> and sets them to "Unassigned".
> 2. It then iterates through pads, propagating the net of the pads to
> their connected entities.
> 3. Finally Iterate all entities, IF AND ONLY IF the entity has a net of
> Unassigned, then recover its Net from the backup stored in step 0.
> 4. End.
> 
> Steps 1 & 2 are unchanged from the original process.

Why the bypass?  Just change the connectivity algorithm to keep the
currently assigned nets.  Your patch creates a maintenance issue and is
confusing.

> 
> I did this because a side effect of the current processing is
> irretrievably lost net assignments.  The result of the patch is, after
> all re-connectivity is established, repair the damage done by step 1. 
> It does not do any Arbitrary assignment of Nets to Entities, an Entity
> can only have one of two nets after this, the net of a connected pad, or
> the net it had prior to the DRC pass.
> 
> I firmly agree that there could and should be more DRC errors issued out
> of the DRC processing, but its a separate issue, and really before we
> start issuing errors, we need to agree that we should be throwing net
> assignments out the window arbitrarily or not.  If not, then my patch
> corrects that in a very simple way with no change to global data
> structures.
> 
> You can make step 2 as complex as you like, add all sorts of logic to
> try and determine the "True" net for an entity, but at the end of that,
> it is my stance that any entity that failed to be "reconnected" by step
> 2, should not have its net left changed to Unassigned.  Because the Net
> was Assigned, it was the DRC pass in step 1 that Unassigned it.  Its
> cleanup, to correct the damage done by Step 1.  You can see the damage
> it causes in the pictures I posted, it is clear damage caused by the DRC
> process to the board layout and design as laid down by the designer.
> 
> I can easily add a DRC note/warning/error (and I think the level should
> be a preference) during the cleanup, that's not an issue and I think its
> worthwhile.  The only rationale I can see for turning the cleanup pass
> in step 3 off is for developers, and only if they are working on the
> re-conectivity algorithms of step 1.  And for developers, it really just
> needs to be a comment, "set this to 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 11/10/16 23:35, Wayne Stambaugh wrote:

On 10/11/2016 12:18 AM, Strontium wrote:

On 11/10/16 09:27, Wayne Stambaugh wrote:

I've thought about this for a while and I'm going to try a different
approach.  Please bear with me, this is going to be lengthy but in the
interest of resolving the via stitching issue properly, I think it needs
to be done.  I'm going to expand on JP's idea that we first define the
problem we are trying to solve before we can arrive at a sound solution.

For my part the problem i would like to see solved is stated as:

"Do not assign the net of any pcb entity as Unassigned unnecessarily."

That's it.  This behaviour hits on all kinds of use cases, but most
noticeably via stitching, but at its core it is the behaviour of
unsolicited changing of net assignments to Unassigned I object to most
strongly, for any reason.

My opinion is, if there is a pre-existing net assignment there is no
reason to prefer the "unassigned net" to it over the "pre-existing"
one.  The "Unassigned" net is guaranteed to be wrong 100% of the time,
the other choice may or may not be wrong, but its probably correct.  So
"most" of the time you have done the right thing, and for all other
cases you are no worse off than now.

I agree with this.  We should not be changing the assigned nets in any
entity.  We should only be testing for connectivity and generating the
appropriate errors in the drc.
Yes, I agree too, which is why I was surprised by the rejection of the 
proposed patch.


Let me summarise the processing the DRC re-connectivity pass CURRENTLY does:
1. Overwrites ALL Tracks and ALL Vias of their existing Net associations 
and sets them to "Unassigned".
2. It then iterates through pads, propagating the net of the pads to 
their connected entities.

3. It finishes.

The side effect of this processing is any and all Tracks/Vias that do 
not have connectivity to a pad have lost the net assigned to them.  It 
has been changed from "the net assigned during design" to "Unassigned".  
Step 1 is irretrievable, all entities just have their Net forcibly set 
to Unassigned, regardless of what it is currently set to.


My patch adds two steps so the process becomes:
0. Locally Backup all entities Net assignments.
1. Overwrites ALL Tracks and ALL Vias of their existing Net associations 
and sets them to "Unassigned".
2. It then iterates through pads, propagating the net of the pads to 
their connected entities.
3. Finally Iterate all entities, IF AND ONLY IF the entity has a net of 
Unassigned, then recover its Net from the backup stored in step 0.

4. End.

Steps 1 & 2 are unchanged from the original process.

I did this because a side effect of the current processing is 
irretrievably lost net assignments.  The result of the patch is, after 
all re-connectivity is established, repair the damage done by step 1.  
It does not do any Arbitrary assignment of Nets to Entities, an Entity 
can only have one of two nets after this, the net of a connected pad, or 
the net it had prior to the DRC pass.


I firmly agree that there could and should be more DRC errors issued out 
of the DRC processing, but its a separate issue, and really before we 
start issuing errors, we need to agree that we should be throwing net 
assignments out the window arbitrarily or not.  If not, then my patch 
corrects that in a very simple way with no change to global data structures.


You can make step 2 as complex as you like, add all sorts of logic to 
try and determine the "True" net for an entity, but at the end of that, 
it is my stance that any entity that failed to be "reconnected" by step 
2, should not have its net left changed to Unassigned.  Because the Net 
was Assigned, it was the DRC pass in step 1 that Unassigned it.  Its 
cleanup, to correct the damage done by Step 1.  You can see the damage 
it causes in the pictures I posted, it is clear damage caused by the DRC 
process to the board layout and design as laid down by the designer.


I can easily add a DRC note/warning/error (and I think the level should 
be a preference) during the cleanup, that's not an issue and I think its 
worthwhile.  The only rationale I can see for turning the cleanup pass 
in step 3 off is for developers, and only if they are working on the 
re-conectivity algorithms of step 1.  And for developers, it really just 
needs to be a comment, "set this to false to disable net cleanup" or 
something like that.  I dont know what value exposing it to the end user 
has.






   It may turn out that there may be a reasonable solution that isn't
terribly difficult to implement without completely rewriting the drc
code or ignoring net connections which have undesirable side effects.

First and foremost is the definition of a via.  A via is a feature that
electrically connects two or more copper features (not just tracks) on
different board layers having the same net.

I disagree on the "Two or more" A stitching via acting as a RF shield
along a RF trace might 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Jakub Kozdon]

When in doubt show distinguishing table.

But why not do to it for user as simple as:

1. select via tool
2. set via parameters (drill diameter, annular ring or set from net or 
zone automaticaly)

3. place via
3.1. when user moving over board with via tool then
- when user set automatical via parameters read it from 
net/zone or use user set via parameters
- preview via parameters so user in real time can see via 
parameters
- according to net selected by user (below) use automatical or 
user set via parameters
- when more layers over let user set desired layer/net by + or 
- or by Tab or Crtl-Tab
- and highlight user selected net/zone and write it to status 
bar to make user sure about selected net

3.2. place via with via parameters and with net selected in step 3.1.

This is only my 3 cents..


Dne 10.10.2016 v 13:43 Tomasz Wlostowski napsal(a):

On 10.10.2016 07:25, Strontium wrote:

On 09/10/16 23:11, Wayne Stambaugh wrote:

On 10/8/2016 1:20 PM, Nox wrote:

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

Wayne, respectfully this is where I believe you have missed the point.
If a designer assigns a net to a via, then THEY are responsible for the
WTF moment.  IF Kicad rips up the nets the designer assigned to vias
then KICAD is responsible for the WTF moment.  In one case the designer
screwed up and in the other Kicad screwed the designer over.

Its as simple as that.

My original patch, posted many moons ago, fixed this problem neatly.  It
did not allow a user to assign arbitrary nets, but if you plonked a via
on a GND fill, it had a GND net, and that via would ALWAYS have a GND
net until you did something explicitly to change it.

Don't shout man What if your board has more than two layers. For
instance, there's a full VCC plane on one internal layer and another
full GND plane on another internal layer? Which plane the via you place
would belong to if vias were to take their nets from copper fills?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Wayne Stambaugh]

On 10/11/2016 12:18 AM, Strontium wrote:
> On 11/10/16 09:27, Wayne Stambaugh wrote:
>> I've thought about this for a while and I'm going to try a different
>> approach.  Please bear with me, this is going to be lengthy but in the
>> interest of resolving the via stitching issue properly, I think it needs
>> to be done.  I'm going to expand on JP's idea that we first define the
>> problem we are trying to solve before we can arrive at a sound solution.
> For my part the problem i would like to see solved is stated as:
> 
> "Do not assign the net of any pcb entity as Unassigned unnecessarily."
> 
> That's it.  This behaviour hits on all kinds of use cases, but most
> noticeably via stitching, but at its core it is the behaviour of
> unsolicited changing of net assignments to Unassigned I object to most
> strongly, for any reason.
> 
> My opinion is, if there is a pre-existing net assignment there is no
> reason to prefer the "unassigned net" to it over the "pre-existing"
> one.  The "Unassigned" net is guaranteed to be wrong 100% of the time,
> the other choice may or may not be wrong, but its probably correct.  So
> "most" of the time you have done the right thing, and for all other
> cases you are no worse off than now.

I agree with this.  We should not be changing the assigned nets in any
entity.  We should only be testing for connectivity and generating the
appropriate errors in the drc.

>>   It may turn out that there may be a reasonable solution that isn't
>> terribly difficult to implement without completely rewriting the drc
>> code or ignoring net connections which have undesirable side effects.
>>
>> First and foremost is the definition of a via.  A via is a feature that
>> electrically connects two or more copper features (not just tracks) on
>> different board layers having the same net.
> I disagree on the "Two or more" A stitching via acting as a RF shield
> along a RF trace might exist where it is only connected at one point to
> a fill plane, the purpose is the vertical copper inside the via creating
> a shield, not necessarily the connection to a plane above it.  And while
> it is ideal to connect to a plane above, in a situation where only the
> via + fill will fit on one side of the board, and no room for fill zone
> on the other, the via is still preferable, from a theoretical RF
> standpoint than no via at all. There are also stitching tracks, which
> don't get much attention but exist, and they could easily be single ended.

Hmm!  I'm not sure how effective a 3 sided Faraday shield would be.  I
would think that all four sides would have to be shielded for it to
effective.  The only case where this makes sense to me is if you are
using a housing to provide the shielding of the fourth side but even
that seems dubious.  In any event, I'm ok with changing the criteria to
one or more connections.  Maybe single ended connections can be drc
warnings rather than errors.

> 
> I also prefer to think of this problem as an "entity problem" rather
> than a via problem as it also impacts on track stubs.
> 
>>   If we are in agreement with
>> that, then we should be able to agree that any via that has less than
>> two connections on different planes to the same net or that connect
>> copper features on different layers with different nets are design rule
>> errors.  Have I missed anything here?
> Yes, single ended entities are valid in my opinion, see above.
> 
>>I can't think of any valid case
>> where you would want unconnected (floating) or partially connected (1
>> connection) vias or vias that short different nets together.  If you can
>> think of one, please elaborate.
> No a via floating or otherwise should never validly short different
> nets. 100% agree.
> Single ended vias and traces, yes i believe there is a reason they
> should be able to exist.
>>
>> Once this is established, we should fix both the connection algorithm
>> and the drc to reflect this criteria.  How much work would this be?  I
>> didn't write either of these pieces of code so I'm going to have to rely
>> on some feedback here.  I'm not asking for a full rewrite of the drc
>> code even though that is a noble long term goal.  I'm asking for what it
>> would take to accommodate the criteria above with the existing code.
> Difficult, because the fill zones are not currently considered for
> connectivity.  There is feedback between the shape and size of the fill
> zone and the result of DRC net reconnection, you cant fill until you
> have your net connectivity sorted out (so the fill can flow around it or
> onto it as the case may be), and you cant sort out your net connectivity
> for stitching vias, until you fill (if you do it based on the zone shape
> and size).
> Catch 22.  Also, in order to properly calculate the fill, the isolated
> vias on it need the appropriate net so the fill can flow into them or
> around them as required.  One would also need to work out what zone the
> via belonged to, which is also 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[jp charras]

Le 11/10/2016 à 09:03, John Devereux a écrit :
> Strontium  writes:
> 
>> On 11/10/16 09:27, Wayne Stambaugh wrote:
> 
> [...]
> 
>>
>>>I can't think of any valid case
>>> where you would want unconnected (floating) or partially connected (1
>>> connection) vias or vias that short different nets together.  If you can
>>> think of one, please elaborate.
>> No a via floating or otherwise should never validly short different
>> nets. 100% agree.
> 
> There are of course "net ties" which can be exactly this.
> 
> (Sorry if that is covered elsewhere, can you make a net tie component
> like that? I don't know kicad well.)
> 
>> Single ended vias and traces, yes i believe there is a reason they
>> should be able to exist.
> 
> Maybe an "access via" for manual soldering of a thermal pad under a QFN?
> Usually it would go to a ground plane though.
> 
> Thanks,

In fact, net ties  (not yet really supported by Pcbnew, but there is a 
workaround) and complex
thermal pads are using pads, not vias.

In Kicad, vias are track segments, and pads are managed by footprints, 
therefore are managed by a
schematic, from the point of view of netnames.

I know some EDA tools (and users) do not make always a lot of difference 
between vias and pads, but
this is not the case in Kicad.
They are 2 fully separate entities.


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[John Devereux]

Strontium  writes:

> On 11/10/16 09:27, Wayne Stambaugh wrote:

[...]

>
>>I can't think of any valid case
>> where you would want unconnected (floating) or partially connected (1
>> connection) vias or vias that short different nets together.  If you can
>> think of one, please elaborate.
> No a via floating or otherwise should never validly short different
> nets. 100% agree.

There are of course "net ties" which can be exactly this.

(Sorry if that is covered elsewhere, can you make a net tie component
like that? I don't know kicad well.)

> Single ended vias and traces, yes i believe there is a reason they
> should be able to exist.

Maybe an "access via" for manual soldering of a thermal pad under a QFN?
Usually it would go to a ground plane though.

Thanks,


-- 

John Devereux

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 11/10/16 09:27, Wayne Stambaugh wrote:

I've thought about this for a while and I'm going to try a different
approach.  Please bear with me, this is going to be lengthy but in the
interest of resolving the via stitching issue properly, I think it needs
to be done.  I'm going to expand on JP's idea that we first define the
problem we are trying to solve before we can arrive at a sound solution.

For my part the problem i would like to see solved is stated as:

"Do not assign the net of any pcb entity as Unassigned unnecessarily."

That's it.  This behaviour hits on all kinds of use cases, but most 
noticeably via stitching, but at its core it is the behaviour of 
unsolicited changing of net assignments to Unassigned I object to most 
strongly, for any reason.


My opinion is, if there is a pre-existing net assignment there is no 
reason to prefer the "unassigned net" to it over the "pre-existing" 
one.  The "Unassigned" net is guaranteed to be wrong 100% of the time, 
the other choice may or may not be wrong, but its probably correct.  So 
"most" of the time you have done the right thing, and for all other 
cases you are no worse off than now.

  It may turn out that there may be a reasonable solution that isn't
terribly difficult to implement without completely rewriting the drc
code or ignoring net connections which have undesirable side effects.

First and foremost is the definition of a via.  A via is a feature that
electrically connects two or more copper features (not just tracks) on
different board layers having the same net.
I disagree on the "Two or more" A stitching via acting as a RF shield 
along a RF trace might exist where it is only connected at one point to 
a fill plane, the purpose is the vertical copper inside the via creating 
a shield, not necessarily the connection to a plane above it.  And while 
it is ideal to connect to a plane above, in a situation where only the 
via + fill will fit on one side of the board, and no room for fill zone 
on the other, the via is still preferable, from a theoretical RF 
standpoint than no via at all. There are also stitching tracks, which 
don't get much attention but exist, and they could easily be single ended.


I also prefer to think of this problem as an "entity problem" rather 
than a via problem as it also impacts on track stubs.



  If we are in agreement with
that, then we should be able to agree that any via that has less than
two connections on different planes to the same net or that connect
copper features on different layers with different nets are design rule
errors.  Have I missed anything here?

Yes, single ended entities are valid in my opinion, see above.


   I can't think of any valid case
where you would want unconnected (floating) or partially connected (1
connection) vias or vias that short different nets together.  If you can
think of one, please elaborate.
No a via floating or otherwise should never validly short different 
nets. 100% agree.
Single ended vias and traces, yes i believe there is a reason they 
should be able to exist.


Once this is established, we should fix both the connection algorithm
and the drc to reflect this criteria.  How much work would this be?  I
didn't write either of these pieces of code so I'm going to have to rely
on some feedback here.  I'm not asking for a full rewrite of the drc
code even though that is a noble long term goal.  I'm asking for what it
would take to accommodate the criteria above with the existing code.
Difficult, because the fill zones are not currently considered for 
connectivity.  There is feedback between the shape and size of the fill 
zone and the result of DRC net reconnection, you cant fill until you 
have your net connectivity sorted out (so the fill can flow around it or 
onto it as the case may be), and you cant sort out your net connectivity 
for stitching vias, until you fill (if you do it based on the zone shape 
and size).
Catch 22.  Also, in order to properly calculate the fill, the isolated 
vias on it need the appropriate net so the fill can flow into them or 
around them as required.  One would also need to work out what zone the 
via belonged to, which is also non-trivial and would almost certainly 
require the via to hold a reference to the zone it was placed upon 
(which may or may not be more important than the net it has).

If this can be resolved with a reasonable amount of effort, the only
thing that would be left would be implementing the board editor features
to place the vias.  I'm guessing most of the proposed patches address
that issue or a reasonably close facsimile thereof.  At a minimum I
would think a via placement tool with associated hotkey and a dialog to
select the via properties from the list of netclass or global via
settings and select the net name from the netlist.  I don't believe any
board file changes would be required.  Once again, if I missed something
please elaborate.
Via placement options would be cool.  My patch does 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 10/10/16 23:36, Wayne Stambaugh wrote:

On 10/10/2016 1:25 AM, Strontium wrote:

On 09/10/16 23:11, Wayne Stambaugh wrote:

On 10/8/2016 1:20 PM, Nox wrote:

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

Wayne, respectfully this is where I believe you have missed the point.
If a designer assigns a net to a via, then THEY are responsible for the
WTF moment.  IF Kicad rips up the nets the designer assigned to vias
then KICAD is responsible for the WTF moment.  In one case the designer
screwed up and in the other Kicad screwed the designer over.

Its as simple as that.

My original patch, posted many moons ago, fixed this problem neatly.  It
did not allow a user to assign arbitrary nets, but if you plonked a via
on a GND fill, it had a GND net, and that via would ALWAYS have a GND
net until you did something explicitly to change it.  What is wrong with
that, HOW is that Kicads fault if the user should have plonked it on the
VCC plane.  Its not.  Kicad shouldn't go along behind you ripping up
your design for the hell of it.  I, in fact, laid boards out, which i
believe would be impractical, if not impossible to lay out without this
patch, and i have to keep a version of that kicad around simply because
kicad isn’t up to the task of following my instructions without later
destroying my design intent.

It is not obvious and NOT a DRC violation to have a via go from being
assigned to GND and suddenly being assigned to UNASSIGNED. Boards could
be made like that without the designer knowing they are being messed
with by the DRC pass.  Now the result is the plane it was supposed to
stich is no longer stitched, AND the design intent has been destroyed by
Kicad.

MY opinion, and I know it doesnt count for much, is DRC should NEVER
reassign an net unless it can UNAMBIGUOUSLY PROVE the nets
connectivity.  IF it cant prove the nets connectivity it should leave
the damn net assignment alone.  Throw a DRC Error FINE, but dont change
my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO
LAID IT.  To be completely fair, the whole "Reassign the nets pass" of
Kicad should be able to be disabled, it should generate DRC violations
for net conflicts, but a designer should be able to tell Kicad, HEY DONT
CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD.

If a user wants to manually assign a net, problem belong them, but i
think its worse for Kicad to insist it knows better than the designer
and that is precisely the situation we have now.

Show a case where leaving the via on the net the user assigned when it
was placed causes a design fault VS reassigning to UNASSIGNED (and that
fault is kicads and not the stupidity of the designer) and i will change
my position, but no one has ever been able to show that except for
"Beware monsters" type replies.

AND if one wanted to proceed "Cautiously" just have a global option
"Preserve nets on DRC" which selectively enables my proposed patch, then
users who dont use via stitching can "proceed cautiously" and other who
actually want to get a design out the door can do some work, and not
have to lay tons of superfluous, difficult to manage, and easily screwed
up stitching tracks.

Stront


I wish it were that simple.  How many times have we been beat over the
head about zone refilling?  If you had been part of these discussions,
you would understand why I approach changes like this cautiously.  We
have a large group of users who think kicad shouldn't let them shoot
themselves in the foot and equally large group of power users like
yourself and myself who are willing to accept that responsibility.  It's
balancing act that as project leader I end up being responsible for.

Wayne,

I totally respect your position as project leader and hope that my 
disagreement with you on this issue in no way makes you feel that I 
don’t.  I feel that's important to say because I do value your good 
strong leadership in this project.


The other reason I have been reluctant to use your patch is that almost
the exact same behavior can be duplicated with single pad footprint
which you can arbitrarily place on a board, specify a net, set per pad
solder masking, per pad connection type(thermal, solid, etc.), and
prevent from being ripped up by using the correct settings during net
import.  The only thing this solution doesn't cover is blind/buried vias
so you get a win there.
It can, and it can not.  The problem with this work around is it now 
pollutes the board with true components which are not represented on the 
schematic, rather than copper 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Wayne Stambaugh]

I've thought about this for a while and I'm going to try a different
approach.  Please bear with me, this is going to be lengthy but in the
interest of resolving the via stitching issue properly, I think it needs
to be done.  I'm going to expand on JP's idea that we first define the
problem we are trying to solve before we can arrive at a sound solution.
 It may turn out that there may be a reasonable solution that isn't
terribly difficult to implement without completely rewriting the drc
code or ignoring net connections which have undesirable side effects.

First and foremost is the definition of a via.  A via is a feature that
electrically connects two or more copper features (not just tracks) on
different board layers having the same net.  If we are in agreement with
that, then we should be able to agree that any via that has less than
two connections on different planes to the same net or that connect
copper features on different layers with different nets are design rule
errors.  Have I missed anything here?  I can't think of any valid case
where you would want unconnected (floating) or partially connected (1
connection) vias or vias that short different nets together.  If you can
think of one, please elaborate.

Once this is established, we should fix both the connection algorithm
and the drc to reflect this criteria.  How much work would this be?  I
didn't write either of these pieces of code so I'm going to have to rely
on some feedback here.  I'm not asking for a full rewrite of the drc
code even though that is a noble long term goal.  I'm asking for what it
would take to accommodate the criteria above with the existing code.

If this can be resolved with a reasonable amount of effort, the only
thing that would be left would be implementing the board editor features
to place the vias.  I'm guessing most of the proposed patches address
that issue or a reasonably close facsimile thereof.  At a minimum I
would think a via placement tool with associated hotkey and a dialog to
select the via properties from the list of netclass or global via
settings and select the net name from the netlist.  I don't believe any
board file changes would be required.  Once again, if I missed something
please elaborate.

The only drawback I can see doing it this way would be if someone
inadvertently opened the board with a stable 4 version of kicad the vias
would automatically get rip up.  Please remember, new features don't get
back ported to stable releases.

I think the crucial element is the drc and connection algrithm code.  If
this is too much effort, we could try Nox's suggestion of a user option
to enable or disable Strontium's ignore orphaned via code.  I would
prefer if that we investigate my suggestion before we fallback to this.
If anyone has any useful feedback or has any objections with this, feel
free to comment.

Cheers,

Wayne

On 10/10/2016 12:24 PM, Nox wrote:
> Wayne,
> 
> This sound very resonable and I am totally with you that the proposed
> solutions have their drawbacks like the currently implemented one.
> Actually I would love to see a perfectly working connection recognition
> algorithm like Tomasz suggested (if I got him correctly) but I guess we
> all agree that although this solution would be the best, it will
> mostlikely the solution taking the most time. Additionally I assume
> nobody can garantee that a new solution will cover every single case
> perfectly.
> 
> I think you made there a very important comment regarding "power users"
> vs "careful users" and I totally see your point. What do you think about
> adding an option which defaults to the current behavior (apperently
> floating elements are set as unassigned) and a "let me shoot my self if
> i want to" option which leaves the label of floating elements unchanged
> (maybe adding a warning in the DRC what floating elements exists)? What
> would be your concern regarding this approach?
> 
> 
> Am 10.10.2016 um 17:36 schrieb Wayne Stambaugh:
>> On 10/10/2016 1:25 AM, Strontium wrote:
>>> On 09/10/16 23:11, Wayne Stambaugh wrote:
 On 10/8/2016 1:20 PM, Nox wrote:

 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
>>> Wayne, respectfully this is where I believe you have missed the point.
>>> If a designer assigns a net to a via, then THEY are responsible for the
>>> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
>>> then KICAD is responsible for the WTF moment.  In one case the designer
>>> screwed up and in the 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Heikki Pulkkinen]

Hi,

If you want via stitching tool, why not try my tool. I have sended
suggestion on it few days ago to kicad developers mailing list. Not many
codelines, so it is easy to look what it do.

Regards,

Heikki

10.10.2016 19.35 "Nox"  kirjoitti:

> Wayne,
>
> This sound very resonable and I am totally with you that the proposed
> solutions have their drawbacks like the currently implemented one. Actually
> I would love to see a perfectly working connection recognition algorithm
> like Tomasz suggested (if I got him correctly) but I guess we all agree
> that although this solution would be the best, it will mostlikely the
> solution taking the most time. Additionally I assume nobody can garantee
> that a new solution will cover every single case perfectly.
>
> I think you made there a very important comment regarding "power users" vs
> "careful users" and I totally see your point. What do you think about
> adding an option which defaults to the current behavior (apperently
> floating elements are set as unassigned) and a "let me shoot my self if i
> want to" option which leaves the label of floating elements unchanged
> (maybe adding a warning in the DRC what floating elements exists)? What
> would be your concern regarding this approach?
>
>
> Am 10.10.2016 um 17:36 schrieb Wayne Stambaugh:
>
>> On 10/10/2016 1:25 AM, Strontium wrote:
>>
>>> On 09/10/16 23:11, Wayne Stambaugh wrote:
>>>
 On 10/8/2016 1:20 PM, Nox wrote:

 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

>>> Wayne, respectfully this is where I believe you have missed the point.
>>> If a designer assigns a net to a via, then THEY are responsible for the
>>> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
>>> then KICAD is responsible for the WTF moment.  In one case the designer
>>> screwed up and in the other Kicad screwed the designer over.
>>>
>>> Its as simple as that.
>>>
>>> My original patch, posted many moons ago, fixed this problem neatly.  It
>>> did not allow a user to assign arbitrary nets, but if you plonked a via
>>> on a GND fill, it had a GND net, and that via would ALWAYS have a GND
>>> net until you did something explicitly to change it.  What is wrong with
>>> that, HOW is that Kicads fault if the user should have plonked it on the
>>> VCC plane.  Its not.  Kicad shouldn't go along behind you ripping up
>>> your design for the hell of it.  I, in fact, laid boards out, which i
>>> believe would be impractical, if not impossible to lay out without this
>>> patch, and i have to keep a version of that kicad around simply because
>>> kicad isn’t up to the task of following my instructions without later
>>> destroying my design intent.
>>>
>>> It is not obvious and NOT a DRC violation to have a via go from being
>>> assigned to GND and suddenly being assigned to UNASSIGNED. Boards could
>>> be made like that without the designer knowing they are being messed
>>> with by the DRC pass.  Now the result is the plane it was supposed to
>>> stich is no longer stitched, AND the design intent has been destroyed by
>>> Kicad.
>>>
>>> MY opinion, and I know it doesnt count for much, is DRC should NEVER
>>> reassign an net unless it can UNAMBIGUOUSLY PROVE the nets
>>> connectivity.  IF it cant prove the nets connectivity it should leave
>>> the damn net assignment alone.  Throw a DRC Error FINE, but dont change
>>> my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO
>>> LAID IT.  To be completely fair, the whole "Reassign the nets pass" of
>>> Kicad should be able to be disabled, it should generate DRC violations
>>> for net conflicts, but a designer should be able to tell Kicad, HEY DONT
>>> CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD.
>>>
>>> If a user wants to manually assign a net, problem belong them, but i
>>> think its worse for Kicad to insist it knows better than the designer
>>> and that is precisely the situation we have now.
>>>
>>> Show a case where leaving the via on the net the user assigned when it
>>> was placed causes a design fault VS reassigning to UNASSIGNED (and that
>>> fault is kicads and not the stupidity of the designer) and i will change
>>> my position, but no one has ever been able to show that except for
>>> "Beware monsters" type replies.
>>>
>>> AND if one wanted to proceed "Cautiously" just have a global option
>>> "Preserve nets on DRC" which selectively enables my proposed patch, then
>>> users who dont use via stitching can "proceed cautiously" and 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Nox]

Wayne,

This sound very resonable and I am totally with you that the proposed 
solutions have their drawbacks like the currently implemented one. 
Actually I would love to see a perfectly working connection recognition 
algorithm like Tomasz suggested (if I got him correctly) but I guess we 
all agree that although this solution would be the best, it will 
mostlikely the solution taking the most time. Additionally I assume 
nobody can garantee that a new solution will cover every single case 
perfectly.


I think you made there a very important comment regarding "power users" 
vs "careful users" and I totally see your point. What do you think about 
adding an option which defaults to the current behavior (apperently 
floating elements are set as unassigned) and a "let me shoot my self if 
i want to" option which leaves the label of floating elements unchanged 
(maybe adding a warning in the DRC what floating elements exists)? What 
would be your concern regarding this approach?



Am 10.10.2016 um 17:36 schrieb Wayne Stambaugh:

On 10/10/2016 1:25 AM, Strontium wrote:

On 09/10/16 23:11, Wayne Stambaugh wrote:

On 10/8/2016 1:20 PM, Nox wrote:

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

Wayne, respectfully this is where I believe you have missed the point.
If a designer assigns a net to a via, then THEY are responsible for the
WTF moment.  IF Kicad rips up the nets the designer assigned to vias
then KICAD is responsible for the WTF moment.  In one case the designer
screwed up and in the other Kicad screwed the designer over.

Its as simple as that.

My original patch, posted many moons ago, fixed this problem neatly.  It
did not allow a user to assign arbitrary nets, but if you plonked a via
on a GND fill, it had a GND net, and that via would ALWAYS have a GND
net until you did something explicitly to change it.  What is wrong with
that, HOW is that Kicads fault if the user should have plonked it on the
VCC plane.  Its not.  Kicad shouldn't go along behind you ripping up
your design for the hell of it.  I, in fact, laid boards out, which i
believe would be impractical, if not impossible to lay out without this
patch, and i have to keep a version of that kicad around simply because
kicad isn’t up to the task of following my instructions without later
destroying my design intent.

It is not obvious and NOT a DRC violation to have a via go from being
assigned to GND and suddenly being assigned to UNASSIGNED. Boards could
be made like that without the designer knowing they are being messed
with by the DRC pass.  Now the result is the plane it was supposed to
stich is no longer stitched, AND the design intent has been destroyed by
Kicad.

MY opinion, and I know it doesnt count for much, is DRC should NEVER
reassign an net unless it can UNAMBIGUOUSLY PROVE the nets
connectivity.  IF it cant prove the nets connectivity it should leave
the damn net assignment alone.  Throw a DRC Error FINE, but dont change
my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO
LAID IT.  To be completely fair, the whole "Reassign the nets pass" of
Kicad should be able to be disabled, it should generate DRC violations
for net conflicts, but a designer should be able to tell Kicad, HEY DONT
CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD.

If a user wants to manually assign a net, problem belong them, but i
think its worse for Kicad to insist it knows better than the designer
and that is precisely the situation we have now.

Show a case where leaving the via on the net the user assigned when it
was placed causes a design fault VS reassigning to UNASSIGNED (and that
fault is kicads and not the stupidity of the designer) and i will change
my position, but no one has ever been able to show that except for
"Beware monsters" type replies.

AND if one wanted to proceed "Cautiously" just have a global option
"Preserve nets on DRC" which selectively enables my proposed patch, then
users who dont use via stitching can "proceed cautiously" and other who
actually want to get a design out the door can do some work, and not
have to lay tons of superfluous, difficult to manage, and easily screwed
up stitching tracks.

Stront


I wish it were that simple.  How many times have we been beat over the
head about zone refilling?  If you had been part of these discussions,
you would understand why I approach changes like this cautiously.  We
have a large group of users who think kicad shouldn't let them shoot
themselves in the foot and equally large group of power users like
yourself and 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Wayne Stambaugh]

On 10/10/2016 1:25 AM, Strontium wrote:
> On 09/10/16 23:11, Wayne Stambaugh wrote:
>> On 10/8/2016 1:20 PM, Nox wrote:
>>
>> 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
> Wayne, respectfully this is where I believe you have missed the point. 
> If a designer assigns a net to a via, then THEY are responsible for the
> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
> then KICAD is responsible for the WTF moment.  In one case the designer
> screwed up and in the other Kicad screwed the designer over.
> 
> Its as simple as that.
> 
> My original patch, posted many moons ago, fixed this problem neatly.  It
> did not allow a user to assign arbitrary nets, but if you plonked a via
> on a GND fill, it had a GND net, and that via would ALWAYS have a GND
> net until you did something explicitly to change it.  What is wrong with
> that, HOW is that Kicads fault if the user should have plonked it on the
> VCC plane.  Its not.  Kicad shouldn't go along behind you ripping up
> your design for the hell of it.  I, in fact, laid boards out, which i
> believe would be impractical, if not impossible to lay out without this
> patch, and i have to keep a version of that kicad around simply because
> kicad isn’t up to the task of following my instructions without later
> destroying my design intent.
> 
> It is not obvious and NOT a DRC violation to have a via go from being
> assigned to GND and suddenly being assigned to UNASSIGNED. Boards could
> be made like that without the designer knowing they are being messed
> with by the DRC pass.  Now the result is the plane it was supposed to
> stich is no longer stitched, AND the design intent has been destroyed by
> Kicad.
> 
> MY opinion, and I know it doesnt count for much, is DRC should NEVER
> reassign an net unless it can UNAMBIGUOUSLY PROVE the nets
> connectivity.  IF it cant prove the nets connectivity it should leave
> the damn net assignment alone.  Throw a DRC Error FINE, but dont change
> my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO
> LAID IT.  To be completely fair, the whole "Reassign the nets pass" of
> Kicad should be able to be disabled, it should generate DRC violations
> for net conflicts, but a designer should be able to tell Kicad, HEY DONT
> CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD.
> 
> If a user wants to manually assign a net, problem belong them, but i
> think its worse for Kicad to insist it knows better than the designer
> and that is precisely the situation we have now.
> 
> Show a case where leaving the via on the net the user assigned when it
> was placed causes a design fault VS reassigning to UNASSIGNED (and that
> fault is kicads and not the stupidity of the designer) and i will change
> my position, but no one has ever been able to show that except for
> "Beware monsters" type replies.
> 
> AND if one wanted to proceed "Cautiously" just have a global option
> "Preserve nets on DRC" which selectively enables my proposed patch, then
> users who dont use via stitching can "proceed cautiously" and other who
> actually want to get a design out the door can do some work, and not
> have to lay tons of superfluous, difficult to manage, and easily screwed
> up stitching tracks.
> 
> Stront
> 

I wish it were that simple.  How many times have we been beat over the
head about zone refilling?  If you had been part of these discussions,
you would understand why I approach changes like this cautiously.  We
have a large group of users who think kicad shouldn't let them shoot
themselves in the foot and equally large group of power users like
yourself and myself who are willing to accept that responsibility.  It's
balancing act that as project leader I end up being responsible for.

The other reason I have been reluctant to use your patch is that almost
the exact same behavior can be duplicated with single pad footprint
which you can arbitrarily place on a board, specify a net, set per pad
solder masking, per pad connection type(thermal, solid, etc.), and
prevent from being ripped up by using the correct settings during net
import.  The only thing this solution doesn't cover is blind/buried vias
so you get a win there.

If you provide a solution for vias, that forces the user to assign a
valid net then I would be more receptive to your solution.  I'm fine if
you default the net assignment to a copper feature that also has an
assigned net that intersects with the via but the user should always
have to select a valid net for a via.  I will not accept a 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Torsten Hüter]

Hi Strontium,

 

I've just checked that, my latest design uses 1252 stitch vias (medium complexity board, 4 layers). I'm a professional KiCad user (I'm not using KiCad for private projects) and I've given our employees the same hint. We have done of course some RF designs as well. You can move the stitch vias around just like any component.

Also I like that I can control some pad properties like the mask opening.

 

Thanks,

Torsten

 



 



Hello Torsten,

I can clearly understand why you went down this road.

The patch I proposed handles all kinds of vias, blind, buried and through.  And doesn’t require a special component.  The problem I had with the "special component" which I did try, possibly after reading one of your posts, is you either have tons of them matching on your Schematic, OR you have tons of manually placed components with no schematic representation.  Neither of which feels like a great solution to me, I dont consider a via as a Component, regardless of if its stitching or not. 

And lets put the problem into perspective for people who havent used stitching vias, when I say a "ton" of vias, I mean potentially hundreds of them in a very small area.  Its not just one or two.  RF Designs require them at small (tiny) intervals down the edges of fills as guards and regularly placed throughout your fill zones to reduce capacitance between the gnd layers.  Its a HUGE problem for people who need to use them, not just some minor annoyance.  And then you do something like move a resistor, and suddenly your gnd layer reflows around it, well now you have to restitch that new area.  Its a whole lot easier to just move existing vias around.

Stront
 






___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[jp charras]

Le 10/10/2016 à 14:59, "Torsten Hüter" a écrit :
> Hi Jean-Pierre,
>  
> I have done several designs with KiCad and stitch vias. The simplest way for 
> me is to create a
> module with a single through hole pad.
> I've even written a python script to automate the placement of these stitch 
> vias (see the mailing
> list archive). That was never a big problem and works well with the stable 
> KiCad version, no issues
> with zone filling or net calculations.

Yes, I tried it and it works.
>  
> I'm guessing that Altium PCB using a special primitive for stitch vias as 
> well.
> See http://techdocs.altium.com/display/ADOH/Via+Stitching
>  
> Only blind vias or burried vias are not possible when using a single pad 
> module; Altium uses the
> start and end layer as attribute for these purposes.

It could be worth to also use some attribute to group stitching vias in Kicad.
In fact, as I previously wrote, defining how "stitching vias" are managed is 
the first work to do.
(the more basic way is to use the time stamp to group vias, but this is a very 
basic management, but
at least it allows placing/removing a group of vias)

Blind vias or buried vias could be possible when using a single pad module, 
because pads have a
layer mask to define the copper layers where they live,.
However, pad dialog properties does not handle "buried pads", but most of pad 
functions should
support them.

>  
> --
>  
> So maybe having free pads with similar attributes - like Altium is using - is 
> here an alternative
> solution. Also for mounting holes as well (currently you need to create a 
> module for them).
>  
> Thanks,
> Torsten
>  
> 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.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

Hello Torsten,

I can clearly understand why you went down this road.

The patch I proposed handles all kinds of vias, blind, buried and 
through.  And doesn’t require a special component.  The problem I had 
with the "special component" which I did try, possibly after reading one 
of your posts, is you either have tons of them matching on your 
Schematic, OR you have tons of manually placed components with no 
schematic representation.  Neither of which feels like a great solution 
to me, I dont consider a via as a Component, regardless of if its 
stitching or not.


And lets put the problem into perspective for people who havent used 
stitching vias, when I say a "ton" of vias, I mean potentially hundreds 
of them in a very small area.  Its not just one or two.  RF Designs 
require them at small (tiny) intervals down the edges of fills as guards 
and regularly placed throughout your fill zones to reduce capacitance 
between the gnd layers.  Its a HUGE problem for people who need to use 
them, not just some minor annoyance.  And then you do something like 
move a resistor, and suddenly your gnd layer reflows around it, well now 
you have to restitch that new area.  Its a whole lot easier to just move 
existing vias around.


Stront

On 10/10/16 20:59, "Torsten Hüter" wrote:

Hi Jean-Pierre,
I have done several designs with KiCad and stitch vias. The simplest 
way for me is to create a module with a single through hole pad.
I've even written a python script to automate the placement of these 
stitch vias (see the mailing list archive). That was never a big 
problem and works well with the stable KiCad version, no issues with 
zone filling or net calculations.
I'm guessing that Altium PCB using a special primitive for stitch vias 
as well.

See http://techdocs.altium.com/display/ADOH/Via+Stitching
Only blind vias or burried vias are not possible when using a single 
pad module; Altium uses the start and end layer as attribute for these 
purposes.

--
So maybe having free pads with similar attributes - like Altium is 
using - is here an alternative solution. Also for mounting holes as 
well (currently you need to create a module for them).

Thanks,
Torsten
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.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Tomasz Wlostowski]

On 10.10.2016 14:59, "Torsten Hüter" wrote:
> I'm guessing that Altium PCB using a special primitive for stitch vias
> as well.

Hi Torsten,

I don't think so (Altium 15 here). It just groups ordinary vias into an
union (another feature people have been asking for).

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Torsten Hüter]

Hi Jean-Pierre,

 

I have done several designs with KiCad and stitch vias. The simplest way for me is to create a module with a single through hole pad.

I've even written a python script to automate the placement of these stitch vias (see the mailing list archive). That was never a big problem and works well with the stable KiCad version, no issues with zone filling or net calculations.

 

I'm guessing that Altium PCB using a special primitive for stitch vias as well.

See http://techdocs.altium.com/display/ADOH/Via+Stitching

 

Only blind vias or burried vias are not possible when using a single pad module; Altium uses the start and end layer as attribute for these purposes.

 

--

 

So maybe having free pads with similar attributes - like Altium is using - is here an alternative solution. Also for mounting holes as well (currently you need to create a module for them).

 

Thanks,

Torsten

 



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.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Tomasz Wlostowski]

On 10.10.2016 14:16, Strontium wrote:
> On 10/10/16 19:43, Tomasz Wlostowski wrote:
>> On 10.10.2016 07:25, Strontium wrote:
>>> On 09/10/16 23:11, Wayne Stambaugh wrote:
 On 10/8/2016 1:20 PM, Nox wrote:

 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
>>> Wayne, respectfully this is where I believe you have missed the point.
>>> If a designer assigns a net to a via, then THEY are responsible for the
>>> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
>>> then KICAD is responsible for the WTF moment.  In one case the designer
>>> screwed up and in the other Kicad screwed the designer over.
>>>
>>> Its as simple as that.
>>>
>>> My original patch, posted many moons ago, fixed this problem neatly.  It
>>> did not allow a user to assign arbitrary nets, but if you plonked a via
>>> on a GND fill, it had a GND net, and that via would ALWAYS have a GND
>>> net until you did something explicitly to change it.
>> Don't shout man What if your board has more than two layers. For
>> instance, there's a full VCC plane on one internal layer and another
>> full GND plane on another internal layer? Which plane the via you place
>> would belong to if vias were to take their nets from copper fills?
>>
>> Cheers,
>> Tom
>>
> Hi Tom,
> 
> Its very simple, you place the via on the layer you want to stitch.
> Just like when you want to lay a track.

Aah, so the the net would be assigned right after the placement. I
perhaps misunderstood you. Looks OK for me.

Tom





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 10/10/16 19:43, Tomasz Wlostowski wrote:

On 10.10.2016 07:25, Strontium wrote:

On 09/10/16 23:11, Wayne Stambaugh wrote:

On 10/8/2016 1:20 PM, Nox wrote:

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

Wayne, respectfully this is where I believe you have missed the point.
If a designer assigns a net to a via, then THEY are responsible for the
WTF moment.  IF Kicad rips up the nets the designer assigned to vias
then KICAD is responsible for the WTF moment.  In one case the designer
screwed up and in the other Kicad screwed the designer over.

Its as simple as that.

My original patch, posted many moons ago, fixed this problem neatly.  It
did not allow a user to assign arbitrary nets, but if you plonked a via
on a GND fill, it had a GND net, and that via would ALWAYS have a GND
net until you did something explicitly to change it.

Don't shout man What if your board has more than two layers. For
instance, there's a full VCC plane on one internal layer and another
full GND plane on another internal layer? Which plane the via you place
would belong to if vias were to take their nets from copper fills?

Cheers,
Tom


Hi Tom,

Its very simple, you place the via on the layer you want to stitch.  
Just like when you want to lay a track.


You want a GND Via, place it on the GND plane fill.  You want a VCC Via, 
place it on the VCC plane fill. You can do that now and it works fine.  
Try it.  The problem is you then run DRC and kicad will destroy your 
design.  So KiCad lets you do it with one hand, only to take it away 
with the other.  When it first happens to you its both jarring and 
disconcerting.


Sincere apologies if my post is seen as shouting, I just find the whole 
nonsense revolving around this issue very frustrating.


Steven/Stront


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Tomasz Wlostowski]

On 10.10.2016 07:25, Strontium wrote:
> On 09/10/16 23:11, Wayne Stambaugh wrote:
>> On 10/8/2016 1:20 PM, Nox wrote:
>>
>> 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
> Wayne, respectfully this is where I believe you have missed the point. 
> If a designer assigns a net to a via, then THEY are responsible for the
> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
> then KICAD is responsible for the WTF moment.  In one case the designer
> screwed up and in the other Kicad screwed the designer over.
> 
> Its as simple as that.
> 
> My original patch, posted many moons ago, fixed this problem neatly.  It
> did not allow a user to assign arbitrary nets, but if you plonked a via
> on a GND fill, it had a GND net, and that via would ALWAYS have a GND
> net until you did something explicitly to change it.  

Don't shout man What if your board has more than two layers. For
instance, there's a full VCC plane on one internal layer and another
full GND plane on another internal layer? Which plane the via you place
would belong to if vias were to take their nets from copper fills?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Collin Anderson]

I'm in agreement as well. 

Windows treats the user like a child.  It assumes you don't know what you're 
doing, and just about all of the design decisions in Windows  can ultimately be 
traced back to the premise that the user is probably stupid.  Well, not stupid, 
but largely ignorant/inexperienced in regard to computers.  

This is not a bad thing - most people use Windows, and most people are not 
particularly computer savvy, so this makes a lot of sense.

The downside of this is that Windows is incredibly frustrating, inflexible, and 
relatively powerless in the hands of a power user.  This begins with 
installation. Have any of you ever tried to Install Windows to a drive that 
wasn't enumerated as the first/zeroth drive?  

You can't.  Surely the user made a mistake. Or because the user won't know how 
to boot from a second drive.

To install Windows on a second drive, you have to physically disconnect all 
other drives from the SATA bus (lol if you have several PCIE SSDs, then it's an 
extra pain in the ass).  

So the question we need to ask is who is KiCad meant for? 

Is it indented for makers who are learning and do this as a hobby, that are 
helpless without an Arduino? Is KiCad intended to be for people who came from 
using Fritzing? 

If so, then KiCad should treat the user like a child and assume they didn't 
mean to do something.  Assume it was a mistake.  KiCad can be the Microsoft 
Word of EDA.  It will just change your shit because it knows what you wanted to 
do better than you.  We can even have a talking 1/4W through hole resistor 
character named Ohmer, who is poorly animated with CGI from 1995, randomly pop 
up to try to help people with their arduino shield.  

Or is KiCad intended to be a professional tool used by real engineers who 
actually know how to design electronics? Is KiCad intended to be powerful? 

If so, then KiCad should treat the user like an adult. It should expect the 
user to be responsible for their actions, and certainly warn them about things 
that might be mistakes or accidents.  This is the entire point of DRC.  But, 
maybe I know what I'm doing and maybe KiCad should assume that and let me 
proceed.  

Right now, I have a bunch of footprints that I use to "fake" vias for via 
stitching.  ghetto_vias.pretty.  I have to copy and paste them manually, and 
manually set the net, and if I ever make any changes that involves removing 
components, I'm screwed.  I can either have all my ghetto_vias get wiped out 
along with footprints I wanted removed, or I can manually delete the extra 
footprints which gets dicey on a large board and maybe the changes I did were 
significant.  

Now, since they're footprints, I also lose push and shove ability.  

Stront's patch is perfect and should not only be included, but the default 
behavior.  But I'll settle for included but needs to be turned on in the 
preferences. 



> On Oct 9, 2016, at 11:35 PM, Chris Pavlina  wrote:
> 
> ...yes. All of this.
> 
> 
>> On Oct 10, 2016 01:25, "Strontium"  wrote:
>>> On 09/10/16 23:11, Wayne Stambaugh wrote:
>>> On 10/8/2016 1:20 PM, Nox wrote:
>>> 
>>> 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
>> Wayne, respectfully this is where I believe you have missed the point.  If a 
>> designer assigns a net to a via, then THEY are responsible for the WTF 
>> moment.  IF Kicad rips up the nets the designer assigned to vias then KICAD 
>> is responsible for the WTF moment.  In one case the designer screwed up and 
>> in the other Kicad screwed the designer over.
>> 
>> Its as simple as that.
>> 
>> My original patch, posted many moons ago, fixed this problem neatly.  It did 
>> not allow a user to assign arbitrary nets, but if you plonked a via on a GND 
>> fill, it had a GND net, and that via would ALWAYS have a GND net until you 
>> did something explicitly to change it.  What is wrong with that, HOW is that 
>> Kicads fault if the user should have plonked it on the VCC plane.  Its not.  
>> Kicad shouldn't go along behind you ripping up your design for the hell of 
>> it.  I, in fact, laid boards out, which i believe would be impractical, if 
>> not impossible to lay out without this patch, and i have to keep a version 
>> of that kicad around simply because kicad isn’t up to the task of following 
>> my instructions without later destroying my design intent.
>> 
>> It is not obvious and NOT a DRC violation to have a via go from being 
>> assigned to GND and suddenly being 

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Chris Pavlina]

...yes. All of this.

On Oct 10, 2016 01:25, "Strontium"  wrote:

> On 09/10/16 23:11, Wayne Stambaugh wrote:
>
>> On 10/8/2016 1:20 PM, Nox wrote:
>>
>> 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
>>
> Wayne, respectfully this is where I believe you have missed the point.  If
> a designer assigns a net to a via, then THEY are responsible for the WTF
> moment.  IF Kicad rips up the nets the designer assigned to vias then KICAD
> is responsible for the WTF moment.  In one case the designer screwed up and
> in the other Kicad screwed the designer over.
>
> Its as simple as that.
>
> My original patch, posted many moons ago, fixed this problem neatly.  It
> did not allow a user to assign arbitrary nets, but if you plonked a via on
> a GND fill, it had a GND net, and that via would ALWAYS have a GND net
> until you did something explicitly to change it.  What is wrong with that,
> HOW is that Kicads fault if the user should have plonked it on the VCC
> plane.  Its not.  Kicad shouldn't go along behind you ripping up your
> design for the hell of it.  I, in fact, laid boards out, which i believe
> would be impractical, if not impossible to lay out without this patch, and
> i have to keep a version of that kicad around simply because kicad isn’t up
> to the task of following my instructions without later destroying my design
> intent.
>
> It is not obvious and NOT a DRC violation to have a via go from being
> assigned to GND and suddenly being assigned to UNASSIGNED. Boards could be
> made like that without the designer knowing they are being messed with by
> the DRC pass.  Now the result is the plane it was supposed to stich is no
> longer stitched, AND the design intent has been destroyed by Kicad.
>
> MY opinion, and I know it doesnt count for much, is DRC should NEVER
> reassign an net unless it can UNAMBIGUOUSLY PROVE the nets connectivity.
> IF it cant prove the nets connectivity it should leave the damn net
> assignment alone.  Throw a DRC Error FINE, but dont change my design. And
> it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO LAID IT.  To be
> completely fair, the whole "Reassign the nets pass" of Kicad should be able
> to be disabled, it should generate DRC violations for net conflicts, but a
> designer should be able to tell Kicad, HEY DONT CHANGE MY DESIGN JUST DO
> WHAT YOU ARE TOLD.
>
> If a user wants to manually assign a net, problem belong them, but i think
> its worse for Kicad to insist it knows better than the designer and that is
> precisely the situation we have now.
>
> Show a case where leaving the via on the net the user assigned when it was
> placed causes a design fault VS reassigning to UNASSIGNED (and that fault
> is kicads and not the stupidity of the designer) and i will change my
> position, but no one has ever been able to show that except for "Beware
> monsters" type replies.
>
> AND if one wanted to proceed "Cautiously" just have a global option
> "Preserve nets on DRC" which selectively enables my proposed patch, then
> users who dont use via stitching can "proceed cautiously" and other who
> actually want to get a design out the door can do some work, and not have
> to lay tons of superfluous, difficult to manage, and easily screwed up
> stitching tracks.
>
> Stront
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Strontium]

On 09/10/16 23:11, Wayne Stambaugh wrote:

On 10/8/2016 1:20 PM, Nox wrote:

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
Wayne, respectfully this is where I believe you have missed the point.  
If a designer assigns a net to a via, then THEY are responsible for the 
WTF moment.  IF Kicad rips up the nets the designer assigned to vias 
then KICAD is responsible for the WTF moment.  In one case the designer 
screwed up and in the other Kicad screwed the designer over.


Its as simple as that.

My original patch, posted many moons ago, fixed this problem neatly.  It 
did not allow a user to assign arbitrary nets, but if you plonked a via 
on a GND fill, it had a GND net, and that via would ALWAYS have a GND 
net until you did something explicitly to change it.  What is wrong with 
that, HOW is that Kicads fault if the user should have plonked it on the 
VCC plane.  Its not.  Kicad shouldn't go along behind you ripping up 
your design for the hell of it.  I, in fact, laid boards out, which i 
believe would be impractical, if not impossible to lay out without this 
patch, and i have to keep a version of that kicad around simply because 
kicad isn’t up to the task of following my instructions without later 
destroying my design intent.


It is not obvious and NOT a DRC violation to have a via go from being 
assigned to GND and suddenly being assigned to UNASSIGNED. Boards could 
be made like that without the designer knowing they are being messed 
with by the DRC pass.  Now the result is the plane it was supposed to 
stich is no longer stitched, AND the design intent has been destroyed by 
Kicad.


MY opinion, and I know it doesnt count for much, is DRC should NEVER 
reassign an net unless it can UNAMBIGUOUSLY PROVE the nets 
connectivity.  IF it cant prove the nets connectivity it should leave 
the damn net assignment alone.  Throw a DRC Error FINE, but dont change 
my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO 
LAID IT.  To be completely fair, the whole "Reassign the nets pass" of 
Kicad should be able to be disabled, it should generate DRC violations 
for net conflicts, but a designer should be able to tell Kicad, HEY DONT 
CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD.


If a user wants to manually assign a net, problem belong them, but i 
think its worse for Kicad to insist it knows better than the designer 
and that is precisely the situation we have now.


Show a case where leaving the via on the net the user assigned when it 
was placed causes a design fault VS reassigning to UNASSIGNED (and that 
fault is kicads and not the stupidity of the designer) and i will change 
my position, but no one has ever been able to show that except for 
"Beware monsters" type replies.


AND if one wanted to proceed "Cautiously" just have a global option 
"Preserve nets on DRC" which selectively enables my proposed patch, then 
users who dont use via stitching can "proceed cautiously" and other who 
actually want to get a design out the door can do some work, and not 
have to lay tons of superfluous, difficult to manage, and easily screwed 
up stitching tracks.


Stront



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[jp charras]

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

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Wayne Stambaugh]

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

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Nox]

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 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
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Nox]

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.


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
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[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
> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] pcbnew - enable editing of associated net for tracks

[Nox]

Hello,

what do you guys think about enabling edit of net names for tracks 
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp