Re: [Kicad-developers] GitLab migration

[Strontium]

My 2c

"As Designed" should be the only answer.  Bug is subjective.  If the 
user thinks the designed behaviour is
broken then they will always think of it as a bug.  Invalid is worse, 
because yes it tells the user they are an idiot.


Even if the program is working "As Designed" it does not mean its 
fantastic, or couldn't be improved, also saying "as designed" does not 
make any comment about the person logging the report (The other two 
do).  If someone spends a reasonable amount of time filling out a bug 
report, then there may be work needed to an area even if it is working 
"As Designed". Marking it "As Designed" would allow the conversation to 
continue about what specifically regarding the "As Designed" behaviour 
is problematic.  "Invalid" and "Not a Bug" cut off continued dialogue 
and look dogmatic/arrogant.


Steven

On 12/10/19 9:36 pm, Jeff Young wrote:

The main thing I didn’t like in the Launchpad workflow was the “Invalid” tag.  
After one of our users spends a lot of time (or even a little) logging a bug, 
it often gets their back up if you mark it “invalid”.

(In the past I’ve used systems that labelled this either “Not a Bug” or “As 
Designed”.  The later is probably the least triggering.)

Cheers,
Jeff.



On 12 Oct 2019, at 10:57, Nick Østergaard  wrote:

The document is still open for comments on
https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing

On Thu, 10 Oct 2019 at 11:30, Ian McInerney  wrote:

On a similar note, the issue workflow will need to be modified if the GitLab 
tracker is used. Unfortunately, GitLab doesn't seem to have the same 
functionality as the Launchpad tracker with respect to issue status and 
severity. This might be a good time to finalize the earlier work that Nick had 
started to formalize the issue process and the bug tracker workflow before we 
transition to the GitLab tracker. That way we can define how we want to do this 
from the outset. This will probably require some trial and error and 
discussions to fully work it out.

-Ian

On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski  wrote:

On 10/10/19 2:30 AM, Andrew Lutsenko wrote:


In terms of issues migration I think moving open issues via script and
locking down launchpad tracker is the best option. Even if migrated
issues and comments on them will be owned by some service account/bot.
It should be doable to include enough information there so that it's
clear who originally posted it and the context is not lost.

I agree, I am not sure if there is any added value in having correct
authors assigned to issues/comments, compared to displaying the
information in the contents field. Since I have spent some time
scripting both Launchpad and Gitlab, let me see how it can be done.

Cheers,
Orson

___
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

___
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




___
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] [RFC] Symbols and Pin mapping in v6 - Proposal

[Strontium]

Hello Ian,

I can see your point, and it has merit.  But its a design choice.  As is 
the design choice to lay out the schematic by function.  For complex 
MCU's (and lets face it, these days all MCU's are complex with regard to 
functionality).  I think that really they should just be defined as 
pins, and the selectable functions of those pins, and said attributes.  
Then how they get arranged and laid out be left up to the designer. I 
also believe that information like THIS pin is powered by VCC2 is also 
useful, as well as the current limits (pin/group).  How that gets 
exposed on the schematic, or what information it supplies to the PCB 
design is a different matter. I firmly agree that I don't think hard 
defining functional units is a good idea.


I often do stuff like take a part of one functional unit, lets say the 
SPI.  Now i don't need its clock, or its input pin, but I can use its 
output pin, and then use the SPI hardware to generate waveforms at a 
particular rate. Or the Uarts, I don't need TX, but i will use RX. Or i 
will mux RX and TX onto the same pin and go half duplex.  The breakdown 
into functional units is non-trivial, they shouldn't be encoded, more 
than just PIN 6, I2C2, SDA or something like that.  Its also valid for a 
lot of chips to have the same functional output on multiple pins.  Or to 
have multiple functional unit inputs simultaneously active on one pin.


Not all chips even break the io down into different power domains, or if 
they do the designer sets them all to 3.3V anyway, and they aren't 
driving any significant load, so the load characteristics become non 
important.  This is something only the designer knows and the part 
definition shouldn't be limited just because power loads may be 
important to some designers.


If i want to draw a schematic, and have a SPI page, that's got the SPI 
port pins I use, and the hardware it attaches to, i should be able to 
draw that.  I can now, but i have to redraw/redefine the MCU to 
accommodate it.


Further, port power domain information isn't (in any serious way) 
captured by kicad schematics now.  The MCU's are rather simplistic.  
Take (a random example) the LPC2142FBD64.  Its got 3 x VDD, 1 x VDDA and 
VBAT.  How are they connected to the io pins, who knows.  They are just 
arranged along the top of the big long MCU box.  Sure, the part has P0 
down the left and P1 on the right, but it doesn't even define what those 
pins are. Let alone what power domains they belong to.  P0 has 32 IO, 
its quite possible they are in multiple power domains.  There is nothing 
that says P0 MUST all share the same power domain. I am guessing these 
pins have a lot of functionality, its not exposed by the part at all.  
Maybe there are parts that do show power domains for ports, i just 
haven't seen any.


If a designer wants to organise by function they should have that 
flexibility.  If the designer wants to organise by port/power domain, 
that should also be supported. Neither should require the MCU part to be 
graphically defined umpteen times, just to suit a particular layout. The 
tool should be flexible enough to do it, and be not artificially limited 
to one particular design preference.  Schematics are, after all, 
artworks and what is attractive to some of us will not appeal to others, 
and vice versa.


Steven


On 17/9/19 5:03 pm, Ian McInerney wrote:
Unfortunately, no I don't agree that the grouping should be by 
peripheral. The purpose of a schematic is to capture the electrical 
connections of a circuit, and allow the designer to reason about it. 
On most chips, the electrical specifications of the same peripheral 
type can differ between instances (e.g. I2C0 has different specs than 
I2C1 because they use different pins).


The most useful grouping for capturing these differences are the ports 
(since those map to the raw pins). The electrical characteristics are 
usually defined on a per-port basis (so all pins of a port will 
usually share the same Vcc, contribute to a per-port current 
limitation, have the same voltage tolerance, etc). If you abstract the 
IC into the peripheral functions, it becomes a lot harder to analyze 
the electrical characteristics when doing a proper design. For 
instance, say you want to use the STM32F413ZH. This chip has multiple 
SPI ports, but one of them (SPI1) has pins that are not 5v tolerant, 
and are only 3.3v tolerant. It becomes easier to analyze and work with 
when you group by port/pins because the datasheet doesn't tell you 
that SPI1 as a whole is not 5v tolerant only that pins PA4/PA5 (which 
it uses) are not 5v tolerant. This limitation is also present for all 
other peripherals that share those pins.


This same reasoning also applies to FPGAs, and I think it is better to 
keep the same reasoning across device types so people don't have to 
learn multiple ways of using the symbols and analyzing the design.



As for the generation of pin constraints to map into the embedded 

Re: [Kicad-developers] [RFC] Symbols and Pin mapping in v6 - Proposal

[Strontium]

Hello Ajith,

I admit i skimmed your proposal, but i think it looks like it has merit, 
and that work can be done to improve symbols and pin mapping.


I always struggle with multi use pins like on MCUs.  Its tedious to keep 
drawing boxes with pins, just to support a layout of pins that suits the 
pinmuxing your using, and the a decent layout of the schematic.


I think a complex component like an MCU or FPGA could work like a 
sub-sheet.  It doesn't have a shape or symbol, per-se.  Its JUST a list 
of pins.  You then drop one of that component (which is a resizeable box 
like a sub-sheet), and like a sub-sheet import pins from it and place 
wherever you want in the box boundary.  Want to break your MCU into 
functional units, just drop another box with the same reference, import 
the pins you want into there.  It would be a lot easier to manage, i 
think.  And would reduce redundancy in part definitions for complex 
MCUs, and make those parts a lot easier to define in the process.  But I 
also think its probably a lot of work to do, and I don't know how it 
would break the file formats.


However this would also allow one to choose the mux function/s which 
could set the appropriate pin attribute for that pin, input/output/open 
drain, etc.  Making DRC sane again.  The schematic would be neater and 
would also tell you more about what is intended than:


I2C2_CLK/SPI1_MISO/ADC3_CH6/CLK_OUT/UART3_TX/UART2_TX/TIMER2_A/SCLK | 10 
-


Does.  Which is how a lot of MCU's end up getting defined.  Instead the 
designer says, this pin is the I2C2_CLK and the pin then looks like this 
in the schematic:


I2C2_CLK | 10 -

doesn't suit layout, right click on pin and change it to the I2C2_CLK on 
pin 239:


I2C2_CLK | 239 -

Don't have to copy the component, move pins around, reimport the changed 
symbol, etc etc.


For simple components, like diodes, transistors, buffers, LDOs, opamps, 
etc etc.  Then a symbolic representation is definitely the way to go.  
And your proposal would make that even nicer.  I like the list of pins 
example you gave for the transistor.  Much clearer from a schematic 
perspective.


Steven

On 12/9/19 11:36 am, Ajith N wrote:

Sorry the URL was mangled, here it is:
https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf


 On Thu, 12 Sep 2019 12:30:26 +0800  

Hi Developers,

Requesting your attention to a proposal and discussion in the
KiCad User Forum. The topic is symbols and pin mapping (for v6) as
they relate to the data model.

I took up a suggestion (by Rene Poeschl) to detail my proposal
with diagrams, and have prepared some slides, which is at:

https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf (PDF
format)

The background references are at the end.

(I feared being unable to respond in a timely manner to potential
questions which may arise in the course of discussions in the
developers' list. Therefore, I have chosen to put more detail into
the slides wherever possible. Hopefully that helps. The detail may
be excessive for some readers though. If so please bear with me).

I hope KiCad developers find this worth looking at for v6.

Thanks for all the great work!

P.S.
I have been a happy user of KiCad for barely over a year now.
KiCad to me is a very nice and open tool with nice features, has
no lock-in, has an active community of users and is progressing in
a good direction.





___
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] HotKey config

[Strontium]

Presumably the hotkey file is textual. I would prefer Full also, but a 
way to have both the benefits of both Sparse and FULL files is to list 
everything, but comment out the entries which are still the default.  So 
the file shows exactly whats been changed, AND what all the 
possibilities are.


Something Like (Not a proposed format):

# Copy : ^C
Paste : ^X

Where Copy is still the default but Paste was changed.

Everything is listed, but the changed items are highlighted.

On 8/6/19 2:35 am, Wayne Stambaugh wrote:

+1

On 6/7/19 1:25 PM, Seth Hillbrand wrote:

+1

On 2019-06-07 12:46, Jon Evans wrote:

I vote "full", because I'd rather not have to look two places to see
what's what.

On Fri, Jun 7, 2019 at 12:40 PM Jeff Young  wrote:


Individual hotkey config files need to be able to be sparse.  So for
instance an “Eagle HotKeys” file can specify just those ACTIONs
it wanted to match with Eagle.  The user can then read as many of
these as they like.

But what about the “standard” user config file where we store
hotkey assignments made through the GUI?  It could also be sparse
(ie: list only those ACTIONs which had hotkeys different from the
default), which would make it shorter, and give an indication of
which hotkeys had been overridden.  Or it could be “full” (ie:
contain all ACTIONs), which would give a useful cheat-sheet of what
all the action names were.

I’m currently leaning toward “full”, but I’ve already gone
back and forth several times….

Thoughts?

Cheers,
Jeff.
___
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

___
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




___
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] Segfault that just started happening

[Strontium]

Hi Simon,

Thast was it.  GLXInfo crashed also.  I rebooted and it all came good.
Not sure what the problem was with OpenGL.

Thanks for the help.

Steven

On 31/10/18 9:11 pm, Simon Richter wrote:

Hi,

On 31.10.2018 14:42, Strontium wrote:


The error was 'BadValue (integer parameter out of range for operation)'.
   (Details: serial 8548 error_code 2 request_code 154 minor_code 24)

The segmentation fault happens because the error handler for X errors
tries to exit the program, and stumbles over invalid objects there. This
is an error path that is badly tested, because these errors are usually
difficult to reproduce, so I'd ignore the segmentation fault here and
focus on the X error.

The major request code (154) is dynamically allocated, so it is
difficult to tell which X extension caused it. The most likely candidate
is GLX, where minor opcode 24 is X_GLXCreateNewContext.

Do other OpenGL based programs work for you?

Does glxinfo report Direct Rendering to be active?

Simon


___
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] Segfault that just started happening

[Strontium]

Extra Information:
The following crash with the X segfault, schematic editor, symbol 
editor, pcb layout editor, footprint editor.  And when they do, they 
kill the project browser.  Gerber viewer also crashes with an X 
segfault, but i doesn't crash the project browser when it does. Bitmap 
to component, PCB calculator and Page layout editor all seem fine.


On 31/10/18 20:42, Strontium wrote:
I was on the js-reynaud legacy nightly ppa (Ubuntu 18.04), and things 
were fine a few days ago.  But i just tried to run kicad and it was 
crashing.
So, i uninstalled everything from legacy nightly and installed the ppa 
js-reynaud/kicad-5  but for some reason if i try and open a schematic 
OR a pcb, it crashes with a segfault also:


Trying to open a schematic:

steven@steven-ge40:~$ kicad
The program 'kicad' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 8548 error_code 2 request_code 154 minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() 
function.)

Segmentation fault (core dumped)


Trying to open a PCB:

steven@steven-ge40:~$ kicad
The program 'kicad' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 4479 error_code 2 request_code 154 minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() 
function.)

Segmentation fault (core dumped)


Anyone else seen this???  I have no idea what's going on.

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

[Kicad-developers] Segfault that just started happening

[Strontium]

I was on the js-reynaud legacy nightly ppa (Ubuntu 18.04), and things 
were fine a few days ago.  But i just tried to run kicad and it was 
crashing.
So, i uninstalled everything from legacy nightly and installed the ppa 
js-reynaud/kicad-5  but for some reason if i try and open a schematic OR 
a pcb, it crashes with a segfault also:


Trying to open a schematic:

steven@steven-ge40:~$ kicad
The program 'kicad' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 8548 error_code 2 request_code 154 minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() 
function.)

Segmentation fault (core dumped)


Trying to open a PCB:

steven@steven-ge40:~$ kicad
The program 'kicad' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 4479 error_code 2 request_code 154 minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() 
function.)

Segmentation fault (core dumped)


Anyone else seen this???  I have no idea what's going on.

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] kicad version and install location

[Strontium]

I honestly think each major revision of KiCad should be considered a NEW 
program, installs to a new place has its configuration and libraries all 
in a new location.  Only Incremental updates 5.0 -> 5.1 should be 
considered upgrades.


Kicad configuration isn't complex or onerous so if a user wants to bring 
a Kicad4 config into Kicad5 or 6 or whatever, then they do that 
themselves, otherwise after install Kicad5 is a fresh blank sheet with 
no relationship to anything that happened on the users computer in 
Kicad4.  I am not familiar with the issues on Windows, but I would have 
thought now this is mostly a packaging issue only??


Sure the NEW program can load your OLD projects, but its not the same, 
and may not work like you remember.


I also agree if it can't work this way now on Windows, then its all a 
bit late for V5, but maybe V6 can consider itself a new program distinct 
from V5.  This would also help with testing, because users could use V5 
for daily work, but also easily install a V6 daily side by side.


A simple workaround for any user on Windows who NEEDS V4 on windows is 
to run V4 in a Linux VM, and just share the file system.


Steven


On 15/07/18 03:14, Wayne Stambaugh wrote:

On 07/14/2018 10:55 AM, Ouabache Designworks wrote:


On Fri, Jul 13, 2018 at 7:49 PM, Mark Roszko mailto:mark.ros...@gmail.com>> wrote:

 Wayne,

 Guess going to suggest it should be a priority to version the config
 into folders.

 This is a user made chart on how to install kicad 5 which honestly is
 silly it has to even exist lol
 
https://kicad-info.s3-us-west-2.amazonaws.com/original/2X/d/d6143659e9237fc358588bed761ef3e557454cde.png
 




Now imagine that you are working on three or four different projects at
the same time and they each used a different version
of Kicad. That is what IC designers have to deal with. Chips take
several years to complete and the tools rev all the time.
You start a new chip six months into your last design and it may use
different revs of tools.

That is why IC designers use environment managers. All the revs are
installed in parallel and each project can pick the one that
it wants.

John Eaton


Pragmatic use of our limited developer resources is not silly.  It's
just the reality of the project.  Would I like for KiCad to be able to
provide support for this?  Of course I would.  I am fairly certain that
if I polled KiCad users if they would rather have all of the features
listed in v6 roadmap or be able to install multiple versions of KiCad
with only a few of those features that they would choose all of the
features.  Even if we implemented the proposed changes for v5, who is
going to backport it v4?  Given the divergence between the code bases,
good luck with that.  We are already 6 months behind when I would have
liked to get v5 out the door so delaying v5 another couple of months is
really not a good option.  I'm fine with implementing this for 5.1 if
someone is interested in coding it but that still doesn't solve the v4
issue which I'm guessing user's want to keep installed along side v5.

___
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

[Kicad-developers] PCB NC Solder Jumpers in the Std Library

[Strontium]

So,

I tried to use the PCB Jumpers from the standard library, specifically a 
NC jumper. Jumper:SolderJumper-2_P1.3mm_Bridged_RoundedPad1.0x1.5mm  
These seem to be new with the V5 library, because i don't remember them 
with V4.


And it causes DRC errors.  Firstly it generates "Track near Pad" DRC 
errors, because its built from overlapping pads, and specifically the 
middle pad used to create the NC connection is too close to the track 
which terminates on the "Actual" pads.


So i made a local change to eliminate that by reducing the size of the 
"joining" pad.  But that still causes a DRC error "Pad near Pad", which 
is right, because its just a bunch of overlapping pads.  So the question 
is, How is one supposed to use this standard library component without 
generating DRC errors.


I tried a bunch of experiments to create a NC Solder Jumper that doesn't 
create DRC errors and the best workaround seems to be use a NO PCB 
Jumper and manually connect the pins in the schematic like this:


https://imgur.com/a/HwXKttp

Which works, and doesn't generate DRC errors, because I have to manually 
connect the pads with a fat track, DRC passes.  BUT it is ugly from a 
schematic perspective.


It seems like there needs to be a copper feature of a footprint, that is 
not a PAD (or at least is ignored for PAD DRC checks) to handle cases 
like this.


Don't get me wrong because i think the Solder Jumper components look 
great, but should there be standard components that can't pass 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] More default fields in schematic

[Strontium]

Hello Everyone,

I like the patch, and hope it makes it in.

Clemens,  I don't think anything that is being discussed is in any way 
going to constrain b) or c).  But I think there is a third group, not just


1. Big Manufacturers
2. Hobbyist/Student

but

3. Small Scale Professional Manufacturer.

And now while 3 might grow into 1, and will have been 2 at some point, 
they almost certainly won't have a large backend with either SAP or 
Custom Generators.  They probably use a spreadsheet, and my opinion is 
having this information default in a sensible/consistent way in kicad 
would make their life a lot easier.  And I say this BECAUSE the engineer 
at the Small Scale shop, is also likely the person putting together the 
BOM and ordering the boards.  They are also making their BOM choices and 
decisions at Design Time, not just saying, its a 48pin tqfp samd21 or 
whatever.  They will be thinking, how much does it cost, what's my 
budget, where can I buy it, what are the MOQs, etc etc.  That's exactly 
the kind of user who would want to encode this into their schematic at 
design time.  And it would feel natural for them to do so. Rather than 
ignore all that, design a board and then make a second pass to do ALL 
that work again and record it in a second system.  I see this as 
supportive of those users, and guiding them, especially new users.


