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] [PATCH] Footprint Wizards Update

[Oliver Walters]

Anyone have any comments on this? I have fixed many issues that were raised
last time. If I can get some feedback, we can progress towards merge.

On Thu, Sep 29, 2016 at 6:18 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Hi All,
>
> I have improved upon the footprint wizards patch, taking suggestions into
> account.
>
> patch file attached.
>
> There is an in-depth discussion of the new format: https://github.com/
> KiCad/Footprint_Wizards/wiki
>
> In particular, instructions on how to update old wizards to the new format:
>
> https://github.com/KiCad/Footprint_Wizards/wiki/Updating-Older-Wizards
>
> Cheers,
>
> Oliver
>
___
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] dummy copper zone - edge cuts are not subtracted

[Nick Østergaard]

I think it has been like this for a very long time. But if you
actually have the zone connect to something it will fill properly. I
think it is a bug, but I don't really know what the design goal was.

2016-10-09 20:41 GMT+02:00 Mário Luzeiro :
> As an additional note:
> - When I export to VRML, the internal copper holes are removed (so, not 
> coherent)
> - Export as gerbers, it shows as pcbnew.
> 
> From: Mário Luzeiro
> Sent: 09 October 2016 19:02
> To: kicad-developers@lists.launchpad.net
> Subject: dummy copper zone - edge cuts are not subtracted
>
> Hi all,
>
> I am doing some artwork using pcbnew ;)
>
> I found that if I add a dummy copper zone, the zone is completely filled and 
> dont take in consideration the edgecuts of the board (but it takes in 
> consideration the clearance of the zone)
>
> Is it expected? or makes sense to be fixed?
>
> 3D Viewer will render exactly as is is on PCBnew. i.e with copper floating 
> outside the board..
>
> Regards,
> Mario Luzeiro
>
> ___
> 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] dummy copper zone - edge cuts are not subtracted

[Mário Luzeiro]

As an additional note:
- When I export to VRML, the internal copper holes are removed (so, not 
coherent)
- Export as gerbers, it shows as pcbnew.

From: Mário Luzeiro
Sent: 09 October 2016 19:02
To: kicad-developers@lists.launchpad.net
Subject: dummy copper zone - edge cuts are not subtracted

Hi all,

I am doing some artwork using pcbnew ;)

I found that if I add a dummy copper zone, the zone is completely filled and 
dont take in consideration the edgecuts of the board (but it takes in 
consideration the clearance of the zone)

Is it expected? or makes sense to be fixed?

3D Viewer will render exactly as is is on PCBnew. i.e with copper floating 
outside the board..

Regards,
Mario Luzeiro

___
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] dummy copper zone - edge cuts are not subtracted

[Mário Luzeiro]

Hi all,

I am doing some artwork using pcbnew ;)

I found that if I add a dummy copper zone, the zone is completely filled and 
dont take in consideration the edgecuts of the board (but it takes in 
consideration the clearance of the zone)

Is it expected? or makes sense to be fixed?

3D Viewer will render exactly as is is on PCBnew. i.e with copper floating 
outside the board..

Regards,
Mario Luzeiro___
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] [PATCH] remove_boost_thread_dependency.patch

[Wayne Stambaugh]

Patch committed in the product repo.  Thank you for your contribution to
KiCad.

Cheers,

Wayne

On 7/4/2016 6:44 PM, Michael Steinberg wrote:
> Please excuse my stupidity #2.
> 
> Remove dependency on boost::thread.
> 
> 
> 
> ___
> 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

[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] [PATCH 16/16] Clean up warnings from exception handlers

[Wayne Stambaugh]

Simon,

This patch is failing to apply cleanly.  Please rebase and resubmit it
when you get a chance and I will merge it.  Sorry about the issues and
the delay.

Thanks,

Wayne

On 6/7/2016 3:54 PM, Simon Richter wrote:
> 
> The exception objects caught are either not referenced at all, or only in
> debug builds. This avoids the warnings for the unused variables.
> ---
>  eeschema/class_libentry.cpp| 2 +-
>  eeschema/class_library.cpp | 4 ++--
>  eeschema/cross-probing.cpp | 2 +-
>  eeschema/dialogs/dialog_bom.cpp| 2 +-
>  eeschema/eeschema_config.cpp   | 6 +++---
>  eeschema/lib_export.cpp| 2 +-
>  eeschema/project_rescue.cpp| 4 ++--
>  eeschema/schframe.cpp  | 2 +-
>  eeschema/symbedit.cpp  | 2 +-
>  pcb_calculator/datafile_read_write.cpp | 2 +-
>  pcbnew/class_module.cpp| 2 +-
>  pcbnew/dialogs/wizard_add_fplib.cpp| 2 +-
>  pcbnew/moduleframe.cpp | 8 
>  utils/idftools/idf_parser.cpp  | 8 
>  14 files changed, 24 insertions(+), 24 deletions(-)
> 
> 
> 
> ___
> 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