I also think KiCAD is going to find a fit with 2 and 3, much more than 1 
will.  Because with 1 the engineers don't care if the tools cost a 
fortune.  They just want what they want.  However all that said, nothing 
in this proposal would effect a Big manufacturer doing whatever they 
want.  Its simply a guided approach, rather than a blank sheet of paper 
approach.


Steven

On 22/05/18 22:49, Clemens Koller wrote:

Hello, everybody!

Just my five cents:
Can we somehow make sure that people understand and consider and Kicad reflects 
the differences in:

a) Unique partname + associated footprint + other arbitrary parameters 
necessary for the board design.

b) One or more qualified components from a manufacturer + a unique manufacturer 
number to be assembled on a).

c) One or more distributors or manufacturers or representatives to get one ore 
more of the b)'s.

In my case, it would be sufficient for Kicad to be able to handle a) only.
b) and c) are neither standardized nor flexible enough to be handled by most 
EDA systems, when there is more than one EDA system in use.
b) and c) is handled i.e. by SAP at one of my manufacturers site and some 
Generators + Tools + MariaDB at my place.

So, there is an n x m matrix of demands for b) and c) which makes IMO no sense 
to code in one EDA system if you look at the big picture how industrial 
electronics design happens nowadays. Off course I am not talking about hobbyist 
or academic use cases.

Regards,

Clemens

On 2018-05-22 14:52, Ben Hest wrote:

 From a Digi-Key KiCad library standpoint, as we're still in beta, I would 
gladly change the fields to whatever would be decided.  Uniformity for plugins 
use would definitely be an advantage.

-Ben

On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark > wrote:

 Thanks! This is exactly what i was going for, non-intrusive oppurtunity
 for uniformity!

 I tested the bom2csv plugin, It did not include the empty fields.

 I also tested the bom_csv_sorted_by_ref, it did not include the empty
 values, but it included some values I had not specified, such as
 Manufacturer and Vendor even if they were not provided in the
 schematic.

 - Kristoffer

 On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
 > I think I like this new patch.  It provides the /opportunity/ for
 > uniformity, without getting in the way of those who want to go their
 > own way.
 >
 > Do the BOM generators automatically output all default fields or only
 > those with values?
 >
 > > On 22 May 2018, at 09:22, kristoffer ödmark  > il.com > wrote:
 > >
 > > Please disregard my previous mail, it got mangled badly somehow, it
 > > did
 > > not look like that in my editor at least.
 > >
 > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
 > > > Eeschema already supports creating default optional fields in the
 > > > configuration settings dialog.  Used correctly, these will give
 > > > you
 > > > the
 > > > same optional field names for every project without having to add
 > > > them
 > > > by hand to each symbol and possibly typing in different field
 > > > names
 > > > by
 > > > accident.
 > >
 > > Different users will still type in different field names for the
 > > same
 > > things though. What you describe works as long as there is only one
 > > person in the entire projects lifetime, using only one computer.
 > >
 > > > The 

Re: [Kicad-developers] Initial rc6 development.

[Strontium]

+1

On 19/05/18 01:27, Seth Hillbrand wrote:


​I'll second Tom's suggestion here.  Distros are free to package KiCad 
how they like, but we can create an AppImage[1] with GTK2 and 
wxpython​ that users can download from the website.  This would 
provide a way for all users to run KiCad even if their distro doesn't 
package the required libraries.  Bug reports on GTK3 could then be 
redirected to the AppImage download link.


-Seth

[1] https://appimage.org/


Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski 
>:


On 18/05/18 17:38, Wayne Stambaugh wrote:
> As we approach the v5 stable release, I want to discuss a
something we
> should seriously consider before we open the flood gates for new
feature
> merges after the v5 branch.  We are currently in an awkward position
> with regards to gtk3 builds on Linux.  Given that most distros
are now
> building wx against gtk3, we really should work towards fixing
this at
> the beginning of v6 and back porting it as soon as possible so
that we
> can better support the current Linux distros. Fortunately, most
distros
> have thankfully provided a gtk2 build version of wx in order to
build
> kicad.  However, they have not done the same thing for wxpython
so for
> most new distro releases, we have to build kicad without wxpython
> support.  I propose we spend some time immediately after the v5
release
> and fix the gtk3 issues before we start making major changes to
the code
> base so that it is not difficult to back port.  Anyone else have any
> thoughts on this?
>

Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom



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


___
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



___
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] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Strontium]

Wayne,

I think it is an acceptable solution for V5 because this shouldn't get 
in the way of a V5 release.


For V6, would it be feasible to define 0.01/0.1% to be a special 
value (like zero) which means "effectively zero" and then the pad gui 
can be updated with this special knowledge so that users don't look at a 
pad and say "Why is this set to 0.01??" and then change it thinking 
its a rounding error or something.


I am not a fan of coded values in gui's because the whole idea of a gui 
is to abstract the implementation details into something human friendly. 
And 0 meaning "inherit", and 0.01 meaning "effectively zero" is an 
implementation issue and not something the user should have to know or 
think about.


Actually, it would be nice in the pad gui, if it IS set to inherit that 
the field display a READ ONLY value that would be used NOW based on the 
current global/parent settings, and which is it (a global value or a 
parent value).


Steven


On 28/04/18 23:35, Wayne Stambaugh wrote:
Just to be clear, the library developers are asking for the ability to 
ignore clearance and ratio settings when creating solder mask and 
solder paste only pads.  If this is the case, it will require a board 
file format change to add a flag to ignore the global and footprint 
level settings.  I would be opposed to changing the code to just 
assume that if it's a solder mask or solder paste only pad that no 
tolerance or ratio is applied.  This would break an existing pads 
defined this way and silently change existing boards.  Given that we 
are deep into feature freeze, the least painful solution would be to 
set the tolerance to 1nm and the ratio (as JP suggested) to 0.1% 
for the footprints that need to maintain the dimensions of solder mask 
and solder paste only boards.  The change to the overall pad 
dimensions using this method would be far below any board 
manufacturer's tolerance capabilities.  Is this not an acceptable 
solution?


Cheers,

Wayne

On 04/28/2018 08:44 AM, Eeli Kaikkonen wrote:



2018-04-28 15:04 GMT+03:00 Rene Pöschl >:


    The global settings here are less for ensuring correct alignment and
    more for a global paste reduction.


That's right, that's what I meant. In the example datasheet you have 
0.05mm tolerance for the location of the mask in relation to the 
copper because. But making the mask openings larger or smaller by 
0.05mm would be against the recommendation.


It just doesn't make sense to apply global paste and solder mask 
clearance values to "pads" which don't have copper. The whole reason 
why non-copper pads can exist is that you need control over the size, 
shape and location of paste or mask, right? Changing the behavior 
could lead to problems but luckily the current behavior can be 
circumvented by adding to clearance fields a very small value which 
is negligible in practice.


Eeli Kaikkonen


___
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




___
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] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Strontium]

On 28/04/18 18:51, jp charras wrote:

Le 28/04/2018 à 10:08, Eeli Kaikkonen a écrit :

It still looks to me that the original problem wasn't understood, and I wasn't 
able to make it
clear. A Solder Mask Defined footprint means that the solder mask opening is 
smaller than the
underlying copper area. It may also be differently shaped than the underlying 
copper pad. Also the
paste area may be differently shaped than the copper or solder mask. In these 
cases it should be
possible to define the mask and paste areas exactly, without adding or removing 
anything. The
logical way of doing it, if KiCad had took it into consideration, would be to 
draw the pad shape and
set the clearances to 0, and the pad would always keep the exact dimensions. 
But now, because 0 is a
special case and means "add here some other value" the pad dimensions - we are 
talking about
non-copper pads - will change unpredictably. This works for normal Non Solder 
Mask Defined pads with
copper, but not for pads which are mask only or paste only.

The only possible solution ATM is to give very small clearance values so that 
the original size of a
mask-only pad is for example 0.3x0.45mm and the efficient value will be 
0.31x0.450001mm. If the
clearances are left to 0 they can be anything, depending on the project's 
values, and the footprint
doesn't work anymore. Remember that modern Solder Mask Defined footprints are 
mostly very small and
tolerances are small. You can't add or remove 0.05mm without it going wrong.

I perfectly understood what you are saying.
But I do not agree with you.

but if "You can't add or remove 0.05mm without it going wrong" it means the 
final board can be wrong.
Just because the solder mask opening areas can be not at the place you are 
expecting, due to
registration issues.
I am thinking you are not taking in account this problem.
If you are thinking this problem does not exist, just set the solder mask 
margin to 0
JP, I agree with you about solder mask registration issues in the normal 
course, however there are components with specified footprints (like the 
one Eeli linked to) that have very tight tolerances.  Now, the fact that 
those specifications exist means that it is possible (although it may be 
expensive and not a normal process) to get registration of the solder 
mask to meet or exceed the tolerances required of these footprints, 
otherwise the footprint would not be defined this way.


Eeli is really talking about "features" of the footprint, and these 
special "features" are modelled as a kind of pad, but are not really 
pads.  In this situation I can see that a way to "disable" the global 
clearances from having any effect for a particular "feature" pad would 
be desirable.  Might be a useful thing for V6?


Steven




See for example http://www.ti.com/lit/ug/slra003d/slra003d.pdf

Eeli Kaikkonen

2018-04-28 10:28 GMT+03:00 jp charras >:

 Some info about these masks:

 For custom shaped pads, building a solder mask shape with a negative 
margin can create issues
 (unpredictable shape for non convex polygons).
 So it is not allowed.

 Margin in solder mask layers is needed because there are always 
registration issues between the
 copper layers and the solder mask layer.

 Therefore, because the X and Y registration position error, you need a 
actual mask size bigger than
 the area defined by a pad, to be sure the actual solder mask does not 
cover the pad (the hole in
 mask always covers the pad area).
 X/Y max error depends on your board house, so this is the reason to have 
the registration tolerance
 defined for the whole board (unless you know your board house, you cannot 
reliably use a defined
 tolerance: it could be too small or too large)

 I am guessing there are also similar registration problems for the solder 
mask, but I don't know
 them.

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





___
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] XDG_CONFIG_HOME on all platforms

[Strontium]

Hi Wayne,

I have no personal problem with your patch, but from a standards point 
of view I want to raise this.


As per: 
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
|"$XDG_CONFIG_HOME| defines the base directory relative to which user 
specific configuration files should be stored. If |$XDG_CONFIG_HOME| is 
either not set or empty, a default equal to |$HOME|/.config should be used."


The way I read your patch is that, XDG_CONFIG_HOME is being used to 
specify the absolute path of the kicad configuration directory, not it's 
relative base directory.


My concern is that if XDG_CONFIG_HOME is set to someones "relative base 
config directory", then that relative base config directory is going to 
get filled with kicad config files.


Also, on unix, wxStandardPaths::Get().GetUserConfigDir() uses 
XDG_CONFIG_HOME internally, so the current kicad specific support for 
XDG_CONFIG_HOME (as a relative base directory) is redundant.
see: 
https://github.com/wxWidgets/wxWidgets/blob/master/src/unix/stdpaths.cpp


Maybe its better to just define a new Kicad specific environment 
variable for the purpose, "KICAD_CONFIG_HOME" for example.  Then there 
is no conflict with any existing uses or standards, your patch as 
written, would also then remove the redundant of processing XDG_CONFIG_HOME.


Steven

On 24/04/18 01:10, Wayne Stambaugh wrote:

Attached is a patch that allows users to have multiple configuration
paths using the XDG_CONFIG_HOME environment variable on all platforms.
I tested it on windows and it seems to work just fine.  I can test it on
linux tonight when I get home but if someone can get to it before then I
would appreciate the help.  Would one of our macos devs please test it
as well before I merge it.

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



___
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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

On 12/04/18 21:49, Jean-Samuel Reynaud wrote:

Perhaps this name should be configurable ("overridable" ?) by an env
variable ?
Yes I think so too.  We have two proposals so far, an environment 
variable, or a command line switch.  Either or both would work.  But 
both are creeping the scope and if we do that, we should do it in V6.  
The decision here is, do we want to have kicad5 keep its configuration 
separate from kicad4 now.  OR do we want to wait until v6 and implement 
these other ideas when we have time to test them and shake out the 
issues. Which will mean kicad4 and 5 can not coexist.


My vote is we just change the already hard coded "kicad" subdirectory 
name to be "kicad5" (or whatever), and that we do that now before kicad5 
is released. Hardcoding "kicad" is no more or less evil than hardcoding 
"kicad5".  Any changes beyond that are deferred to V6 when they can be 
properly considered, implemented and tested.


NOTE: on any platform other than Windows and Mac, the root configuration 
directory can already be changed with an environment variable.  So you 
can change ~/.config/kicad to ~/my_extra_config/kicad but you can not 
change the name of the kicad subdirectory itself.


Steven



Le 12/04/2018 à 15:29, Strontium a écrit :

kicad5
kicad6
etc etc works for me.  I am not wedded to my suggestion, it was
illustrative only.

For backward compatibility, "kicad" would be for kicad4 because that's
what it uses now, so there would be no "kicad4".

I agree that a user selectable configuration directory would be useful
for some people.  It should not be difficult to do either, once there
was a consensus on the how of it. However, being cognizant of how late
in the release stage for V5 it is, this proposal to only change the base
directory is to allow kicad4 and 5 to coexist (and nightlies) in the
absolutely simplest possible way, without creeping the scope, or
creating untested code paths or boundary cases.  I also don't feel that
it creates a burden going forward, or precludes the development team
expanding on this or any other changes to this area that are felt
desirable.  I think we should push anything more exotic than just using
a new base configuration directory to version 6.

Steven

On 12/04/18 18:39, Clemens Koller wrote:

I would pretty much vote to use the IMO more common naming scheme for
major package versions:

kicad (the current one installed from the repository of your choice)
kicad4 (currently: 4.0.7)
kicad5 (currently: 5.0.0-rc2-dev...)
kicad6 (tbd.)

...avoiding the ".v5" i've seen lately.

I believe there is less demand for different minor versions installed
next to each other, however it would be a nice-to-have.
(So... a user-selectable configuration might help: $ kicad -c
projectconfig.cfg)

Regards,

Clemens

On 2018-04-12 09:33, Strontium wrote:

After considering my patch, what about the following proposal:

Just change the hard coded string in common.cpp (at around line 243)
from:

cfgpath.AppendDir( wxT( "kicad" ) );

to

cfgpath.AppendDir( wxT( "kicad.v5" ) );

(or some other string)

Thats it.  Then Kicad Version 5 will have a unique configuration
directory that will not conflict with version 4.

If an end user wants to bring their kicad V4 configuration over to v5,
they just copy it themselves.  Otherwise it starts with a brand new
blank configuration.  Alternatively packaging might be able to copy it
over.  But i don't see any real need to do it for the user at that
stage.  Its just a complication.

Then when the development branch is forked, just rename this again to
something like:
cfgpath.AppendDir( wxT( "kicad.v6dev" ) );

(or whatever).

Then an end user can have V4, V5 and a Nightly all on the same machine
and configurations won't conflict.

Anything more exotic can be deferred to V6 development.

Steven




On 08/04/18 13:33, Carsten Schoenert wrote:

Am 07.04.18 um 17:34 schrieb Strontium:

Attached is a patch for discussion only.

Its the minimum change I could come up with to implement a unique
version specific config directory.

Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to
"~/somethingelse/kicad" which would work, but isn't a very friendly
naming scheme.

Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
$HOME/.local/share.

I'm sure Windows and Mac have similar variables for the folders that
should contain the logical same content.

The path to the KiCad user config must based on such variables plus the
preferred name for the config folder, so like kicad-5 (for KiCad5) and
kicad-6 (for future version KiCad6) and kicad-nightly (for devel
version). GTK is doing this for a long time.


$ find  ~/.config -type d -name gtk*
/home/carsten/.config/gtk

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

kicad5
kicad6
etc etc works for me.  I am not wedded to my suggestion, it was 
illustrative only.


For backward compatibility, "kicad" would be for kicad4 because that's 
what it uses now, so there would be no "kicad4".


I agree that a user selectable configuration directory would be useful 
for some people.  It should not be difficult to do either, once there 
was a consensus on the how of it. However, being cognizant of how late 
in the release stage for V5 it is, this proposal to only change the base 
directory is to allow kicad4 and 5 to coexist (and nightlies) in the 
absolutely simplest possible way, without creeping the scope, or 
creating untested code paths or boundary cases.  I also don't feel that 
it creates a burden going forward, or precludes the development team 
expanding on this or any other changes to this area that are felt 
desirable.  I think we should push anything more exotic than just using 
a new base configuration directory to version 6.


Steven

On 12/04/18 18:39, Clemens Koller wrote:

I would pretty much vote to use the IMO more common naming scheme for major 
package versions:

kicad (the current one installed from the repository of your choice)
kicad4 (currently: 4.0.7)
kicad5 (currently: 5.0.0-rc2-dev...)
kicad6 (tbd.)

...avoiding the ".v5" i've seen lately.

I believe there is less demand for different minor versions installed next to 
each other, however it would be a nice-to-have.
(So... a user-selectable configuration might help: $ kicad -c projectconfig.cfg)

Regards,

Clemens

On 2018-04-12 09:33, Strontium wrote:

After considering my patch, what about the following proposal:

Just change the hard coded string in common.cpp (at around line 243) from:

cfgpath.AppendDir( wxT( "kicad" ) );

to

cfgpath.AppendDir( wxT( "kicad.v5" ) );

(or some other string)

Thats it.  Then Kicad Version 5 will have a unique configuration
directory that will not conflict with version 4.

If an end user wants to bring their kicad V4 configuration over to v5,
they just copy it themselves.  Otherwise it starts with a brand new
blank configuration.  Alternatively packaging might be able to copy it
over.  But i don't see any real need to do it for the user at that
stage.  Its just a complication.

Then when the development branch is forked, just rename this again to
something like:
cfgpath.AppendDir( wxT( "kicad.v6dev" ) );

(or whatever).

Then an end user can have V4, V5 and a Nightly all on the same machine
and configurations won't conflict.

Anything more exotic can be deferred to V6 development.

Steven




On 08/04/18 13:33, Carsten Schoenert wrote:

Am 07.04.18 um 17:34 schrieb Strontium:

Attached is a patch for discussion only.

Its the minimum change I could come up with to implement a unique
version specific config directory.

Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to
"~/somethingelse/kicad" which would work, but isn't a very friendly
naming scheme.

Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
$HOME/.local/share.

I'm sure Windows and Mac have similar variables for the folders that
should contain the logical same content.

The path to the KiCad user config must based on such variables plus the
preferred name for the config folder, so like kicad-5 (for KiCad5) and
kicad-6 (for future version KiCad6) and kicad-nightly (for devel
version). GTK is doing this for a long time.


$ find  ~/.config -type d -name gtk*
/home/carsten/.config/gtk-3.0
/home/carsten/.config/gtk-2.0

If KiCad will introduce some version specific user config and data
folders (which I appreciate to see) it will be needed to configured by
the build environment and not hard-coded in the binaries. The variables
can be overwritten with some additional value given while starting the
applications.

e.g.
take the default folders
$ kicad

override the setting for the default config etc.
$ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad



___
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




___
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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

After considering my patch, what about the following proposal:

Just change the hard coded string in common.cpp (at around line 243) from:

cfgpath.AppendDir( wxT( "kicad" ) );

to

cfgpath.AppendDir( wxT( "kicad.v5" ) );

(or some other string)

Thats it.  Then Kicad Version 5 will have a unique configuration 
directory that will not conflict with version 4.


If an end user wants to bring their kicad V4 configuration over to v5, 
they just copy it themselves.  Otherwise it starts with a brand new 
blank configuration.  Alternatively packaging might be able to copy it 
over.  But i don't see any real need to do it for the user at that 
stage.  Its just a complication.


Then when the development branch is forked, just rename this again to 
something like:

cfgpath.AppendDir( wxT( "kicad.v6dev" ) );

(or whatever).

Then an end user can have V4, V5 and a Nightly all on the same machine 
and configurations won't conflict.


Anything more exotic can be deferred to V6 development.

Steven




On 08/04/18 13:33, Carsten Schoenert wrote:

Am 07.04.18 um 17:34 schrieb Strontium:

Attached is a patch for discussion only.

Its the minimum change I could come up with to implement a unique
version specific config directory.

Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to
"~/somethingelse/kicad" which would work, but isn't a very friendly
naming scheme.

Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
$HOME/.local/share.

I'm sure Windows and Mac have similar variables for the folders that
should contain the logical same content.

The path to the KiCad user config must based on such variables plus the
preferred name for the config folder, so like kicad-5 (for KiCad5) and
kicad-6 (for future version KiCad6) and kicad-nightly (for devel
version). GTK is doing this for a long time.


$ find  ~/.config -type d -name gtk*
/home/carsten/.config/gtk-3.0
/home/carsten/.config/gtk-2.0

If KiCad will introduce some version specific user config and data
folders (which I appreciate to see) it will be needed to configured by
the build environment and not hard-coded in the binaries. The variables
can be overwritten with some additional value given while starting the
applications.

e.g.
take the default folders
$ kicad

override the setting for the default config etc.
$ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad




___
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] Fwd: Right to use KiCad name / logo

[Strontium]

On a practical note, the bigger the profile of KiCad gets, the more 
likely some a-hole tries to trademark kicad out from under the project 
for their own perceived benefit (Or just simply to be an a-hole).  It 
happens.


So it's probably a good idea to get the trademark just to protect the 
project from someone else taking it and then the trouble that causes.


Who pays for that, and who holds it is another question.  But if it 
happens,  we should clearly define what's allowed and what's not.  For 
example, if you made a board in KiCad, is it allowed to put the KiCad 
logo on the boards silkscreen?  What if it's a commercial board, and not 
open source?  That sort of thing.


Steven

On 11/04/18 19:51, Wayne Stambaugh wrote:

Please take a look at the inquiry below that I received from CERN about
using the KiCad logo for merchandising and trademark questions.  I have
included my response to the inquiry.  Does anyone else have any
objections or any knowledge of KiCad being a registered trademark?

Cheers,

Wayne

 Forwarded Message 
Subject: RE: Right to use KiCad name / logo
Date: Mon, 9 Apr 2018 13:59:55 +
From: Hilary Nathan 
To: Wayne Stambaugh 
CC: Javier Serrano 

Hi Wayne
Many thanks for your prompt response.  I will follow up with Javier and
CERN's legal team to see what (if any) efforts have been made for TM
protection of the KiCad name/logo.
In the meantime, it would be great if you could contact the rest of the
development team to receive their response to my queries.
Best wishes
Hilary


-Original Message-
From: Wayne Stambaugh  Sent: 09 April 2018 15:48
To: Hilary Nathan 
Cc: Javier Serrano 
Subject: Re: Right to use KiCad name / logo

Hi Hilary,

I personally do not have any issue with using the KiCad logo as long as
the merchandising proceeds go to the KiCad project.  I cannot speak for
the entire development team but I'm reasonably sure they would feel the
same way.  I can ask on the developers mailing list if you prefer.

I was under the impression the CERN was going to handle registering the
KiCad trademark (at least in the EU) given some of the conversations I
have had with Javier but I may have misunderstood.  Perhaps we could use
some of the proceeds to help defer the cost of getting KiCad trademarked
at least in the US and EU.  I do not believe there is any intent to
trademark KiCad.  We really don't have any legal entity to own the
trademark so I suspect that is why it has not happened up to this point.
  I'm not sure how best to handle this.  I am comfortable with CERN
applying for the trademark as long as it is understood that the
trademark belongs to the KiCad project.  The other option may be to
register it under the project founder's name (Jean-Pierre Charras).  I
am open to suggestion since legal matters are not my specialty.

Cheers,

Wayne

On 4/9/2018 6:51 AM, Hilary Nathan wrote:

Dear Wayne

  


I joined CERN at the beginning of this year and have been in touch
with Chris Gammell from Analog Life LLC/Contextual Electronics about
how together we can increase awareness and funds for KiCad.  Chris
already uses the KiCad name and logo on his community forum (and other
sites) to support KiCad, and sells KiCad-branded merchandise to raise
money for KiCad development.

  


Before CERN partners with Chris (and potentially others) in this kind
of activity, I wanted to check with you about trademark protection and
ability to use the KiCad name and logo.

  


As I understand, the licences for KiCad (program, documentation,
library and website) do not cover trademarks.  I have searched
trademark data bases and KiCad is not listed as a protected mark.

  


Would you kindly advise:

  


1.   Whether there is any trademark protection for KiCad?

2.   If so, what is the source of the protection, where is it
registered and who is the owner of the IP?

3.   If not, are all interested parties (yourself and the other
authors; other contributors or sponsors) happy for CERN to use the
KiCad name and logo in a commercial manner (eg: merchandise)
independently or with other partners (such as Chris) with all profits
flowing back to the CERN & Society Foundation for KiCad development?

4.   If not, do any interested parties (as identified above)
intend to apply trademark protection to the name/logo?

  


If it is easier, we can discuss by telephone when it's convenient for you.

  


Your advice is much appreciated.

  


Best wishes

Hilary

  


*Hilary Nathan*

CERN & Society Foundation

CERN International Relations

  


inst-CERN

CERN - European Organization for Nuclear Research CH - 1211 Geneva 23,
Switzerland

  


Tel. +41 22 76 62159

http://www.cern.ch/giving

  

  


/Sign up for the CERN & Society e-newsletter and stay up-to-date!/

/cern.ch/go/CSnews   ///

  

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

Hell Carsten,

On 08/04/18 13:33, Carsten Schoenert wrote:

Am 07.04.18 um 17:34 schrieb Strontium:

Attached is a patch for discussion only.

Its the minimum change I could come up with to implement a unique
version specific config directory.

Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to
"~/somethingelse/kicad" which would work, but isn't a very friendly
naming scheme.

Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
$HOME/.local/share.

I'm sure Windows and Mac have similar variables for the folders that
should contain the logical same content.
yes, its not obvious from the patch I sent, because I left that code 
unmodified, but the config path is obtained using the wx call: 
wxStandardPaths::Get().GetUserConfigDir()  Kicad doesn't know about the 
platform specifics, it relies on wx to provide them.


ONLY if the platform is not windows or mac will it also read 
"XDG_CONFIG_HOME" and use that for the base of the configuration 
directories.  My patch does not change how kicad gets the configuration 
path, it only allows there to be two paths and if it has to create the 
current path, it copies the configuration from the previous config path, 
in order that current configuration is preserved on a version upgrade 
but not changed for the previous version.


The path to the KiCad user config must based on such variables plus the
preferred name for the config folder, so like kicad-5 (for KiCad5) and
kicad-6 (for future version KiCad6) and kicad-nightly (for devel
version). GTK is doing this for a long time.


$ find  ~/.config -type d -name gtk*
/home/carsten/.config/gtk-3.0
/home/carsten/.config/gtk-2.0

If KiCad will introduce some version specific user config and data
folders (which I appreciate to see) it will be needed to configured by
the build environment and not hard-coded in the binaries.
I suspected as much, however I do not know how one would go about that 
for kicad.  As to whether we do this now, later, or at all, The jury is 
still out, I just was looking at the scope of the change should kicad 
decide to do something like this.

  The variables
can be overwritten with some additional value given while starting the
applications.

e.g.
take the default folders
$ kicad

override the setting for the default config etc.
$ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad

It would be easy enough to add a unique environment variable which 
superseded XDG_CONFIG_HOME if set.  Is this portable to windows and mac 
though?



___
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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

Attached is a patch for discussion only.

Its the minimum change I could come up with to implement a unique 
version specific config directory.


Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows 
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to 
"~/somethingelse/kicad" which would work, but isn't a very friendly 
naming scheme.


So, what I did is:
Define a previous config dir and a current one.  They can not be sub 
directories of one another, so I went with "kicad.v5" for the new config 
directory.  For a nightly we could use "kicad.v6dev" or some such.


HOW these constants should get assigned I don't know.  At the moment I 
hard coded them.


I changed GetKicadConfigPath() to take a parameter of the config 
subdirectory, and renamed the function to just GetConfigPath().
Added a new GetKicadConfigPath() which works like the old one, but uses 
the new parametrised GetConfigPath().
IF the current config path does not exist, we make it (Same 
functionality as before), except then we check if the old one exists, 
and if it does, we just copy everything from it into the new one, once.  
If the new config path already exists we ignore the old one all together.


Very first time this runs will be slower than normal (due to the file 
copy), every other time it should be exactly the same as it is now.


As far as I know wx does not have a copy directories function, but there 
is one in their forums, so I pulled that, and made some small changes to 
remove redundancy in the code.  Its a pretty straight forward recursive 
copy.  I don't know if this should stay in this file, or live elsewhere, 
or be re-written/re-named.


Patch attached.  Tested on Linux, and seems to work fine.  Should work 
on Windows and MAC, but I haven't tested on those.  ALL programs use the 
GetKicadConfigPath() function to get the base of the configuration (as 
far as I can tell), there should be no strange corner cases.



diff --git a/common/common.cpp b/common/common.cpp
index c547b60f3..77002f473 100644
--- a/common/common.cpp
+++ b/common/common.cpp
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -215,7 +216,57 @@ wxConfigBase* GetNewConfig( const wxString& aProgName )
 }
 
 
-wxString GetKicadConfigPath()
+// Taken from:
+//https://forums.wxwidgets.org/viewtopic.php?t=2080
+//Slightly modified for kicad use.
+bool wxCopyDir(wxString sFrom, wxString sTo, bool noFromOK = false)
+{
+// Fix paths
+if (sFrom[sFrom.Len() - 1] != '\\' && sFrom[sFrom.Len() - 1] != '/') sFrom += wxFILE_SEP_PATH;
+if (sTo[sTo.Len() - 1] != '\\' && sTo[sTo.Len() - 1] != '/') sTo += wxFILE_SEP_PATH;
+
+// Make destination directory
+if (!wxDirExists(sTo)) {
+if (!wxFileName::Mkdir(sTo, wxS_DIR_DEFAULT, wxPATH_MKDIR_FULL)) {
+wxLogError(wxT("%s could not be created!"), sTo.c_str());
+return false;
+}
+}
+
+// Check if source directory exists
+if (!::wxDirExists(sFrom)) {
+if (noFromOK) return true;
+wxLogError(wxT("%s does not exist!\r\nCan not copy directory"), sFrom.c_str());
+return false;
+}
+
+// Copy from Source to Destination
+wxDir fDir(sFrom);
+wxString sNext = wxEmptyString;
+bool bIsFile = fDir.GetFirst();
+while (bIsFile) {
+const wxString sFileFrom = sFrom + sNext;
+const wxString sFileTo = sTo + sNext;
+if (::wxDirExists(sFileFrom)) {
+wxCopyDir(sFileFrom, sFileTo);
+}
+else {
+if (!::wxFileExists(sFileTo)) {
+if (!::wxCopyFile(sFileFrom, sFileTo)) {
+wxLogError(wxT("Could not copy %s to %s !"), sFileFrom.c_str(), sFileTo.c_str());
+return false;
+}
+}
+}
+bIsFile = fDir.GetNext();
+}
+return true;
+}
+
+#define KICAD_PREVIOUS_CONFIG wxT( "kicad" )
+#define KICAD_CURRENT_CONFIG  wxT( "kicad.v5" )
+
+wxFileName GetConfigPath( wxString name )
 {
 wxFileName cfgpath;
 
@@ -240,11 +291,24 @@ wxString GetKicadConfigPath()
 }
 #endif
 
-cfgpath.AppendDir( wxT( "kicad" ) );
+cfgpath.AppendDir( name );
+
+return cfgpath;
+}
+
+
+wxString GetKicadConfigPath()
+{
+wxFileName cfgpath;
+
+cfgpath = GetConfigPath( KICAD_CURRENT_CONFIG );
 
 if( !cfgpath.DirExists() )
 {
-cfgpath.Mkdir( wxS_DIR_DEFAULT, wxPATH_MKDIR_FULL );
+// No Current Config, so get the path of the previous config.
+// and copy everything from it.
+wxCopyDir( GetConfigPath( KICAD_PREVIOUS_CONFIG ).GetPath(), 
+   cfgpath.GetPath(), true );
 }
 
 return cfgpath.GetPath();
___
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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

Hi Wayne,

I agree with you about scope creep, however I do see issues for users.

From an end user perspective V5 is a big change. I noticed big changes 
just from missing nightly updates for 2 months.  There may be an 
extended period of time when a user will want to run both versions, for 
many reasons.



On 06/04/18 01:54, Wayne Stambaugh wrote:

We should defer this to v6 unless the fix is simple with little or no
risk of introducing new bugs.  I know it would be nice to have but I
could say that about a lot of things.  Scope creep will prevent us from
ever delivering v5.

Cheers,

Wayne

On 4/5/2018 12:25 PM, Seth Hillbrand wrote:

If we are going to support multiple versions, on the developer side, we
should add a preference versioning to the user configuration directory.
Otherwise, fp-lib-table will being either pointing to v4 or v5
footprints.  Likewise, there are a few preferences that only exist in v5
and will be lost when v4 saves the preference file.

To avoid cluttering the config directory, we could place the v5
configurations in a v5 sub directory.  Configurations would be
preferentially loaded from the v5 directory with a fall-back to the v4
items if v5 items were not found.  Configurations would only be saved to
the v5 subdir.
I agree with this, except I think we should ONLY read the V4 config 
once, when the program detects there is no V5 config sub directory at 
all.  After the V5 config is made and saved, the V4 config should be 
ignored, and they should diverge from that point.


I don't know this code at all, but If no one else is doing it, I can try 
and look at it over the weekend.  But I wont waste time if the decision 
is already final.


If we don't do this can I propose that the V5 packaging make a backup of 
the V4 config so that end users at least have the option of reverting 
without their config being lost.


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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Strontium]

On 04/04/18 18:52, Jean-Samuel Reynaud wrote:

So my questions are:
- Is it usefull ?


Having both versions be able to be installed side by side is immensely 
valuable for an end user, and the development of kicad, in my opinion.


The users can "USE" the stable version for their work.  They can also 
test the Nightly and not worry about it messing with their work.  It 
should mean that general users have a better chance to test the new 
version as it evolves, and they will feel more involved, even if that 
involvement is only posting bugs.  They don't have to choose between 
being on the bleeding edge, and being productive.


It would be equally useful (maybe even more useful) to have kicad V4 and 
V5 installed simultaneously as well.


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] Board Edge clearance problem

[Strontium]

On 07/03/18 18:25, Tomasz Wlostowski wrote:

On 07/03/18 06:34, Strontium wrote:

My second "show stopper" bug for me, using V5 RC2

I also reported this in the bug tracker, again sorry for the double up.

I was trying to layout a board, but Kicad is refusing to let me lay
tracks or vias in close proximity to the board edge.  Its highlighting
the edge, and ignoring any command to drop the via or track segment.


Two questions:

- what's the default track clearance in your design?
- could you send us (in private) the board file?

Tom


Hi Tom,

I just was preparing to send the board, and tested again, and it seems 
in todays update of the nightly PPA the behaviour has changed.  Its no 
longer doing what I reported. So, it would appear that its problem solved.


If you still need me to send the board, let me know.  My clearance is 
0.1524, for everything. And my edge cut is 0.1mm.


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

[Kicad-developers] Board Edge clearance problem

[Strontium]

My second "show stopper" bug for me, using V5 RC2

I also reported this in the bug tracker, again sorry for the double up.

I was trying to layout a board, but Kicad is refusing to let me lay 
tracks or vias in close proximity to the board edge.  Its highlighting 
the edge, and ignoring any command to drop the via or track segment.


The problem is, this proximity seems to be uncontrollable, I can't find 
any option which sets it, or even references it.


Further, the proximity is a really long way from the board edge, which 
makes routing a tight board tedious because you need this excessive and 
unnecessary border.


For example, this is fine: http://i.imgur.com/5hAzrhL.png

But this is not: http://i.imgur.com/2wBHePK.png

You can also see the "halo" is well over the via, and would cover it in 
both positions.


So, it just looks and feels wrong, and seems totally uncontrollable.  I 
should be able to place the annular ring of the via right up against the 
edge of the fill of the zone.  Now it may be this isn't a bug and i have 
my setup wrong, and i would be pleased if it were the case, but if it is 
so, then the option controlling this isn't obvious at all, and the halo 
being shown still looks wildly off.


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

[Kicad-developers] Zone filling problems

[Strontium]

Sorry for posting this, AND also posting a bug report, but i know you 
guys are close to releasing a V5 and i have been testing RC2 from 
nightly PPA and have hit two bugs which would be show stoppers for me, 
and make me want to go back to V4.


First one is a problem with Zone refills using DRC.

If I have a zone, and place a via or track over it from another net.  
And then do a DRC, but select "Refill all zones..." then the DRC 
proceeds without error, and says it refilled the Zone.


However, a visual inspection of the board shows, no the zone did not 
refill and the via and zone now clash because they are not the same net, 
but there is no DRC violation.


Thats what it looks like. But what is really happening is the zone is 
being recalculated, and the DRC is passing because the Zone does now 
actually flow properly around the net overlapping it. BUT what happens 
is the board is not redrawn to show the new zone outline.  Zooming 
around the board, etc, does not cause it to redraw either.  The only 
ways i have found to make it redraw is to manually select the zone for 
editing, or to press "B"


Its a highly disconcerting problem, because the board that kicad 
"understands" and the one it "displays" are out of sync.


The effect is obvious when one does a 3d render of the board, because 
that shows the board that kicad understands, even though in the pcb 
editor its shown as not that.  as shown here: 
http://i.imgur.com/hKfPJ22.png


the other problem i will post separately.

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] Hierarchical Schematic to contain link to pcb

[Strontium]

My 2c, something like this would be useful for fanout of chips, 
especially BGA.  You could have a standard fan out, which included the 
main chip, all its fan out vias, tracks and bypass capacitors.  It would 
then be imported as a module, the schematic represents everything in 
that module.  Its placed on the PCB as a "multipart" component.


But it sounds like a lot of work to implement.

Steven


On 13/11/17 23:11, Kristoffer Ödmark wrote:

Hello!

I suspect this has been discussed before in different formats. But 
anyway.


What would be the major problems or concerns with allowing a schematic 
to have a pcb as file to include? What I mean is that the same way we 
let a symbol have a footprint in eeschema, we let a schematic point to 
a pcb file that is included before footprints are added to the pcb.


Every subschematic has a unique timestamp that could be added to every 
existing footprint in the schematic and should prove a sufficient way 
fix every designator number in the schematic in case a pcb is included 
multiple times.


I guess this would mean that at a later date the pcb-items would need 
to be able to be added to a group of some sort, so that one could 
easily move the newly included pcb as one.


Thinking about it this grouping is actually required, otherwise 
updating the pcb from the schematic might be impossible due to the 
fact that a board may contain items such as segments, which do not 
contain any unique id.


There is a huge gain from this, since it would allow multiple users to 
work on the same pcb in a different manner, allocating a space for 
their subschematic / subpcb etc, and also it would allow design reuse 
much easier.


Problems i see:

When parts of an imported pcb is updated how to handle it?
    - ( Propose to have a toggle to update all from imported pcb, or 
to ignore those coming from an imported pcb )



How should the grouping be available?
    -  ( Propose only let kicad group based on imported pcb and 
therefore every item can only have one group belonging or none group 
belonging, not changeable by the user )



If a subscheet has a subscheet, and both have an assigned pcb, how do 
we add this?

    -  ( Propose that only the highest level pcb be used )

How can one move all the parts of one imported pcb as a group, and how 
to change only a single item of the imported pcb?
    -  ( Have the disambiguation of meny show both the component and 
the group when selecting a component belonging to a group, toggle this 
behaviour on/off in a button from the toolbar, similar to the allow 
drc toggle )


How will this be managed by kicad?
    -  ( Assume that each subpcb and subschematic is a standalone 
project and therefore let the user worry about this, but add a demo 
showcasing this hierarchy with a ./main.{pro,sch,kicad_pcb} and a 
./subpcb/subpcb.{pro,sch,kicad_pcb} )






___
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] GitHub Plugin (my nemesis)

[Strontium]

+1 also
It allows a company to start with the libraries at some point and keep 
them consistent (by forking) and they can easily cherry pick changes or 
do wholesale merges with their changed libraries, as they desire.  And 
for a casual user who just uses things, "as is" it will just work.


On 28/09/17 09:47, Tiger12506 wrote:
+1 on this approach, to me this is the obvious way that it should be 
done. However, my opinion is not important, I'm not a contributor. :)


On 9/27/2017 8:37 PM, David Godfrey wrote:

Hi All

I have to agree with some of the other posters, why not use git as it 
was intended?


Specifically I think the following makes sense.

- Keep the multiple repositories, this helps when a company only 
wants to make certain sets of libs available to it's staff


- Have a master repository that includes all other repositories as 
submodules.


- Have branches that are matched to kicad versions. This allows 
footprint changes in a version safe way.


- Use standard "git clone" (initial download) and "git pull" (update) 
on the main repo which provides the entire set of available libs 
without actually downloading the content for all libs.


- When a specific lib is needed, do similar to what we do now, and 
use "git submodule update --init --recursive $submoduleName" to just 
pull that specific submodule


- Allow the "main" library repo URI to be altered. This enables a 
companies fork of the repo to be used.


- Allow the "main" library repo URI to be ANY valid git URI. That 
means a repo on a local fileserver rather than a http server can be 
used. Along with various security options etc.


- Add a fairly simple scripted tool that's run "on release" to 
retrieve a README.md (an possibly a descriptor/index file) from each 
actual library repo and update those within the "main" repo. This 
removes the need to have the current case where manual edits are 
required to keep the "main" repo in sync with what's available in the 
individual lib's.


To add a new lib, it's then as simple as (from the main repo) doing 
something like

- "git submodule add $URI"
- "./scripts/update-library-indexes.sh"
- "git commit -a -m $'added new module "modulename"\nupdated all 
module descriptions and index'"

- "git push"


All of the above allows the Main repo to be forked by a company (or 
individual) and have their own custom repo's added very easily.
It even allows libraries to be easily excluded or replaced, all using 
extremely well developed management tools.


On a side note, git submodules are stored in the main repository 
basically as URI that includes a commit reference.
That means it's easy to specify a specific library version to include 
in a specific branch/tag of the main repo.



As for the person that said "git isn't available for windows", sorry, 
that's bunkum.
There are many many development environments out there that ONLY run 
on windows that have git integration.
A quick google search for "git for windows" will show what you need 
to know there.


Finally, wrapping git to duplicate the effective API that's currently 
in use should be relatively trivial, resulting in virtually no code 
changes required to KICAD it's self.
Assuming the existing functionality is cleanly wrapped by an API, the 
only real change to KICAD would be the swapout of the module, and 
addition of an easy way to change the URI



I know I haven't covered everything in this email, but it should be a 
good outline for further discussion





___
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] File format version increment

[Strontium]

Hi Adam,

Yes, on Linux one has to choose between Nightly/Stable if using the 
PPA.  The other option is building KiCad yourself, which I can do, but 
many can't/won't.  I was not sure of the situation on other OS's if you 
can install Nightly/Stable simultaneously on Mac, then its more reason 
why the Linux distributions should follow suit.


Steven

On 22/09/17 10:01, Adam Wolf wrote:

Strontium,

I assume you are talking about linux based on the word PPA, but mostly
for other people on the list, you can do this with the MacOS KiCad.

Adam

On Thu, Sep 21, 2017 at 8:59 PM, Strontium <strnty...@gmail.com> wrote:

This is a question for the distribution maintainers,

Is it possible to change the distribution PPA's (etc) so that one can
install the nightly and the stable version of kicad, simultaneously?

When things like file format versions change then people have to make a
choice, do I run nightly and lose backward compatibility OR do I run stable
and lose newer features/the ability to test.   It would be handy to be able
to have Stable installed to do real work, and nightly also installed for
testing, or for boards where you really want access to a new feature early.

Steven



On 20/09/17 00:38, Maciej Sumiński wrote:

For your information: support for long pad and pin names has been just
merged. As the change affects both eeschema and pcbnew, and may result
in files that are not loaded correctly with older versions - the file
format versions had to be incremented.

Regards,
Orson



___
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




___
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] 2: Via Tool

[Strontium]

Hi Orson,

Can, and will, thanks for the feedback.  Ditto for the DRC situation I 
described.


Steven

On 21/09/17 18:09, Maciej Sumiński wrote:

Hi Steven,

The via tool is still quite fresh, so as you have noticed - it might be
lacking in certain cases. Would you please turn it into a bug report?
Your message is already drowning in the mailing list traffic, but a bug
report will stay in the tracker until it is resolved.

Regards,
Orson

On 09/13/2017 05:53 AM, Strontium wrote:

His second criticism is with the via tool.

What he did is lay two tracks on his board, one on either side. (Both
had the same net)

He then pressed the via tool, and dropped vias into the intersections.

The vias created design violations because they are assigned No Net.
Doing DRC does not reconnect them.

This is hostile, especially for a new user.  His complaint was, whats
the point of a via tool if i cant place a via on a track and it "Just
Work".  Seems a reasonable criticism.

We argued about the end cases, but I agree with him that:

1. If you have tracks with the same net on multiple tracks, the via tool
should be able to place a via on the tracks and pick up their net.  It
shouldn't create a Design violation.

2. If you have one track with a net and the other(s) with "No Net" the
via should get the net of the one track that has a net.

3. That a DRC should propagate the net through connectivity of the
connected tracks and vias laid in this way, and it currently doesn't.
It just throws a design violation.

4. With DRC checking enabled, it shouldn't be possible to drop a via if
that via would cause a design violation.  Exactly like its not possible
to lay two tracks with different nets over one another. (For example,
two tracks on different layers, with different nets should not be able
to put a via over them because thats a design violation)

I am not sure if the Via tool is considered complete, or still a work in
progress, however I think these things should be considered as the way
it currently works is unintuitive.

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



___
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] File format version increment

[Strontium]

This is a question for the distribution maintainers,

Is it possible to change the distribution PPA's (etc) so that one can 
install the nightly and the stable version of kicad, simultaneously?


When things like file format versions change then people have to make a 
choice, do I run nightly and lose backward compatibility OR do I run 
stable and lose newer features/the ability to test.   It would be handy 
to be able to have Stable installed to do real work, and nightly also 
installed for testing, or for boards where you really want access to a 
new feature early.


Steven


On 20/09/17 00:38, Maciej Sumiński wrote:

For your information: support for long pad and pin names has been just
merged. As the change affects both eeschema and pcbnew, and may result
in files that are not loaded correctly with older versions - the file
format versions had to be incremented.

Regards,
Orson



___
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] 1: GAL Bug with Window Buttons

[Strontium]

On 13/09/17 13:24, Nick Østergaard wrote:

What version of kicad did he test?

Application: kicad
Version: no-vcs-found-8182369~60~ubuntu16.04.1, release build
Libraries:
wxWidgets 3.0.2
libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-93-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.58.0
Curl: 7.47.0
Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON

___
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] 3: Net Connectivity

[Strontium]

His third criticism is with net connectivity.

What he did was he has a component with 4 GND pads in a row.  He ran a 
track across them (in the middle) and finished it at the last pad.  The 
Track clearly crosses all pads, however the DRC shows them as 
"unconnected" when they are really connected electrically.


His complaint is that this is tedious and unintuitive to lay, and wrong 
from a physical model of the board perspective.  That any copper track 
crossing a pad at any point should be considered connected, because it 
is, it shouldn't need to touch the centre of the pad, which is an 
arbitrary anchor.


Its also not consistent with a track that crosses a pad that is not its 
net.  That track, if it touches the wrong pad at any point throws a DRC 
error, but if it connects to a pad with the correct net (but doesn't end 
on the pads centre) is considered not connected.


There is an edge case where a track only slightly touches a pad, and is 
electrically connected, but Not connected sufficiently for the design, 
but that is not the same thing as being "unconnected" and isn't handled 
by DRC now in any event.


He IS a new user and he naturally has numerous complaints, most of which 
result from frustration with learning a new tool, and I talk him through 
those.  But, I think these three points are valid criticisms that the 
developers should consider in the future.  I will make some entries in 
the bug tracking system to track these, but I wanted feedback first, are 
these "wont fix" or "feature requests", "bugs", etc.


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

[Kicad-developers] 2: Via Tool

[Strontium]

His second criticism is with the via tool.

What he did is lay two tracks on his board, one on either side. (Both 
had the same net)


He then pressed the via tool, and dropped vias into the intersections.

The vias created design violations because they are assigned No Net.  
Doing DRC does not reconnect them.


This is hostile, especially for a new user.  His complaint was, whats 
the point of a via tool if i cant place a via on a track and it "Just 
Work".  Seems a reasonable criticism.


We argued about the end cases, but I agree with him that:

1. If you have tracks with the same net on multiple tracks, the via tool 
should be able to place a via on the tracks and pick up their net.  It 
shouldn't create a Design violation.


2. If you have one track with a net and the other(s) with "No Net" the 
via should get the net of the one track that has a net.


3. That a DRC should propagate the net through connectivity of the 
connected tracks and vias laid in this way, and it currently doesn't.  
It just throws a design violation.


4. With DRC checking enabled, it shouldn't be possible to drop a via if 
that via would cause a design violation.  Exactly like its not possible 
to lay two tracks with different nets over one another. (For example, 
two tracks on different layers, with different nets should not be able 
to put a via over them because thats a design violation)


I am not sure if the Via tool is considered complete, or still a work in 
progress, however I think these things should be considered as the way 
it currently works is unintuitive.


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

[Kicad-developers] 1: GAL Bug with Window Buttons

[Strontium]

Hi all,

Background: My father is a hardware engineer, he has been doing it since 
the early 70s learning in the RAAF, laying boards using tape, so he has 
a lot of experience.  He is retired, but still likes to design boards, 
and I have convinced him to give KiCAD a go.  He has been using old 
versions of Altium and still uses Protel 99SE, but would like to use 
KiCAD because he doesn't want to use windows in a VM any more if he can 
avoid it, he wants to use Linux native.


He has a number of problems adapting to the software and I will lay 
those out over three messages, one is a clear bug in GAL, the others are 
not as clear, although I think his criticisms have merit and are useful 
to consider.  He is using the nightly build from PPA, so all the 
criticisms are directed to KiCAD at that state.


1. The window sliders/buttons on the GAL Canvas do not function.

If you press left/right/up/down, nothing happens.

If you click the mouse in the slider space, the slider bar moves, but 
nothing updates on the screen.


The only thing the sliders do is if you grab them and drag them, the 
canvas updates.


In Legacy, these buttons/sliders work as expected and one would imagine 
they should do exactly the same thing in GAL Canvas.  I think this is a bug.


The other two issues I will put in their own posts.

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] Python script offered as example for Action Plugin and wxFormBuilder integration

[Strontium]

Hello Wayne and Greg,

Can I suggest just adopting PEP8 for Python code formatting.  Its clean, 
well documented, and there are plenty of linters to check conformance.  
And if there is anything in PEP8 that is annoying for KiCad development 
(cant imagine what) just specify an exclusion or exception.


Steven

On 12/08/17 22:15, Wayne Stambaugh wrote:

On 8/11/2017 10:08 PM, Greg Smith wrote:

...

Suggestions on coding style, functionality, integration technique are
welcome!

We have not defined a Python coding style.  It's something that needs to
be done but no one has had the time to do it.  Please look at some of
the existing Python code in the KiCad source repo and follow what others
have done.  The last time I looked (which admittedly has been a while),
the formatting of our Python code was pretty consistent.

...


___
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] Component table improvements

[Strontium]

I agree with this decision as well but for different reasons.

The more I get into small scale self manufacturing, the more I am 
persuaded by the argument that you want to keep as little BoM 
information in the Kicad schematic fields as reasonably possible. It 
becomes a maintenance nightmare, an external BoM tool is what is needed 
which bridges Kicads schematic information and true BoM part 
information.  If you are making one or two boards you can store it all 
inside your schematic, but go to 3 or 4 and you quickly feel like you 
are crushing rocks re-entering the same information for the same 
components all over again.  And if you want to change something, then 
you have to do it for every component you have of that part, in every 
schematic that uses it. Then you have equivalents, costings, inventory 
control, supplier information, etc etc. It quickly becomes unmanageable 
if you try and hold this information in a schematic.


If you are trying to generate a CSV or TSV to upload to Mouser for 
costing, it will be subtly different to what a contract manufacturer 
will want from you, etc.  Because of this, no two designers will come up 
with the same scheme to specify this BoM information, it will depend 
what they want to use it for.


Its better to store an abstract or general piece of information in the 
schematic which can be used by an external BoM tool to generate a true 
BoM for you, in the format/s you or your manufacturer require.  And if 
you are going to do that, its just as easy to directly read the 
schematic files, as it is to read a BoM exported in CSV format.


See: https://github.com/KiCad/kicad-library-utils for python code to 
read a schematic directly.


Steven

On 13/05/17 02:18, jp charras wrote:

Le 12/05/2017 à 13:55, Oliver Walters a écrit :

This feature was IN this branch of code but was vetoed. It was WYSIWYG BoM with 
export to:

*SV
XML
HTML

Wayne mentioned that KiCad used to have such a BOM export tool but I haven't 
been using KiCad long
enough to have experienced it.

If there is real need for such a feature then I leave that to the project leads 
to decide. I have
the code still, and it could be implemented very easily.

Hi Oliver,

As Wayne said, we don't like a BOM export tool *written in C++ inside* the 
Kicad code.

Here is the reason:
A few years ago, this code was existing and (as Wayne said) created the same 
BOM files (txt, csv...)
as your code.

What was the result:
Roughly ever month, a bug or request was filled to change something in BOM 
files.
I am guessing we cannot find 2 guys who want the same BOM format or option.

Therefore, the C++ code inside the Kicad code was dropped, and replaced by 
external scripts (Python
or XSL) to transform the XML netlist created by Kicad to an other list (BOM, 
but also other netlist
formats).

*Trust me*, this was a *wise* decision (It was not my decision, but was a good 
decision).

Therefore: if you want to create the BOM you like, write a Python script to do 
that from a netlist
(it is easy to run from Eeschema: see the BOM or Netlist generator), but do not 
try to merge this
code in Kicad C++ sources: your script will never generate the "right" BOM.
But a Python script is very easy to modify.

There are already many BOM generators written in Python.





___
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] [FEATURE] Component table viewer

[Strontium]

Hi Oliver,

On 06/05/17 12:13, Oliver Walters wrote:


And it just so happens that in this schematic NO components have
been edited to include these default fields/values, so, they don't
show up in the component table. 



I have a patch to fix this now - if a field is empty and a template 
value exists, that is placed there instead.


Also, editing Multipart components is a little quirky, If you
change a field for a multi-part component, all "parts" update to
that value, but if any parts have different values, only one is
shown in the table and its not clear that the underlying multipart
field is inconsistent.


This is a hard one as really, multi-part components should /not/ have 
different values in various fields! I had thought about adding another 
level (with an arrow as you suggest) but I think it becomes too 
complicated.
Yes, I agree with you on this, Its confusing that KiCad doesn't 
synchronise those fields.  BUT I think maybe its done that way to help 
facilitate swapping parts between multiple multi-part components.


Maybe a developer who knows more about this can weigh in?  Is having 
different field value/fields in a single multi-part component a 
"Feature" or a "Quirk"?  And if a "Feature" what's its purpose?


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] [FEATURE] Component table viewer

[Strontium]

Oliver,

This is one of my components:
http://i.imgur.com/QXyCXXt.png

This is the component table:
http://i.imgur.com/F2WTRC2.png

The MFG, MPN or EQUIVOK fields in the component aren't shown in the table!

And in doing that I worked out my problem :)

I have MFG/MPN/EQUIVOK defined as "Default Fields" with default values.
And because the component hasn't been edited, I can edit it and SEE the 
default fields and default values BUT unless I change something they are 
not saved with the component.  And it just so happens that in this 
schematic NO components have been edited to include these default 
fields/values, so, they don't show up in the component table.


It would be nice if the "Default Fields" and their default values show 
in the table if they weren't defined for the component, maybe 
highlighted in some way (Italic, light grey, or something) to indicate 
they are defaulted and not actually set. But now I know why I couldn't 
see them its not a big deal so consider this an Enhancement request.


Also, editing Multipart components is a little quirky, If you change a 
field for a multi-part component, all "parts" update to that value, but 
if any parts have different values, only one is shown in the table and 
its not clear that the underlying multipart field is inconsistent.  
Again its not a big deal, I just noticed it.  Maybe multipart components 
should work like grouped components, i.e. you can click an arrow and see 
all the parts and edit them individually, or edit the top level 
component and set them all to the same value?  I'm not really sure if 
this is a good idea or not.


I'm working on an external BOM management tool. It reads a schematic 
live while you edit it in Kicad, and costs it from octopart and/or a 
database of locally defined components, updating in real time.  This 
tool you have made is going to save me an enormous amount of time 
editing schematics and getting all the field metadata consistent.  Thank 
you.


Two more enhancement ideas:
1. A way to update the schematic from edits without closing the table view.
2. A way to revert the last edit (undo)

Steven

On 05/05/17 20:56, Oliver Walters wrote:

Steven,

Unless you mean something different to what I think "custom fields" 
means, then this is already the case - any extra fields (beyond 
REFERENCE / FOOTPRINT / DATSHEET / VALUE) are preesnt to be edited in 
the table...


On Fri, May 5, 2017 at 10:51 PM, Strontium <strnty...@gmail.com 
<mailto:strnty...@gmail.com>> wrote:


Hi Oliver,

Just had a chance to check out your component table viewer, its
nice.  Great work.

Is it on your roadmap to be able to view/edit a components custom
fields?

Regards,
Steven

On 03/05/17 05:35, Oliver Walters wrote:

Wayne,

Thanks for merging!

I will address those points at some stage - there are other
ideas I have too but I thought it was better to get the first
iteration done and make incremental improvements.

Regards,
Oliver



___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<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] [FEATURE] Component table viewer

[Strontium]

Hi Oliver,

Just had a chance to check out your component table viewer, its nice.  
Great work.


Is it on your roadmap to be able to view/edit a components custom fields?

Regards,
Steven

On 03/05/17 05:35, Oliver Walters wrote:

Wayne,

Thanks for merging!

I will address those points at some stage - there are other ideas I 
have too but I thought it was better to get the first iteration done 
and make incremental improvements.


Regards,
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] Eagle import - zone filling issues

[Strontium]

I Agree,

Minimum clearance from an edge is not the same thing as minimum 
clearance from a trace.  Would like to see this also.


The idea to have the zone clearances optionally come from the Design 
Rules is also good.


Steven

On 01/05/17 08:28, José Ignacio wrote:
While changing the format it would also be great if a separate 
clearance could be specified between the zone and board edges vs trace 
clearances, at least leave the capability in the format if it can't be 
implemented yet. I've found that the required copper pullback in some 
cases is much higher than what would be desirable for regular 
zone-trace clearances, which required me to get creative with the zone 
outlines.


Thanks,
Jose

On Sun, Apr 30, 2017 at 5:32 PM, Tomasz Wlostowski 
> wrote:


On 30.04.2017 21:02, Lachlan Audas wrote:
> Here's the link,
>
http://www.cosmosc.com/example/A10-A20-OLINUXINO-MICRO-4GB_Rev_D.brd

> it's in eagle format, so import  under pcbnew.
> I should of added that viewing the (E)properties and make no changes
> (but hitting the OK instead of the Cancel button) regenerates
the flood
> fill.
> while not wrong,   it may be worth adding a change bit,   to the
> properties requester,   and only regenerates if something has
changed.
> But I suppose that's nit picking ;)
>

Hi,

Lachlan sent me a complex board in Eagle that has several copper
zones,
each with different clearances, which filled incorrectly or didn't
fill
at all. There were some trivial issues (e.g. inverted filling
priority),
but there is one that needs discussion:

In pcbnew, each zone must have manually assignned clearance (in the
property window). In Eagle or Altium, if there's no clearance
specified,
the program takes the clearance set in the Design Rules for the
net the
zone belongs to.

I propose to add a similar feature to Kicad, that is:
- add a checkbox "use custom clearance" in the zone properties window
- if not checked, take the netclass clearance.

This unfortunately requires a small file format change. Would you
agree
with that?

Also, many thanks to Lachlan for spotting this problem!

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



___
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] [RFC] BOM Editor

[Strontium]

Oliver,

Thats does sound fantastic, and it should be incorporated into kicad, in 
my opinion, because its not just a BOM Tool, it would be component 
management with BOM export and is complimentary to external BOM tools 
not a replacement for them.


Steven

On 14/02/17 18:08, Oliver Walters wrote:

Steven,

I am currently playing around with this idea, actually. I'm converting 
the layout from a wxGrid to wxDataViewCtrl which allows each "group" 
to be expanded (to show which components are contained therein) and 
many other advanced features.


This may turn into more than just a BOM tool.

On Tue, Feb 14, 2017 at 9:00 PM, Strontium <strnty...@gmail.com 
<mailto:strnty...@gmail.com>> wrote:


This looks really nice, this would be awesome if it allowed you to
edit the BOM as well, for example, your line 3, change 0.1uf to
1uf and C1, C7, C8, C9, C10 and C16 all change their value in the
schematic to match.  Obviously there are things you wouldnt be
able to edit, such as Reference and Qty, but everything else
should be editable.

It would make keeping component annotations orderly very simple
and bulk edits very very simple.

Steven


On 14/02/17 14:20, Oliver Walters wrote:

Hi all,

I have been working on a BOM exporter built into KiCad (in
addition to the external BOM script functionality that already
exists).

It's not ready yet to be merged but I am showing the progress
here to get any input and in case anyone else is working on a
similar feature.

Here's a screenshot of the current tool (launched from eeschema)

http://i.imgur.com/nb3mqqx.png

Features that are implemented thus far:
- Extract all component fields
- Group components based on user-selectable fields
- Show conflicts when groups cannot be merged
- Show/hide various columns
- Sort part references in natural fashion, e.g. C99 < C100
- CSV export
- TSV export
- HTML export

Features still to be implemented:
- Sort by column (ascending, descending)
- Save BOM preferences to project file
- Add filters to each column to include/exclude groups by
wildcard or regex
- Back-annotate component data (bulk update all components in a
group)

So, thoughts? I feel that a proper BOM tool has been sorely
missing from Kicad thus far.

If I continue to work on this is it something that is likely to
be merged?

Regards,
Oliver


___
Mailing list:https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to :kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe :https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   :https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>


___ Mailing list:
https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers> Post to :
kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net> Unsubscribe :
https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers> More help   :
https://help.launchpad.net/ListHelp
<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] [RFC] BOM Editor

[Strontium]

This looks really nice, this would be awesome if it allowed you to edit 
the BOM as well, for example, your line 3, change 0.1uf to 1uf and C1, 
C7, C8, C9, C10 and C16 all change their value in the schematic to 
match.  Obviously there are things you wouldnt be able to edit, such as 
Reference and Qty, but everything else should be editable.


It would make keeping component annotations orderly very simple and bulk 
edits very very simple.


Steven

On 14/02/17 14:20, Oliver Walters wrote:

Hi all,

I have been working on a BOM exporter built into KiCad (in addition to 
the external BOM script functionality that already exists).


It's not ready yet to be merged but I am showing the progress here to 
get any input and in case anyone else is working on a similar feature.


Here's a screenshot of the current tool (launched from eeschema)

http://i.imgur.com/nb3mqqx.png

Features that are implemented thus far:
- Extract all component fields
- Group components based on user-selectable fields
- Show conflicts when groups cannot be merged
- Show/hide various columns
- Sort part references in natural fashion, e.g. C99 < C100
- CSV export
- TSV export
- HTML export

Features still to be implemented:
- Sort by column (ascending, descending)
- Save BOM preferences to project file
- Add filters to each column to include/exclude groups by wildcard or 
regex

- Back-annotate component data (bulk update all components in a group)

So, thoughts? I feel that a proper BOM tool has been sorely missing 
from Kicad thus far.


If I continue to work on this is it something that is likely to be merged?

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



___
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] .SWEET file suggestion

[Strontium]

Can I make the suggestion, for CPU/MCU/FPGA type parts that have lots of 
configurable pins, drawing an actual component is tedious and somewhat 
pointless as its just a box (or multiple boxes, one for each subunit) 
with pins.


Some CPU's have so many functional units and pins that fitting it all on 
one giant box is also pointless as it may not even fit on a a3 page, so 
you end up with multiple parts in a component for various functional 
divisions and then multiple versions of the same component to account 
for different GPIO multiplexing arrangements, which change and evolve as 
the design evolves.  It quickly becomes a maintenance problem.


For example, you decide GPIO 7 is good for a LED, but later, oh no GPIO 
7 is the last SPI chip select, oh ok, swap it with GPIO 184, but no, its 
not that easy now you have to edit the component to reflect it, and now 
every design you have that uses the same CPU ends up with a unique 
version of the component to match its GPIO muxing.


I believe it would be far preferable for these types of components 
simply to define the functions of each pin in a table, and then when 
placing the part, its just an empty box (like a nested sheet).  You then 
right click on the part select "Add pin" and then select from the list 
of unplaced pins the one you want, and its function.  You then drop the 
pin on one of the 4 sides of the box.


Basically like the nested sheet/sheet pin in concept, except you can 
select which pin to import from the list of pins not yet utilised.


This way one only need to define a single component, and editing it is 
just a matter of editing a table of pins, which is very easy compared to 
drawing a component with 100's of pins.  You then "draw" the part 
uniquely for your design on your schematic, as you use each pin, but you 
only ever have one part defined in your library.


Schematic DRC would then have an Error/Warning for pins not used. This 
would make it much easier with complex parts, for example, you have a 
USB page, you only need the pins from the cpu chip for USB sub unit, and 
if you decide to change the OTG ID pin to a different GPIO, you don't 
need to redraw your part, or have multiple "versions" of your part, you 
just delete the old ID GPIO pin, and add the new one.


This would be in addition to the current graphical parts, which are 
preferable for basic components and standard building blocks.


Steven

On 13/02/17 18:32, Oliver Walters wrote:
Here is a good example of where such a feature would be very well 
received: 
https://forum.kicad.info/t/component-occupies-entire-page-newbie/5272/22


On Thu, Jan 5, 2017 at 12:10 AM, Chris Pavlina 
> wrote:


I second this suggestion. Numerous people have been proposing this for
quite a long time in IRC, it's a popular idea. A large number of parts
are configurable, and forcing the pins to be non-configurable
makes ERC
pretty weak.

On Wed, Jan 04, 2017 at 07:22:37PM +1100, Oliver Walters wrote:
> As far as I am aware, this (
> https://lists.launchpad.net/kicad-developers/msg23302.html
) is
the latest
> proposal for the new symbol format.
>
> Is this the case?
>
> Reading through this I have an idea that I think will be very
useful.
>
> Currently each PIN can only have one TYPE (INPUT, OUTPUT,
OPEN-COLLECTOR,
> etc) which means that for parts with multiple
alternate-functions on a pin,
> ERC is essentially useless if the pin can be used as an INPUT or
an OUTPUT
> (or something else).
>
> Further, labelling all the possible alternate functions on a pin
means that
> either the symbol grows exceedingly wide, or many functions are
missed.
>
> I suggest that the pin type should have facility for alternate
functions to
> be specified which would solve both of these problems. Once a
symbol is
> placed in the schematic, any multi-function pins are set to
"default"
> values (e.g. GPIO for a micro) but the other functions can be
selected.
>
> See proposed "addition" to format here:
>
> http://i.imgur.com/5m38eTT.png
>
> 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



___
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] [RFC] Standard field for manufacturer part number in schematic symbols

[Strontium]

My 2c for what its worth,

The properties we are talking about are just KEY:Value pairs, and i 
don't think its wise to change from that.  Its simple and easily handles 
most possibilities.


What I think would be useful however is a customisable "set" of standard 
"keys", So when you go into the properties of a placed component, you 
can just select from your "standard" set of keys, and populate the value 
fields.


To handle what Kasper suggests, one would have two standard keys:
"MPN" and "MANUFACTURER", or a standard field format for MPN that can 
hold both the manufacturer and part number.


The issue with the keys isnt that they are customisable, its that they 
are easy to type wrong/get inconsistent, you have to remember what keys 
you are using, did you leave any out, etc, etc.


In this situation, we could define a "default" set of standard keys, 
like "MPN", etc.  Users would be able to define their own sets, add or 
delete from the "default" set, etc.  Tool writers would invariably use 
the defaults, unless there was a good reason not to.  Its not 
proscriptive, just suggestive.


So, rather than a change to the schematic file, its a UI change and a 
change to an existing config file, or a (my preference) new config file.


As a suggestion, a "standard" key would be defined as:
"KEY Name", "Help String", "Type"|"Validity RegEx"

The KeyName is shown in a drop down, hovering over it produces the help 
text, anything entered in the Value is checked against the optional 
Validity RegEx or Type, (eg, Type could be "filename", and its checked 
to be a valid file).


This doesn't change the ability to add a fully customised Key:Value, 
just like one can now, its just a type validating shortcut to help keep 
ones fields assigned to schematic parts on their schematic orderly and 
consistent.


One change I would LOVE to see however, is the ability to add properties 
to nets on the schematic, as well as components.  I would also LOVE to 
be able to propagate those properties to their respective features on 
the PCB via the net list, but that's a different conversation.


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] Via Stitching

[Strontium]

Hello Heikki,

Can you explain the logic you are using to determine the net of the vias 
during DRC reconnect?  It looks like you are only considering the top 
and bottom layer, but stitching vias may be stitching internal layers?


Steven


On 23/10/16 21:48, Heikki Pulkkinen wrote:

Hi Wayne and all,

About that my suggestion of Via Stitching. I do some tests and found 
that if DRC first fill zones and then do tests it does not break 
anything. if you forgot to Fill or Refill zoenes before running DRC.


Regards

Heikki


On Fri, Oct 21, 2016 at 6:41 PM, Heikki Pulkkinen > wrote:


Hi Wayne,

If you try this, I send the last full patch of that Via Stitching.
Do not care other patches in mailing list, they are more or less
incomplete.

Regards

Heikki

On Tue, Oct 18, 2016 at 3:22 PM, Wayne Stambaugh
> wrote:

I will look at when I get a chance.  When that will be I
cannot say for
sure.  I've just been really busy.  I will try to get around
to it this
weekend.

Cheers,

Wayne

On 10/17/2016 3:40 PM, Jakub Kozdon wrote:
> Hi, it looks usable.
>
> Don't know if it is visible for all, but Wayne, what do you
think about it?
>
> Jakub
>
> Dne 16.10.2016 v 19:23 Heikki Pulkkinen napsal(a):
>> Hi,
>>
>> I add array feature to my Via Stitching. And an another
slowly video
>> to watch.
>> https://youtu.be/28nfoZPg2bg
>>
>> Full fixed patch and array test patch. More work have to be
done, but
>> this was easy start.
>>
>> Regards
>>
>> Heikki
>>
>> On Thu, Oct 13, 2016 at 7:23 PM, Heikki Pulkkinen

>> >> wrote:
>>
>> Hi,
>>
>> Here is demovideo about via stitching. It is slowly,
because of
>> slowly machine. I do some development too, so full patch is
>> attached too.
>>
>> On Tue, Oct 11, 2016 at 5:49 PM, Marcos Chaparro
>> 
>>
wrote:
>>
>> Hi Heikki,
>> is there any chance to make some screenshots or
video about
>> this? Some of us do compile kicad to get the latest and
>> greatest but never applied a patch for a particular
feature.
>>
>> Regards
>>
>>
>> Marcos
>>
>> On Sat, Oct 8, 2016 at 7:04 AM, Heikki Pulkkinen
>> 
>> wrote:
>>
>> Hi,
>>
>> Putting back that my via stitching tool to
routing tool.
>> It is better that way, I think. All via tools
are in same
>> place, and it adds vias to pours only from hotkeys.
>>
>>
>>
>> On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen
>> 
>> wrote:
>>
>> Hi,
>>
>> Finally Via Stitching without tracks is at
zone tool.
>> I tested it little bit, but more tests are
needed.
>> This patch replace all other patches. Do
not use them,
>> use only this patch. I think this is worth
of try. I
>> am going to use it anyway, even if it do
not get any
>> acceptance. First patch is for Fedora
users. It makes
>> possible to build Kicad in Fedora release
wxWidgets
>> libs whitout building wxWidget from source.
I do not
>> know has anybody else that problem, but I had.
>>
>>
>> Heikki
>>
>> On Tue, Sep 27, 2016 at 6:46 PM, Heikki
Pulkkinen
>> 
>> wrote:
>>
>> Hi
>>
>> And I really practice. I made
improvement and
>> forgot to copy all. So improvement is
in these two
 

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

[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

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

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

Re: [Kicad-developers] Net propagation/connectivity calculation [was: pcbnew - enable editing of associated net for tracks]

[Strontium]

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

Hi all,

There's been another long thread on stitching vias/net propagation. Let
me add my 3 cents.

The whole subject is more complex, as Wayne and JP already mentioned
many times.
I disagree, I think the issue is portrayed to be far more difficult than 
the reality.


The problem is a designer can lay a Via using standard Kicad tools, and 
then Kicad will change that Via from the net it was assigned to, to 
Unassigned.


Thats the problem.

There is a solution, just make sure any Via (or track stub) that is 
Unassigned after a DRC pass is reverted back to the Net it had BEFORE 
the DRC pass.  It works, is simple, and does not require any changes to 
the way Kicad works in the face of the user.


There may be 100's of reasons why DRC is not great at the moment, and it 
should be re-written, etc, etc. But that just kicks this BUG down the 
road to a never never future, and meanwhile, designers using Kicad, 
maybe for the first time have a very jarring WTF moment when they lay a 
via, and suddenly at some seemingly random point, and without warning, 
it goes from being a GND Via, to being "Unassigned" and Oh, don't forget 
nothing highlights this to them, except a visual inspection.



The root of the problem is the legacy's connectivity calculation/check
algorithm (class CONNECTIONS), which:
- propagates track/via net codes from the pads they're connected to,
- participates in finding isolated copper islands in zones,
- performs a connectivity check.

It has several drawbacks, though:
- Doesn't handle zones properly when checking board's connectivity. This
is the reason why allowing the user to select a net for a via/track is
*dangerous*. See the attached drawing - the top two zones are assigned
the net GND, same as the via that stitches them together. They are not
connected to any pad, though, but the board passes the DRC without any
error.
That's a different problem to the existing one.  The VIA has a GND Net, 
KiCad shouldn't (in my lonely opinion) change that to Unassigned, just 
because its not capable of dealing with it automatically.

- Doesn't handle overlapping zones. The rightmost zone has the net GND,
but it's not filled at all!
Again a different problem.  The problem is not anything about Kicads DRC 
not handling fills.  Even if it did, it would not be able to reassign 
the vias through some magic, because overlapping fill planes could be 
"ANY" or "None" of the intended net for the stitching Via.  Its why I 
say, once a via is placed, if KiCad can not UNAMBIGUOUSLY determine its 
connectivity it should leave the net assigned to it alone.


Changing it to "Unassigned" only makes the problem WORSE and doesn't in 
any way make it better.

- It's difficult to extend. We'd like to have arcs/other shapes on
copper layers with proper connectivity check sooner or later!
Again, different problem, the maintainability of the DRC code is not the 
issue at hand.

- It's slow. Net propagation on Chris's motherboard takes ~6 seconds.
Again, different problem, the speed of the DRC code is not the issue at 
hand.


Therefore, I've decided to rewrite the algorithm. My assumptions were:

Tom, rewriting the DRC code is probably a worthy goal, and I would be 
the last one to defend the existing code base,  but, unless someone can 
resolve the issue of backtracking a isolated Via to its intended Net 
based on connectivity ALONE, then the ONLY solution is not to change it 
to unassigned in the first place.


Which is EXACTLY what the patch I proposed oh so long ago achieves. You 
will need to do the same thing, otherwise you will have the same 
problem, you will rip up all the net assignments, like the existing DRC 
code, You will rebuild all the unambiguous connectivity, and then you 
will be left with a bunch of entities (lets say they are vias) and you 
will not be able to UNAMBIGUOUSLY decide what net they SHOULD be 
assigned to based on board connectivity alone, and you will end up with 
"Unassigned Vias".


So while rewriting the DRC code is probably a fantastic idea, what's 
actually preventing the application of the patch I proposed, strictly on 
its technical merits, and not on the basis that one day we might have 
different DRC code which somehow (How, no one can actually say) handles it.


More importantly, has anyone actually applied the patch I proposed to 
KiCad and given it a try, before declaring the problem as unsolvable, or 
much more complex than it really is.  Because I was never given a single 
instance of a technical problem that it introduces and I never came 
across any after extensive use.


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

[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

[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

[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

[Kicad-developers] Kicad Fields, was Re: [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Strontium]

I split this from the net-ties, etc RFC because its drifting off topic 
from that discussion.


I am not sure I understand the rationale to "It should also
be limited to passing information to external tools such as simulators
and scripts such as Tom's proposal"?

Both the Footprint and the Component Reference are "Fields" and 
key:value pairs.  I would imaging these are the first Fields that any 
new Kicad user works with.


Kicad has functionality to work with those "Fields" and they are core 
information NOT just for external tools, they also convey information 
from Schematic to PCB.  Yet they are also just Key:Value field pairs.


I agree that it requires documentation if the number of fields grows, 
especially if they are not explicitly included like the default Field 
list automatically includes Footprint and reference.  Surely one way to 
mitigate that is to have a list of "standard" Fields that can be 
selected from in addition to typing them in.  It would also be possible 
to have a validator or entry dialogue for a "standard" fields "value", 
similar to the footprint field.  This is not a design proposal, merely a 
suggestion of how this could be handled.


It would also still be very "generally" useful to be able to add fields 
to nets, and for that information to be able to propagate to the PCB 
elements they reflect.  Alternatively (and I actually think its 
preferable) some mechanism to query that information from the schematic, 
given a PCB object, eliminates the need to propagate it into the PCB 
file and keeps it DRY.


Whether for a core feature or not, Properly implemented, I can easily 
imagine fields that carry arbitrary information between Schematic/PCB 
being a killer feature, especially for scripting. It would then make it 
easy to create scripts for all sorts of purposes and for their operation 
to be generally parametrisable and documented in the schematic.  
Something which now is not possible.


Examples: You could have a python script which produces tuned antennas 
parametrically, and does it based on the parameters specified in the 
schematic.
In the schematic, you place a component for a "mounting hole" you 
declare for the "mounting hole" its actual co-ordinates, as it is a 
constraint.  Now a script run on the PCB can ensure that the mounting 
holes are located in "exactly" the correct location as specified in the 
schematic.
You could create a schematic representation for your board 
"outline", and the field is the name of a DXF. In pcbnew, a script can 
read that, and automatically load the DXF and draw the outline on the 
outline layer.  Change the DXF and the PCB can easily and quickly be 
updated to redraw the outline layer.


It would clearly be up to the developer of the script to document the 
parameters and how the script is used, as its not "core" functionality.  
BUT, a full library of "extended" functionality could grow around this 
feature and it makes kicad significantly more powerful and significantly 
easier to extend.  I believe users would quickly become accustomed to 
looking in the library for the "extended" features they want, as their 
needs grow.





On 04/05/16 22:57, Wayne Stambaugh wrote:

The use of fields for arbitrary data is indeed powerful.  It should also
be limited to passing information to external tools such as simulators
and scripts such as Tom's proposal.  Anything that is supported as a
feature in KiCad should be part of the schematic file format and fully
supported by the schematic editor.  The problem with using fields is the
user has to know how to define all of the attributes correctly which
requires thorough documentation.  I don't see this as a good solution
for the average user.  This is a bit like using regular expressions.
They are really powerful but only a small number of users (typically
developers) will actually know how to use them effectively.

On 5/3/2016 7:13 PM, Strontium wrote:

My 2c.

One of the fantastically useful features of eeschema is components have
an "arbitrary" list of key:value pairs (fields) attached to them as
attributes.

Can I suggest that such a feature attached to objects on the PCB would
be even more powerful/useful.

It would mean that changes like the ones suggested would not require
further format changes to the pcb file, these attributes can be
added/deleted at will as they are just a key:value pair.  It would also
make the file format backward/forward compatible, pcbnew wont care what
the key:values are, it can read/edit/propagate them.  If functionality
exists to utilise them then it can use it, if not, they are passive,
just like eeschema.

Further, the key:value pairs in eeschema could be imported into the
matching pcb objects, so that there is only 1 place that needs to be
edited to set them (the schematic). (I actually think that

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Strontium]

My 2c.

One of the fantastically useful features of eeschema is components have 
an "arbitrary" list of key:value pairs (fields) attached to them as 
attributes.


Can I suggest that such a feature attached to objects on the PCB would 
be even more powerful/useful.


It would mean that changes like the ones suggested would not require 
further format changes to the pcb file, these attributes can be 
added/deleted at will as they are just a key:value pair. It would also 
make the file format backward/forward compatible, pcbnew wont care what 
the key:values are, it can read/edit/propagate them.  If functionality 
exists to utilise them then it can use it, if not, they are passive, 
just like eeschema.


Further, the key:value pairs in eeschema could be imported into the 
matching pcb objects, so that there is only 1 place that needs to be 
edited to set them (the schematic). (I actually think that should be the 
proper place to set them)


And by objects I mean both components AND nets. At the moment only 
components have "fields" on the schematic, the ability to attach them to 
nets would be mighty handy.


It would also be super useful for python scripting, because you can 
tag/parametrise your objects on the pcb and your scripts can then, 
easily, only do things with the appropriately tagged entities.


FOR EXAMPLE:

On the schematic, a key value pair is added to a net:
IMPEDANCE:50
This attribute is set as visible, so when the schematic is printed its 
OBVIOUS that the net needs to be 50Ohm impedance. (It would be great on 
schematic if the visible flag had 3 states: invisible, value only, 
key+value)


On the PCB, a python script is run "adjust_impedance", it scans all nets 
looking for ones with the "IMPEDANCE" key, and then adjusts the width of 
the trace to have that impedance, as required. And if it can't, it 
generates a list of nets which are not the correct impedance, based on 
the board parameters as set in the schematic.


ALL of the features suggested below would be easier to implement with 
such a unified attribute system between schematic/pcb AND would mean 
that fewer changes need to be made to the file formats long term.


Steven J



On 03/05/16 20:40, Tomasz Wlostowski wrote:

Hi all,

Recently there has been a lot of discussion on these features. Here's a
short proposal how we could hit all three birds with one stone:

Changes to SCH:
- none

Changes to netlist import:
- auto_generate flag for SCH components - when set, invokes a Python
script/C++ plugin which updates the PCB footprint of the component
depending on its SCH parameters (e.g. produces a microstrip footprint
based on Width/Length parameters defined on SCH).
- write some microwave component generator plugins (or port the existing
tools). Perhaps a good job for Python.

Changes to PCB:
1) Add two flags to each graphical primitive within a footprint:
- net_tie: DRC treats the primitive as non-conducting and doesn't throw
a short circuit error (see drawing A)
- net_inherit = pad_number: the primitive will take the net of the pad
with given pad_number (see drawing B)
2) Add new 'anchor' virtual pad type.
- indicates the point to attach a trace/via when routing the component.
- exists on a single copper layer.
- has no physical copper.
- has an optional direction vector which denotes how it can be connected
with a trace/other anchor pad (see drawing C)
- has a circular perimeter (maybe other shapes in the future if needed).
Objects intersecting the graphical primitive outside the anchor
perimeter are considered colliding by the DRC (see drawing D) even if
they have the same net.
3) modify .kicad_pcb/footprint formats to support the above:
- extend fp_* entities: net_tie & net_inherit flags
- extend pad entity: add anchor pad type, perimeter radius and direction
vector.
4) modify DRC to support the above (we can benefit from the work already
done by JP)


Advantages:
- microwave footprints generated straight from the schematics.
- net ties for free (since based on the same idea as microwave components)
- custom footprint copper shapes almost for free (costs one extra flag &
some changes in netlist importer)
- minimum changes to file formats & data structures.

The attached drawing shows use cases for all of the above and explains
the concept of anchors.

Looking forward to your feedback,
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] Opening pcbnew from kicad: ImportError: No module named pcbnew

[Strontium]

As far as i know wxPython, which kicad requires for python scripting, 
does not support py3k.


There is https://github.com/wxWidgets/Phoenix but i'm not sure how 
compatible that is with wxPython, or if it is compatible with py2k.


Steven

On 11/01/16 16:46, Nick Østergaard wrote:

Ohh yeah, I did not notice that before. That must be why it can't find
it. The scripting thing does not support py3k. We should really try to
make it support both. I hope someone volunteers, I myself, does not
know what it takes in the swig context.

But I can tell that on my system (archlinux) I have both python 3 and
python 2.7 installed with the default python being 3. But here it
works fine. Maybe Clemens only have python 3 installed?

2016-01-11 9:35 GMT+01:00 Johannes Maibaum :

Hi,

Am 11.01.2016 um 00:31 schrieb Clemens Koller:

$ PYTHONPATH=~/SW/lib/python2.7/site-packages python
Python 3.5.1 (default, Dec  7 2015, 12:58:09)
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sys
print(sys.path)

['', '/home/admin/SW/lib/python2.7/site-packages',
'/usr/lib/python35.zip', '/usr/lib/python3.5',
'/usr/lib/python3.5/plat-linux', '/usr/lib/python3.5/lib-dynload',
'/usr/lib/python3.5/site-packages']



Just a blind guess after seeing this: have you ever tried to load the module
with a Python 2 interpreter, and not with your system's version 3.5? I'm not
sure if this has anything to do with it, but it might be worth a try...


Best,
Johannes


___
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




___
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] Opening pcbnew from kicad: ImportError: No module named pcbnew

[Strontium]

Hi Clemens,

I have been looking at your problem.

And I believe you are either running Arch, or there is possibly 
something wrong with your python install.


PEP-0394 http://legacy.python.org/dev/peps/pep-0394/ says that the 
"python" command should run the python2 interpreter installed on your 
system.  But in your case its running the python3 interpreter.  Which, 
according to PEP-0394 is not recommended but is what Arch linux does.


The recommended way of running python 3 is with the "python3" command.

Kicad scripting requires python2, so if you don’t have python2 
installed, or the "python" command runs the python3 interpreter and not 
python2 then bad things will happen, as you have been experiencing.


Try installing "python2" or making "python" point to it and see if your 
problems are resolved.


To bring kicad inline with that PEP we should not use "python" but 
specifically refer to the interpreter as "python2".


Steven


On 11/01/16 07:31, Clemens Koller wrote:

Hi!


It gets more interesting when I add the path to pcbnew.py:

$ PYTHONPATH=~/SW/lib/python2.7/site-packages ./pcbnew

I believe you wanted to do:

$ export PYTHONPATH=~/SW/lib/python2.7/site-packages ./pcbnew

You don't need the export when you write the variable before the
command like this. But I am unsure if the tilde behaves as you expect
here. One could try to use ${HOME} or actually write /home/username
instead of the tilde.

Python internally resolves the ~/... properly to /home//...
and puts it in the front of the search path:

$ PYTHONPATH=~/SW/lib/python2.7/site-packages python
Python 3.5.1 (default, Dec  7 2015, 12:58:09)
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sys
print(sys.path)

['', '/home/admin/SW/lib/python2.7/site-packages', '/usr/lib/python35.zip', 
'/usr/lib/python3.5', '/usr/lib/python3.5/plat-linux', 
'/usr/lib/python3.5/lib-dynload', '/usr/lib/python3.5/site-packages']



Traceback (most recent call last):
   File "", line 3, in 
   File "/home/admin/SW/lib/python2.7/site-packages/pcbnew.py", line 5055, in 

 class BOARD(BOARD_ITEM):
   File "/home/admin/SW/lib/python2.7/site-packages/pcbnew.py", line 5710, in 
BOARD
 def GetViaByPosition(self, aPosition, aLayer=UNDEFINED_LAYER):
NameError: name 'UNDEFINED_LAYER' is not defined

I am not into the python internals, but it seems something smells down that 
road.
We can just declare installing kicad with python support as non-root currently
as "unsupported". I am fine with that for now.

At least you resolved you module load issue so that's a step in the
right direction.  I don't know how thoroughly the Python module code has
been tested so you may find some issues here and there.

If somebody wants me to debug something in this area, let me know.
Otherwise, I'll stop digging at this place and call it a day.

Regards,

Clemens

___
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] unused file: scripting/python_console_frame.h

[Strontium]

Hi Cirilo,

It can be purged it doesn’t do anything any more.

I wasn't sure what the procedure was to do that.

Steven

On 10/01/16 09:02, Cirilo Bernardo wrote:

In somewhat recent changes to pcbnew/pcbframe.cpp the file
scripting/python_console_frame.h has become orphaned. Can the
file be purged or is it still being kept for some purpose?

- Cirilo



___
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] Opening pcbnew from kicad: ImportError: No module named pcbnew

[Strontium]

I am building with this:
$ cmake ../kicad-source-mirror -DKICAD_SKIP_BOOST=ON 
-DCMAKE_INSTALL_PREFIX=/opt/kicad-build 
-DDEFAULT_INSTALL_PATH=/opt/kicad-build -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON

$ make all
$ make install

That installs pcbnew.py in :
/opt/kicad-build/lib/python2.7/dist-packages/pcbnew.py

which is NOT a system directory.

I do not build and install my test versions with root privilege, as my 
normal user owns /opt/kicad-build, and i don’t experience this problem.  
So i'm not sure what the issue Clemens is getting trying to do the same 
thing.


Steven

On 09/01/16 00:25, Clemens Koller wrote:

Hello, Nick!

On 2016-01-08 17:03, Nick Østergaard wrote:

Distro packagers are supposed to enable scripting, and when they
generate a package it is installed in the proper location for python.
AFIK

Anyway, I did write to keenerd that the scripting is supposed to be
enabled. But it does not seem he is the last packager at the moment.

There were some commits from him for kicad-4.0.1.
So he should be in charge. ;-)

On Arch, I believe the packages are build using makepkg using
fakeroot, so he/we won't run into the issues.

Clemens

___
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] PATCH: To facilitate easier Via Curtain/Filling

[Strontium]

Hi Piers,

On 20/12/15 00:24, Piers Titus van der Torren wrote:

Hi Wayne,
If I can add my thoughts, I think Steven has a fair point that 
tracking zones in the DRC is non trivial, so a 'real' solution in that 
direction is not around the corner, and will never be perfect either.
Yes, I think there will always be corner cases, and this patch cleans up 
those corner cases by not unnecessarily changing nets on tracks/vias 
laid by a designer.


The proposed change has as side effect that unconnected tracks without 
a zone connection also will keep their net, until another net is 
forced upon them. This in my opinion is good, as it makes it easier to 
reconnect erroneously disconnected tracks. So even when tracking zones 
is included in DRC this behaviour is still useful.
I agree, I think the tracks not losing their nets, when they can't be 
reassigned, is far less surprising/disturbing to a designer.  It means 
you can be in the middle of a board edit, do a DRC, and then continue 
where you left off.




I even think the proposed behaviour should be extended to net 
conflicts: when a track is connected to multiple nets, the track 
should keep its original net, so the DRC error will point to the 
location with the problem, and not to some random location in the 
middle of a track.
The patch would need to be extended to detect these "net conflicts", in 
theory it could be enhanced to maintain a list of such conflicts and 
also recover them at the end.  But I would propose adding that as a 
follow up patch if the behaviour I propose is accepted.


It might be useful to list the unconnected tracks in the DRC besides 
the unconnected pads, but that's only slightly related.
I can probably add this.  I haven't looked at what's required to add to 
the DRC message output/checking, but, in principle, a Message about the 
tracks which are unconnected to pads and were recovered could be 
generated during the processing where unassigned nets are recovered.


Perhaps there needs to be a DRC option to flag "Track not connected to 
Pad" and "Via not connected to Pad", as a Warning/Error.  Then, I could 
then flag them as required, during the net recovery part of my patch.  
The nets still wouldn't change their assignment, but DRC would then 
highlight that they are not connected to a Pad.  As it stands, the nets 
will change to unassigned and wont be highlighted unless that change 
causes another DRC error.


It would make the patch more complex, but would possibly make it more 
useful to a designer and help create better boards.


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] PATCH : Enhanced Python Shell - Proposed version

[Strontium]

Yes, I added the base directory of the scripting path to the python 
search path.  scripting/plugins is still in the search path, I didn’t 
take it away.


The reason I did it is because not all scripting is a plugin.  For 
example, the python shell itself, or user scripts, or library modules.  
So those things can be separated from the plug-ins and not pollute that 
directory with python files that are not strictly plugins.


Adding those paths shouldn't break anything, however it certainly does 
need testing.


Steven


On 18/12/15 00:11, Bernhard Stegmaier wrote:

At least the footprint wizards should be checked.
If I remember correctly at least on OSX they could rely on the path 
settings as they were before (this was one I did to make them work 
some while back)...

I can check on the weekend, if nobody is able to do before.


Regards,
Bernhard

On 2015-12-17 16:49, Wayne Stambaugh wrote:

The build issues have been resolved but I noticed that you have changes
the python script path form scripting/plugins to scripting/. This may
break things for users and in package installers.  It' needs to be test
by some of our package devs and verified by our Python users to make
sure your path changes didn't break anything.  Any of you heavy Python
users have any thoughts on this patch since it impacts you the most?

On 12/17/2015 12:10 AM, Strontium wrote:

Hi Wayne,

Thanks for testing this on windows, I really appreciate it a lot.

I moved the offending comments from being inline comments and placed
them into the Docstring.  It has the added benefit of making them more
visible to end users.

See: http://i.imgur.com/Zq1pdyV.jpg
(Apologies on the quality of the screen capture.)

I also ran the pure python code I am submitting for the shell 
through PEP8,

 PEP257 and pyflakes and corrected all problems they highlighted. NOTE:
They are all style issues and not logic faults.

I don't believe there are style guides for python and KiCad yet, but I
figured PEP8 and PEP257 would be a minimum.

I believe I fixed the style problem with the C++ code.

Revised patch attached.
Updated code is also on my github.

Steven

On 17/12/15 05:56, Wayne Stambaugh wrote:

Your patch fails to build using swig 3.0.6 on windows due to the
comments you added to kicadplugins.i.  Here is the output:

C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(101) 



: Error: Unknown SWIG preprocessor directive: The (if this is a 
block of

target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(105) 



: Error: Unknown SWIG preprocessor directive: The (if this is a 
block of

target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(109) 



: Error: Unknown SWIG preprocessor directive: The (if this is a 
block of

target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(113) 



: Error: Unknown SWIG preprocessor directive: And (if this is a 
block of

target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(118) 



: Error: Unknown SWIG preprocessor directive: NOTE (if this is a block
of target language code, delimit it with %{ and %})
pcbnew/CMakeFiles/_pcbnew.dir/build.make:61: recipe for target
'pcbnew/pcbnewPYTHON_wrap.cxx' failed

I tried using the recommended %{ %} to wrap the comments. It built 
fine
but crashed when I ran it.  Your best bet is to get rid of the 
comments
or figure out the proper swig technique for wrapping python 
comments.  I

tried removing the comments and it worked fine.  You also have some
coding policy violations ( missing spaces before and after 
parenthesis )

that need to fixed.


On 12/16/2015 5:58 AM, Strontium wrote:

Hello List,

I believe I have cleaned up my patch and made the enhanced shell do
everything it should.

It has a tabbed interface, with simple text editing capabilities.

Its GUI can be used to introspect the full internal state of 
pcbnew, as

exposed by the python interface.

The editor can be used to code python scripts (with syntax
highlighting), and it has auto-completion built in.  Ie, type word 
press

(dot) and it gives you a list of possibilities which follow. Further,
you can use the editor to load up KiCad files and edit them without
having to use an external editor, if one desires.

It will allow you to save your interactive history, and restore it 
in a

new session.  It has a startup file which is executed when the python
shell first starts, and automatically creates a default if it doesn't
exist.  All of its configuration, history and startup files are 
stored

in the users KiCad configuration directory on each platform.

The default startup file doesn't do anything, but includes a 
commented
out example which will automatically load pcbnew into the shell, 
and get

Re: [Kicad-developers] PATCH : Enhanced Python Shell - Proposed version

[Strontium]

Hi Wayne,

Thanks for testing this on windows, I really appreciate it a lot.

I moved the offending comments from being inline comments and placed 
them into the Docstring.  It has the added benefit of making them more 
visible to end users.


See: http://i.imgur.com/Zq1pdyV.jpg
(Apologies on the quality of the screen capture.)

I also ran the pure python code I am submitting for the shell through PEP8,
 PEP257 and pyflakes and corrected all problems they highlighted. NOTE: 
They are all style issues and not logic faults.


I don't believe there are style guides for python and KiCad yet, but I 
figured PEP8 and PEP257 would be a minimum.


I believe I fixed the style problem with the C++ code.

Revised patch attached.
Updated code is also on my github.

Steven

On 17/12/15 05:56, Wayne Stambaugh wrote:

Your patch fails to build using swig 3.0.6 on windows due to the
comments you added to kicadplugins.i.  Here is the output:

C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(101)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(105)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(109)
: Error: Unknown SWIG preprocessor directive: The (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(113)
: Error: Unknown SWIG preprocessor directive: And (if this is a block of
target language code, delimit it with %{ and %})
C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(118)
: Error: Unknown SWIG preprocessor directive: NOTE (if this is a block
of target language code, delimit it with %{ and %})
pcbnew/CMakeFiles/_pcbnew.dir/build.make:61: recipe for target
'pcbnew/pcbnewPYTHON_wrap.cxx' failed

I tried using the recommended %{ %} to wrap the comments.  It built fine
but crashed when I ran it.  Your best bet is to get rid of the comments
or figure out the proper swig technique for wrapping python comments.  I
tried removing the comments and it worked fine.  You also have some
coding policy violations ( missing spaces before and after parenthesis )
that need to fixed.


On 12/16/2015 5:58 AM, Strontium wrote:

Hello List,

I believe I have cleaned up my patch and made the enhanced shell do
everything it should.

It has a tabbed interface, with simple text editing capabilities.

Its GUI can be used to introspect the full internal state of pcbnew, as
exposed by the python interface.

The editor can be used to code python scripts (with syntax
highlighting), and it has auto-completion built in.  Ie, type word press
(dot) and it gives you a list of possibilities which follow. Further,
you can use the editor to load up KiCad files and edit them without
having to use an external editor, if one desires.

It will allow you to save your interactive history, and restore it in a
new session.  It has a startup file which is executed when the python
shell first starts, and automatically creates a default if it doesn't
exist.  All of its configuration, history and startup files are stored
in the users KiCad configuration directory on each platform.

The default startup file doesn't do anything, but includes a commented
out example which will automatically load pcbnew into the shell, and get
the current board on screen.  Two very common things that need to be
done most times when you start the python shell.

The shell is fully written in python, and uses the foundation of
PyAlamode included with wxpython.  It does not introduce any further
dependencies on KiCad, everything it achieves is already built into
KiCad, and not currently exposed.

It should be possible to extend the shell in future and add features,
without requiring to hack core code inside pcbnew.

The changes to the core of pcbnew, that I did, were to facilitate this,
and I discuss why I did them in earlier posts. They haven't changed in
this patch.  There may be better ways to achieve this and I am open to
suggestions.

I have only tested on Linux, but I do not believe any of the OS specific
code changes that I made should negatively effect Windows or Mac,
nevertheless it needs testing on those platforms and I do not have
access to them.

Screenshots of it in action:

http://i.imgur.com/lTFFddR.png
http://i.imgur.com/qbACtPR.png
http://i.imgur.com/Yny4Lnc.png
http://i.imgur.com/q2AjrPi.png

The code is also available on my github:
https://github.com/stevenj/kicad-source-mirror/tree/enahnced-python-shell

Hopefully this is useful.

Steven


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

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Strontium]

Hi Torsten,

Regarding the side effects, the patch actually eliminates a side effect, 
and introduces no others.  As it stands, if a via/track is changed to 
unassigned, it has an impact on fill zones and then it IS possible for 
those zones to not fill properly and you can end up with disconnected 
islands or thin traces, as they try and avoid the newly "unassigned" 
vias.  There is no warning/error for this, and it doesn't necessarily 
cause a DRC violation.  The board will change to something the designer 
didn't draw, and they have no way of knowing it, other than a visual 
inspection of every fill zone.


It will continue to reassign any nets that it can, that doesn't change, 
and is essential.  All it does is recover the nets that would change to 
unassigned after the reassignment pass, back to what they were before 
the reassignment pass started.


If a designer wanted to find these stubs, all they need to do is hide 
the fill zones and they become easy enough to see.


Basically, with this patch, if you drew it, that's how it stays. If you 
put a GND stub track in the middle of a GND fill plane, it will have no 
effect on the fill zone, the fill will just cover it.


Its because this patch allows the board to remain "as drawn" that it 
becomes easier to Manually fill vias and Manually stitch vias (both 
through hole and micro).  Without it, you either need to use pads as 
vias, and do without microvias and have to place many redundant 
components in the process, or you need to lay redundant tracks to every 
single via to make them retain the net.


As for my python scripts, they are quick and dirty hacks, at best, to 
solve the problems I had.  They are essentially just assistance to 
manually placing the vias.  I don't for a second promote them as a 
working solution to via filling/stitching.  And I would be keen to work 
with others who have an interest in this for a good solution to that 
problem.


Steven



On 16/12/15 20:23, "Torsten Hüter" wrote:

Hi Steven,
my question are the side-effects of this patch, do you have checked 
all possible cases?
For instance if I'm retaining the nets, what happens if I've forgotten 
to erase tracks or vias in my design, would that create copper islands?
How can I discriminate between the intentional and nonintentional 
placement of free vias?

--
I've seen that you have startet your own python script for stitching. 
Please have a look at my code, I'd really like that we don't have too 
many implementations of the same feature (Ben has also announced 
another version). I'm using single pad components for the vias, but 
should be relative easy to adapt.

http://bazaar.launchpad.net/~torstenhtr/kicad/kicad_via_stitching/files/head:/pcbnew/scripting/tools/viastitching/
--
I like the idea of a special via class. I could imagine that the 
pcbnew/class_pad.h could be extended or a new class is derived from 
that. The reason is, that DRC and zone calculations work already well 
for it and a free via is for manufacturing the same as having a 
through hole pad. Just a start/stop layer needs to be added for 
burried/blind vias.

Thanks,
Torsten
*Gesendet:* Mittwoch, 16. Dezember 2015 um 02:49 Uhr
*Von:* Strontium <strnty...@gmail.com>
*An:* kicad-developers@lists.launchpad.net
*Betreff:* Re: [Kicad-developers] PATCH: To facilitate easier Via 
Curtain/Filling

Hi Wayne, Everyone,

This is the process now. If you have a fill zone, and you start to lay
a track within it, KiCad will assign that track/via to the net of the
zone of the layer you are on. AND, as a board Designer, that's exactly
what you would expect. But then, following this design process, you
press the DRC button.

All of a sudden the Track/Via you just laid in the fill zone, and which
KiCad gave you a Net for, loses its net assignment, and becomes
"unconnected". Now the fill area flows around it, avoiding it by the
distance of the fill clearance.

Its a case of Kicad Giving with one hand (the net from the fill) and
then taking away with the other (net reassignment). All my patch does,
is align these so that once the net has been given by KiCad, it wont
needlessly be taken away. It might be reassigned because of a pad
connection, but it wont otherwise be "lost".

This "misalignment" between the DRC Net reassignment and the laying
code, causes multiple problems, on real boards:

1. If you do this, and it doesn't cause a DRC. You may not notice it,
because a "unconnected" track/via is not a DRC error or warning. So the
design intent of your board is thwarted, you may have fill planes now
disconnected at certain points and not enough vias connecting them,
disconnected islands of fill, etc. This board goes to production, and
is actually flawed. All because the designer ran "DRC" check before
sending it AND there is nothing obvious to highlight the change KiCad
made to the board, to the designer. The only way to find them i

[Kicad-developers] PATCH : Enhanced Python Shell - Proposed version

[Strontium]

Hello List,

I believe I have cleaned up my patch and made the enhanced shell do 
everything it should.


It has a tabbed interface, with simple text editing capabilities.

Its GUI can be used to introspect the full internal state of pcbnew, as 
exposed by the python interface.


The editor can be used to code python scripts (with syntax 
highlighting), and it has auto-completion built in.  Ie, type word press 
(dot) and it gives you a list of possibilities which follow. Further, 
you can use the editor to load up KiCad files and edit them without 
having to use an external editor, if one desires.


It will allow you to save your interactive history, and restore it in a 
new session.  It has a startup file which is executed when the python 
shell first starts, and automatically creates a default if it doesn't 
exist.  All of its configuration, history and startup files are stored 
in the users KiCad configuration directory on each platform.


The default startup file doesn't do anything, but includes a commented 
out example which will automatically load pcbnew into the shell, and get 
the current board on screen.  Two very common things that need to be 
done most times when you start the python shell.


The shell is fully written in python, and uses the foundation of 
PyAlamode included with wxpython.  It does not introduce any further 
dependencies on KiCad, everything it achieves is already built into 
KiCad, and not currently exposed.


It should be possible to extend the shell in future and add features, 
without requiring to hack core code inside pcbnew.


The changes to the core of pcbnew, that I did, were to facilitate this, 
and I discuss why I did them in earlier posts. They haven't changed in 
this patch.  There may be better ways to achieve this and I am open to 
suggestions.


I have only tested on Linux, but I do not believe any of the OS specific 
code changes that I made should negatively effect Windows or Mac, 
nevertheless it needs testing on those platforms and I do not have 
access to them.


Screenshots of it in action:

http://i.imgur.com/lTFFddR.png
http://i.imgur.com/qbACtPR.png
http://i.imgur.com/Yny4Lnc.png
http://i.imgur.com/q2AjrPi.png

The code is also available on my github:
https://github.com/stevenj/kicad-source-mirror/tree/enahnced-python-shell

Hopefully this is useful.

Steven
diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index ff99a93..469ddbf 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -678,6 +678,12 @@ if( KICAD_SCRIPTING )
 DESTINATION ${KICAD_DATA}/scripting/plugins
 FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
 )
+
+# scripting python shell
+install( DIRECTORY ${PROJECT_SOURCE_DIR}/pcbnew/scripting/kicad_pyshell/
+DESTINATION ${KICAD_DATA}/scripting/kicad_pyshell
+FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
+)
 endif()
 
 if( KICAD_SCRIPTING_MODULES )
diff --git a/pcbnew/pcbframe.cpp b/pcbnew/pcbframe.cpp
index b19fca1..185fcb9 100644
--- a/pcbnew/pcbframe.cpp
+++ b/pcbnew/pcbframe.cpp
@@ -70,8 +70,6 @@
 #include 
 #include 
 
-#include 
-
 #if defined(KICAD_SCRIPTING) || defined(KICAD_SCRIPTING_WXPYTHON)
 #include 
 #endif
@@ -980,9 +978,6 @@ void PCB_EDIT_FRAME::UpdateTitle()
 }
 
 
-wxSize PYTHON_CONSOLE_FRAME::m_frameSize;   ///< The size of the PYTHON_CONSOLE_FRAME frame, stored during a session
-wxPoint PYTHON_CONSOLE_FRAME::m_framePos;   ///< The position ofPYTHON_CONSOLE_FRAME  the frame, stored during a session
-
 void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 {
 
@@ -990,7 +985,7 @@ void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this, pythonConsoleNameId() );
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 
diff --git a/pcbnew/pcbnew.cpp b/pcbnew/pcbnew.cpp
index 0abbd00..2277c65 100644
--- a/pcbnew/pcbnew.cpp
+++ b/pcbnew/pcbnew.cpp
@@ -241,36 +241,26 @@ static bool scriptingSetup()
 }
 }
 
-// TODO: make this path definable by the user, and set more than one path
-// (and remove the fixed paths from /scripting/kicadplugins.i)
-
-// wizard plugins are stored in kicad/bin/plugins.
-// so add this path to python scripting default search paths
+// wizard plugins are stored in ../share/kicad/scripting/plugins.
+// so add the base scripting path to python scripting default search paths
 // which are ( [KICAD_PATH] is an environment variable to define)
+// [KICAD_PATH]/scripting
 // [KICAD_PATH]/scripting/plugins
 // Add this default search path:
-path_frag = Pgm().GetExecutablePath() + wxT( 

Re: [Kicad-developers] PATCH V2 : Enhanced Python Shell

[Strontium]

Hi,

Yes I do.  But its a bit beyond the scope of this enhancement. However 
with this base enhancement in place, doing that should be easier.


For me, one of the biggest problems with the python scripting in KiCad, 
isn't that its not powerful enough, its that its largely undocumented.  
My hope is with this enhanced shell, introspection of what is exposed by 
kicad to python will be easier, and so it will be easier to experiment 
and add those kinds of features.


Steven.

On 15/12/15 16:52, easyw wrote:

Hi Steven,

do you think it would be useful/possible to add a way to launch a 
macro like in FreeCAD, choosing from a list?

https://bugs.launchpad.net/kicad/+bug/1526064
"Ability to assign shortcuts to run a specific script or adding 
toolbar buttons would be great!"


thank you for your improvements
Maurice

On 15/12/2015 09.03, Strontium wrote:

I attach an enhanced patch to the python shell.

This one is a bigger change than the previous patch.  But it moves the
code to the point where the whole shell is contained as an external
python file, which makes it a lot easier to develop and enhance.

Explanation of the changes:
- I created a "pcbnew/scripting/kicad_pyshell" directory to contain the
shell python code.  So i added the required installer directives.

- I don't need or use "scripting/python_console_frame.h" so all
reference to its removed from the code, but the file still exists in the
source tree.

- I changed the Bundled search path to be "scripting" not
"scripting/plugins". "plugins" is only one type of possible scripting
and also common to all 3 platforms, so its handled lower down. This
means its possible to have other types of "scripting". The directory it
produces is therefore just the scripting "bundled" search path, and
doesn't need to be over-ridden by the end user, as far as i can tell. So
I removed the comments about that being desirable.

- I removed the TODO comments, the way the code works now, there are a
bunch of default search paths added, some referencing the kicad install
path, some from the KICAD_PATH environment variable and some from the
users root directory and users kicad config directory.  Its also easily
possible for a user to add their own include paths, all they need to do
is add python code to a module in the search path to do it, and the
python interpreter will load that and execute it in the process of
initialising the plugins.  Note, these search paths are only possible
search paths, they dont get added if they dont exist.

- I modified LoadPlugins in kicadplugins.i to properly add all the
scripting paths, including plugin paths.

The full list of possible default search paths is now:
+# The Scripts bundled with Kicad:
+#   
+#   /plugins
+#
+# The Scripts relative to the Kicad environment variable search 
path:

+#   /scripting
+#   /scripting/plugins
+#
+# The Scripts relative to the Kicad Users configuration:
+#   /scripting
+#   /scripting/plugins
+#
+# And on Linux, extra paths relative to the home directory:
+#   ~/.kicad_plugins
+#   ~/.kicad/scripting
+#   ~/.kicad/scripting/plugins

And i include that as a comment in the code.

- I changed some names from PluginsPath to ScriptingPath to
make the parameters reflect their current use.

- I reduced the python code embedded within CreatePythonShellWindow to
the bare minimum, which eases maintenance, as further changes or
enhancements to the python shell are all in pure python.  I also renamed
it from pycrust_panel to pcbnew_shell to better reflect what it is.  Its
possible in future the shell wont be based on pycrust, there is no need
to do it, except that currently its already a dependency of Kicad and
easy enough to leverage.

It also seemed to make sense to refer it to pcbnew, where it is embedded
because i could imagine a time when eeschema has python scripting and
its own shell.  And, at that time both programs could share a lot of the
same python shell code.

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] PATCH V2 : Enhanced Python Shell

[Strontium]

I attach an enhanced patch to the python shell.

This one is a bigger change than the previous patch.  But it moves the 
code to the point where the whole shell is contained as an external 
python file, which makes it a lot easier to develop and enhance.


Explanation of the changes:
- I created a "pcbnew/scripting/kicad_pyshell" directory to contain the 
shell python code.  So i added the required installer directives.


- I don't need or use "scripting/python_console_frame.h" so all 
reference to its removed from the code, but the file still exists in the 
source tree.


- I changed the Bundled search path to be "scripting" not 
"scripting/plugins". "plugins" is only one type of possible scripting 
and also common to all 3 platforms, so its handled lower down.  This 
means its possible to have other types of "scripting". The directory it 
produces is therefore just the scripting "bundled" search path, and 
doesn't need to be over-ridden by the end user, as far as i can tell.  
So I removed the comments about that being desirable.


- I removed the TODO comments, the way the code works now, there are a 
bunch of default search paths added, some referencing the kicad install 
path, some from the KICAD_PATH environment variable and some from the 
users root directory and users kicad config directory.  Its also easily 
possible for a user to add their own include paths, all they need to do 
is add python code to a module in the search path to do it, and the 
python interpreter will load that and execute it in the process of 
initialising the plugins.  Note, these search paths are only possible 
search paths, they dont get added if they dont exist.


- I modified LoadPlugins in kicadplugins.i to properly add all the 
scripting paths, including plugin paths.


The full list of possible default search paths is now:
+# The Scripts bundled with Kicad:
+#   
+#   /plugins
+#
+# The Scripts relative to the Kicad environment variable search path:
+#   /scripting
+#   /scripting/plugins
+#
+# The Scripts relative to the Kicad Users configuration:
+#   /scripting
+#   /scripting/plugins
+#
+# And on Linux, extra paths relative to the home directory:
+#   ~/.kicad_plugins
+#   ~/.kicad/scripting
+#   ~/.kicad/scripting/plugins

And i include that as a comment in the code.

- I changed some names from PluginsPath to ScriptingPath to 
make the parameters reflect their current use.


- I reduced the python code embedded within CreatePythonShellWindow to 
the bare minimum, which eases maintenance, as further changes or 
enhancements to the python shell are all in pure python.  I also renamed 
it from pycrust_panel to pcbnew_shell to better reflect what it is.  Its 
possible in future the shell wont be based on pycrust, there is no need 
to do it, except that currently its already a dependency of Kicad and 
easy enough to leverage.


It also seemed to make sense to refer it to pcbnew, where it is embedded 
because i could imagine a time when eeschema has python scripting and 
its own shell.  And, at that time both programs could share a lot of the 
same python shell code.


Steven
=== modified file 'pcbnew/CMakeLists.txt'
--- pcbnew/CMakeLists.txt	2015-12-10 19:20:35 +
+++ pcbnew/CMakeLists.txt	2015-12-15 07:31:41 +
@@ -678,6 +678,12 @@
 DESTINATION ${KICAD_DATA}/scripting/plugins
 FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
 )
+
+# scripting python shell
+install( DIRECTORY ${PROJECT_SOURCE_DIR}/pcbnew/scripting/kicad_pyshell/
+DESTINATION ${KICAD_DATA}/scripting/kicad_pyshell
+FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
+)
 endif()
 
 if( KICAD_SCRIPTING_MODULES )

=== modified file 'pcbnew/pcbframe.cpp'
--- pcbnew/pcbframe.cpp	2015-11-29 06:56:27 +
+++ pcbnew/pcbframe.cpp	2015-12-15 07:30:47 +
@@ -70,8 +70,6 @@
 #include 
 #include 
 
-#include 
-
 #if defined(KICAD_SCRIPTING) || defined(KICAD_SCRIPTING_WXPYTHON)
 #include 
 #endif
@@ -980,9 +978,6 @@
 }
 
 
-wxSize PYTHON_CONSOLE_FRAME::m_frameSize;   ///< The size of the PYTHON_CONSOLE_FRAME frame, stored during a session
-wxPoint PYTHON_CONSOLE_FRAME::m_framePos;   ///< The position ofPYTHON_CONSOLE_FRAME  the frame, stored during a session
-
 void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 {
 
@@ -990,7 +985,7 @@
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this, pythonConsoleNameId() );
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 

=== modified file 'pcbnew/pcbnew.cpp'
--- pcbnew/pcbnew.cpp	2015-11-04 08:48:34 +
+++ pcbnew/pcbnew.cpp	2015-12-15 07:32:00 +
@@ -241,36 +241,26 @@
 }
 }
 

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Strontium]

Hi Wayne, Everyone,

This is the process now.  If you have a fill zone, and you start to lay 
a track within it, KiCad will assign that track/via to the net of the 
zone of the layer you are on.  AND, as a board Designer, that's exactly 
what you would expect. But then, following this design process, you 
press the DRC button.


All of a sudden the Track/Via you just laid in the fill zone, and which 
KiCad gave you a Net for, loses its net assignment, and becomes 
"unconnected".  Now the fill area flows around it, avoiding it by the 
distance of the fill clearance.


Its a case of Kicad Giving with one hand (the net from the fill) and 
then taking away with the other (net reassignment).  All my patch does, 
is align these so that once the net has been given by KiCad, it wont 
needlessly be taken away.  It might be reassigned because of a pad 
connection, but it wont otherwise be "lost".


This "misalignment" between the DRC Net reassignment and the laying 
code, causes multiple problems, on real boards:


1. If you do this, and it doesn't cause a DRC.  You may not notice it, 
because a "unconnected" track/via is not a DRC error or warning.  So the 
design intent of your board is thwarted, you may have fill planes now 
disconnected at certain points and not enough vias connecting them, 
disconnected islands of fill, etc.  This board goes to production, and 
is actually flawed. All because the designer ran "DRC" check before 
sending it AND there is nothing obvious to highlight the change KiCad 
made to the board, to the designer.  The only way to find them is a 
detailed visual inspection, after every DRC Check.


2. To work around point 1, you need need to criss cross your board with 
interconnecting tracks from pads with that net to the vias, so they keep 
their assignment.  This causes a problem that if you now edit, you have 
all of these tracks, which you are only using to keep nets assigned to 
your vias, making it very difficult to edit/relay, etc.  In many cases 
the nearest pad may be on the other side of the board, requiring you to 
manually lay a track to it.


OR Place a single pad component which simulates a VIA, but then you cant 
use microvias, and you need to now manage the "extra" components.


3. Changing vias/tracks to "unassigned" may introduce "DRC" errors on 
the board that weren't there before the DRC pass.  So, in effect, KiCad 
is actually generating these DRC errors with the DRC check Pass, they 
didn’t exist BEFORE the DRC check, but do after. Which, as a board 
designer, is surprising and off-putting.


Basically, and at its core, this patch makes the net reassignment code 
compatible with the code that lets you place a track/via on a fill plane 
and pick up its net.  Without it, its like KiCad telling you what you 
are doing while editing is OK.  But then changing its mind later.


And while my patch allows me to much more easily, manually, lay GND vias 
for filling, etc, its utility is not limited to "Via Curtains" or "Via 
Fills".  For example, you may simply want to put a few extra vias 
between two VCC planes to share the current load.  This patch makes that 
easy and consistent.


I can certainly understand the desire not to implement "quick fixes" 
that increase "cruftiness", I wouldn't want that either. And while this 
patch is small, I don't think this patch increases cruftiness but 
actually reduces cruftiness and makes the board design DRC process less 
surprising to a board designer and more consistent with the way the 
layout tools work.


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] PATCH: To facilitate easier Via Curtain/Filling

[Strontium]

Hi Thomas,

I considered this, but tracking zones is non trivial.

For example, imagine the stackup:

GND
VCC
GND
VCC

A Through Via, from top to bottom could be connected validly connected 
to either GND or VCC.


Once the net is removed from the via by the reassignment pass, there is
no longer any information left to tell kicad which pair of zones was 
connected by the via.


The approach I suggest will fix this problem, because it just wont 
change the net for those vias.  It wont consider if there is a zone or 
not, it just says "hey, you gave it the GND net, so i will leave it as GND."



On 14/12/15 21:21, Tomasz Wlostowski wrote:

On 12.12.2015 02:41, Strontium wrote:

This change should not break or modify any current behaviour, EXCEPT to
retain the nets of tracks/vias which Kicad is otherwise incapable of
determining automatically.

Hi Steven,

Thanks for the patch, it also (partially) fixes the via stitching issue
many people have been complaining about. The origin of the problem is
that the net propagation code does not take zones into account - so a
via that is not connected to any pad with a chain of tracks is treated
as disconnected.

Adding zone support in the net calculation code should AFAIK fix this
for good, but it may also require enhancing the DRC (so that it will
report every object with no pad connection) and the 'clean tracks'
tool code.

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

[Kicad-developers] PATCH: Enhanced Python Shell - V1

[Strontium]

Attached is a patch for the enhanced python shell.

This is what it looks like for me: http://i.imgur.com/je6yv8g.png

The assertions I was getting occur in a debug build and appear to be 
normal behaviour of wxpython, and not actual errors.


See: http://wxpython.org/Phoenix/docs/html/Notebook.html

Specifically : "On platforms other than Windows, or if the application 
is not using Windows themes, GetThemeBackgroundColour 
 
will return an uninitialised colour object"


That is the cause of the exceptions, and according to the docs its what 
it should do.  If someone knows more about this particular aspect of 
wxpython/wxwidgets I would be happy to make them NOT happen in a debug 
build.


I have only tested it on Linux, it needs testing on Windows and Mac, 
although its all standard wxpython stuff, so I expect it should "just 
work" if wxpython works.  That's the hope anyway.


Its just the vanilla implementation of the PyAlacarte shell from 
wxpython at the moment, there are a few enhancements/changes that can be 
made to make it nicer.  I am looking at those now, including the error 
you can see on the screenshot, which appears to not cause any issues, 
but I would like to fix in any event.


Steven
=== modified file 'pcbnew/pcbframe.cpp'
--- pcbnew/pcbframe.cpp	2015-11-29 06:56:27 +
+++ pcbnew/pcbframe.cpp	2015-12-13 14:46:14 +
@@ -70,8 +70,6 @@
 #include 
 #include 
 
-#include 
-
 #if defined(KICAD_SCRIPTING) || defined(KICAD_SCRIPTING_WXPYTHON)
 #include 
 #endif
@@ -980,9 +978,6 @@
 }
 
 
-wxSize PYTHON_CONSOLE_FRAME::m_frameSize;   ///< The size of the PYTHON_CONSOLE_FRAME frame, stored during a session
-wxPoint PYTHON_CONSOLE_FRAME::m_framePos;   ///< The position ofPYTHON_CONSOLE_FRAME  the frame, stored during a session
-
 void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 {
 
@@ -990,7 +985,7 @@
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this, pythonConsoleNameId() );
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 

=== modified file 'scripting/python_scripting.cpp'
--- scripting/python_scripting.cpp	2015-08-24 18:32:56 +
+++ scripting/python_scripting.cpp	2015-12-13 14:45:48 +
@@ -227,16 +227,17 @@
 }
 
 
-wxWindow* CreatePythonShellWindow( wxWindow* parent )
+wxWindow* CreatePythonShellWindow( wxWindow* parent, const wxString& aFramenameId )
 {
 const char* pycrust_panel =
 "import wx\n"
-"from wx.py import shell, version\n"
+"from wx.py import editor, version\n"
 "\n"
 "intro = \"PyCrust %s - KiCAD Python Shell\" % version.VERSION\n"
 "\n"
 "def makeWindow(parent):\n"
-"pycrust = shell.Shell(parent, -1, introText=intro)\n"
+"pycrust = editor.EditorNotebookFrame(parent, id=-1, title=intro)\n"
+"pycrust.Show()\n"
 "return pycrust\n"
 "\n";
 
@@ -297,6 +298,8 @@
 
 wxASSERT_MSG( success, _T( "Returned object was not a wxWindow!" ) );
 Py_DECREF( result );
+
+window->SetName(aFramenameId);
 }
 
 // Release the python objects we still have

=== modified file 'scripting/python_scripting.h'
--- scripting/python_scripting.h	2013-07-19 18:27:22 +
+++ scripting/python_scripting.h	2015-12-13 14:37:04 +
@@ -31,7 +31,7 @@
 #ifdef KICAD_SCRIPTING_WXPYTHON
 
 voidRedirectStdio();
-wxWindow*   CreatePythonShellWindow( wxWindow* parent );
+wxWindow*   CreatePythonShellWindow( wxWindow* parent, const wxString& aFramenameId );
 
 class PyLOCK
 {

___
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] Enhanced Python Shell

[Strontium]

On 13/12/15 01:20, Wayne Stambaugh wrote:

I just tried this.  Nice!  This is definitely nicer than the Python
shell we are using.  I'm with Nick, where's the patch?

On 12/12/2015 10:00 AM
Attached is A ROUGH PATCH, but its not correct yet.  I am posting it for 
comments, and maybe someone can help explain my problem??


I am getting unexplained assertions in the kicad menu.
With this patch, the first time the "Tools" menu is accessed no problem.
If the Python Console is opened, then the very next access to the tools 
menu gives:
../src/gtk/menu.cpp(745): assert "Assert failure" failed in Check(): 
can't check this item


I am also getting assertions when i expand some items in the "Namespace":

../src/gtk/colour.cpp(218): assert "IsOk()" failed in Alpha(): invalid 
colour

../src/gtk/colour.cpp(207): assert "IsOk()" failed in Blue(): invalid colour
../src/gtk/colour.cpp(196): assert "IsOk()" failed in Green(): invalid 
colour
../src/gtk/colour.cpp(233): assert "IsOk()" failed in GetPixel(): 
invalid colour

../src/gtk/colour.cpp(185): assert "IsOk()" failed in Red(): invalid colour
../src/gtk/colour.cpp(185): assert "IsOk()" failed in Red(): invalid colour
../src/gtk/colour.cpp(196): assert "IsOk()" failed in Green(): invalid 
colour

../src/gtk/colour.cpp(207): assert "IsOk()" failed in Blue(): invalid colour

I don't know whats causing those.  Also, i will probably move the 
setting of the frame name inside CreatePythonShellWindow.


Doing it this way removes the need for the PYTHON_CONSOLE_FRAME and 
assuming I can get it to work without causing assertions, then that 
whole file could be removed.


IF I can get this to work, I would like to add features such as:

Startup scripts which execute the first time the window is opened.
Saving and restoring of the windows settings.
Saving and restoring of the history.
Making the About Dialog more descriptive/meainingful.

I think that:
Settings/History would be stored in the users kicad config directory.
Startup scripts would also be there.

I would also like to add the users kicad config directory and the 
current project path to the search path, so that user scripts could be 
stored with their project or with their kicad settings.


Steven.
=== modified file 'pcbnew/pcbframe.cpp'
--- pcbnew/pcbframe.cpp	2015-11-29 06:56:27 +
+++ pcbnew/pcbframe.cpp	2015-12-13 07:17:14 +
@@ -990,7 +990,11 @@
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+{
+//  pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this );
+pythonPanelFrame->SetName(pythonConsoleNameId());
+}
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 

=== modified file 'scripting/python_scripting.cpp'
--- scripting/python_scripting.cpp	2015-08-24 18:32:56 +
+++ scripting/python_scripting.cpp	2015-12-13 07:19:47 +
@@ -231,16 +231,16 @@
 {
 const char* pycrust_panel =
 "import wx\n"
-"from wx.py import shell, version\n"
+"from wx.py import editor, version\n"
 "\n"
 "intro = \"PyCrust %s - KiCAD Python Shell\" % version.VERSION\n"
 "\n"
 "def makeWindow(parent):\n"
-"pycrust = shell.Shell(parent, -1, introText=intro)\n"
+"pycrust = editor.EditorNotebookFrame(parent, id=-1, title=intro)\n"
+"pycrust.Show()\n"
 "return pycrust\n"
 "\n";
 
-
 wxWindow*   window = NULL;
 PyObject*   result;
 

___
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] Enhanced Python Shell

[Strontium]

Hello Kicad developers,

I have been a very long time follower of kicad and I think the work done 
to it over the years is simply amazing.

I would love to contribute where I can.

I have had need to play with the python scripting of Kicad.  Kicad uses 
wxpython.
Wxpython includes within it, a much better shell than the one currently 
being used.


If inside the current python shell, one does this:

>>> import wx; f = wx.py.editor.EditorNotebookFrame(title="KiCad PCB"); 
f.Show()


You will see what I am talking about.

It provides a nice way to introspect python state when writing scripts, 
and also includes a simple tabbed text editor.


Its possible this shell could be tweaked to be even better, but even as 
it stands its a LOT better than the default shell.


I am working on a proposed patch to sub the existing shell with this 
one, for further discussion.  I will post it once I test it.


Strontium (Steven J)




___
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] PATCH: To facilitate easier Via Curtain/Filling

[Strontium]

I am working on a couple of RF designs, proper layout requires the use 
of "Via Curtains/Via Filling", Further they are HDI boards and I am 
using both through-hole and micro vias.


I am aware of the "Pro Tip" which suggests simulating a via with a 
component with a single pad.  The "Pro-Tip" doesn't work for me, because 
a pad simulates  a through hole via only, and I also need to fill with 
micro-vias.


I am attempting to write python scripts to automate the Via 
Curtain/Filling, which is otherwise tedious and difficult to edit.


However, there is existing behaviour of Kicad which will cause it to 
delete the net associated with a Track/Via unless that Track/Via is 
connected to a pad, after a DRC.


This behaviour stems from the function :

void PCB_BASE_FRAME::RecalculateAllTracksNetcode()

in pcbnew/connect.cpp

Basically it traces all tracks/vias from the pads and reassigns their 
nets based on the pads they are connected to.  To do that, it first 
removes the already associated nets, and uses the "unassigned net" as a 
flag to tell the function what needs to be traced.


This is fine, and works well.  But in the circumstance where the 
Via/Track is not actually connected to a pad it has the side-effect, 
once complete, of leaving those vias/tracks in the "unconnected" state.


The reality is, these vias/tracks are not "unconnected" the designer has 
actually connected them to the fill planes, or otherwise assigned them a 
net for a reason, which this function does not account for, and doing so 
would be non-trivial and prone to error.


(For example, a Board with a GND/VCC/GND/VCC four layer fill could use a 
through via to connect the GND planes, OR the VCC planes and there is no 
way to automatically determine which.)


Instead, I propose the following patch, or something like it, which 
simply "backs up" the nets of the tracks/vias and after the Nets are 
recalculated, for those which were not changed, restores their net to 
the one it was on entry.


This means if the designer places a GND Via not connected to a pad, it 
will always be a GND Via and will never "lose" its net on DRC. It will 
then properly connect the Fill Planes or whatever other purpose the 
designer had in mind, and wont change.


This change should not break or modify any current behaviour, EXCEPT to 
retain the nets of tracks/vias which Kicad is otherwise incapable of 
determining automatically.


Strontium (Steven J)
=== modified file 'pcbnew/connect.cpp'
--- pcbnew/connect.cpp	2015-06-26 13:41:56 +
+++ pcbnew/connect.cpp	2015-12-11 06:36:01 +
@@ -855,14 +855,32 @@
  * segments.
  * Pads netcodes are assumed to be up to date.
  */
+
+// Simple structure to hold backup data of Tracks/Vias beign processed.
+struct NETBACKUP {
+  TRACK* t;
+  int m_NetCode;
+
+  NETBACKUP (TRACK* init_t, int init_m_NetCode)
+{
+t = init_t;
+m_NetCode = init_m_NetCode;
+}
+};
+
 void PCB_BASE_FRAME::RecalculateAllTracksNetcode()
 {
+std::vector< NETBACKUP > tbak;  // NetCode Backup
+
 // Build the net info list
 GetBoard()->BuildListOfNets();
 
 // Reset variables and flags used in computation
 for( TRACK* t = m_Pcb->m_Track;  t;  t = t->Next() )
 {
+// BACKUP NetCode of Track/Via
+tbak.push_back(NETBACKUP(t, t->GetNetCode()));
+
 t->m_TracksConnected.clear();
 t->m_PadsConnected.clear();
 t->start = NULL;
@@ -942,6 +960,16 @@
 }
 }
 
+// Scan the backup netcodes, and reset any unconnected nets back to their original value.
+for( unsigned i = 0; i != tbak.size(); i++) {
+// Check if the Track/Via remains Unconnected
+if (tbak[i].t->GetNetCode() == NETINFO_LIST::UNCONNECTED)
+{
+// It is, so restore it to the last known NetCode.
+tbak[i].t->SetNetCode(tbak[i].m_NetCode);
+}
+}
+
 // Sort the track list by net codes:
 RebuildTrackChain( m_Pcb );
 }

___
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