Re: [Kicad-developers] Build flags/options for the nightly builds.

[Andy Peters]

> On Mar 16, 2022, at 6:34 AM, Adam Wolf  wrote:
> 
> Sorry, I haven't been following the news about this.  Are there any docs or 
> instructions for the integration, at least how it's supposed to work?
> 
> I can help your engineers with setting up a Mac dev environment, if that's 
> helpful.
> 
> (I recently picked up a Space Mouse Pro for some 3D modeling work, and would 
> love to see it working well on kicad on macos :) )


I realize I’m not adding to the discussion with this, but as soon as Kicad 
supports the Space Mouse on macOS, I’m getting one.

-a




> 
> On Wed, Mar 16, 2022, 12:37 AM Markus Bonk  > wrote:
> HI Adam,
> 
>  
> 
> Thanks, the SpaceMouse integration is indeed compiled in. Unfortunately, 
> there is an issue with the driver on the mac so that it doesn’t do anything 
> at the moment
> 
>  
> 
> Markus
> 
>  
> 
> From: Adam Wolf  > 
> Sent: Wednesday, March 9, 2022 7:05 PM
> To: Markus Bonk  >
> Cc: KiCad Developers  >
> Subject: Re: [Kicad-developers] Build flags/options for the nightly builds.
> 
>  
> 
> I double checked that this build was built with KICAD_USE_3DCONNEXION=ON: 
> https://downloads.kicad.org/kicad/macos/explore/6.0-testing/download/kicad-unified-20220225-193735-714c65275c.3dconnexion.dmg
>  
> .
>   I also uploaded the build log.  The build log includes building Wx and a 
> lot of dependencies, but it shows
> 
> -- Including 3Dconnexion SpaceMouse navigation support in pcbcommon
> and 
> 
> -- Including 3Dconnexion SpaceMouse navigation support in 3d-viewer
> 
> https://downloads.kicad.org/kicad/macos/explore/6.0-testing/download/buildlogs.20220225-193735-714c65275c.txt
>  
> 
>  
> 
> I do not know if it is expected to work 100% yet or if there are settings I 
> would need to change, but I opened it up on my Mac and tried to navigate in 
> the 3D viewer with my SpaceMouse Pro, but the model didn't seem to respond.
> 
>  
> 
> Thanks for your patience. :) I should be more available--right after the last 
> release, I had a client deliverable that significantly changed scope, but 
> that's covered now.
> 
>  
> 
> This build is about two weeks old, so I poked the server to build another one 
> off the current master.
> 
>  
> 
> Adam Wolf
> 
>  
> 
> On Mon, Feb 28, 2022 at 2:02 AM Markus Bonk  > wrote:
> 
> Hi Adam,
> 
>  
> 
> Our macOS team have tried the following builds:
> 
> Testing:
> 
> kicad-6.0-testing-20220221-081032-b4ac59d9d3
> 
> kicad-6.0-testing-20220222-081156-5cc2bef954
> 
>  
> 
> Nightly:
> 
> kicad-unified-20220224-000836-d2069e1548
> 
> And two other builds (testing & nightly).
> 
>  
> 
> None of the builds respond to 3D Mouse input.
> 
>  
> 
>  
> 
> Also, they say their check for symbols/ library dependencies fails or is 
> invalid with KiCad. The binaries lack any symbol or dependency from the 
> navlib.
> 
>  
> 
> Can you please let us know what we are doing wrong or what the issue is.
> 
>  
> 
> Thanks
> 
> Markus
> 
>  
> 
> From: Adam Wolf  > 
> Sent: Tuesday, February 22, 2022 5:46 PM
> To: Markus Bonk  >
> Cc: KiCad Developers  >
> Subject: Re: [Kicad-developers] Build flags/options for the nightly builds.
> 
>  
> 
> Hi Markus,
> 
>  
> 
> Could you try this build? 
> https://downloads.kicad.org/kicad/macos/explore/6.0-testing/download/kicad-6.0-testing-20220221-081032-b4ac59d9d3.dmg
>  
> 
>  It's a few days old, actually, but I just got it uploaded today. It *should* 
> have the flag set--could you verify?  I'll start an updated build, too.
> 
>  
> 
> Thanks for your patience :)
> 
>  
> 
> Adam
> 
>  
> 
> On Tue, Feb 22, 2022 at 12:01 AM Markus Bonk  > wrote:
> 
> Hi Adam,
> 
>  
> 
> Hope you have been able to progress with the 6.02 issues. Will you be able to 
> do this this week?
> 
>  
> 
> Markus
> 
>  
> 
> From: Adam Wolf  > 
> Sent: Monday, February 14, 2022 9:06 AM
> To: Markus Bonk  >
> Cc: KiCad Developers  >
> Subject: Re: [Kicad-developers] Build flags/options for the nightly builds.
> 
>  
> 
> Hi Markus,
> 
>  
> 
> I will be sending a link out shortly, hopefully tomorrow.  Last week I ended 
> up hitting some snags with the 6.0.2 release.
> 
>  
> 
> Adam
> 
>  
> 
> On Thu, Feb 10, 2022 at 11:52 PM 

Re: [Kicad-developers] Can't show 3D models (was: build failure)

[Andy Peters]

> On Mar 6, 2021, at 3:30 PM, Jonatan Liljedahl  wrote:
> 
> Hi,
> 
> I tried the nightly 20210306, and actually no, it shows no models
> either! See attached screenshots.
> As you see, I have KICAD6_3DMODEL_DIR =
> /Users/lijon/Coding/kicad-packages3D, which is where I've cloned the
> kicad-packages3D gitlab repo. The model is there:
> 
> % ls -l /Users/lijon/Coding/kicad-packages3D/LED_THT.3dshapes/LED_D3.0mm.wrl
> -rw-r--r--  1 lijon  staff  36129 Aug 16  2020
> /Users/lijon/Coding/kicad-packages3D/LED_THT.3dshapes/LED_D3.0mm.wrl
> 
> On Sat, Mar 6, 2021 at 6:56 PM Adam Wolf  > wrote:
>> 
>> Do the release versions work for you?
>> 
>> Assuming it does, this is almost certainly an issue with dyld and 
>> fixup_bundle.
>> 
>> Let me know if the release/nighties work on your system, and I can walk 
>> folks through how to solve it.

I have the same problem on my two Macs, both running nightly from a couple of 
days ago on Big Sur — no 3D models appearing anywhere, and it looks like the 
old KISYS3DMOD environment variable is being ignored. It doesn’t show up in the 
Path Substitutions in the Manage Footprint Libraries dialog.

Is there a reason why the environment variable that points to the 3D models was 
changed to KICAD6_3D_MODEL_DIR? This breaks existing footprint/3D model links, 
as that variable is embedded in footprints. And the footprint format hasn’t 
changed.

Application: KiCad

Version: (5.99.0-9619-g3f1e407a42), release build

Libraries:
wxWidgets 3.0.4
libcurl/7.64.1 SecureTransport (LibreSSL/2.8.3) zlib/1.2.11 
nghttp2/1.41.0

Platform: macOS Version 10.16 (Build 20D80), 64 bit, Little endian, wxMac

Build Info:
Date: Mar  5 2021 04:30:43
wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
Boost: 1.75.0
OCC: 7.5.0
Curl: 7.54.0
ngspice: 31
Compiler: Clang 10.0.1 with C++ ABI 1002

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
KICAD_USE_OCC=ON
KICAD_SPICE=ON


-a

___
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] 5.99 footprint editor: weird status thing in Pad Properties

[Andy Peters]

I’m using 5.99 and making a footprint for a connector. In the pad properties I 
see this weird status line thing in the lower left:

“Footprint R1 (300K), back side (mirrored), rotated 180º”

See screenshot, look for red oval.

What the heck?

Application: KiCad Footprint Editor

Version: (5.99.0-9281-g2d7e7c515a), release build

Libraries:
wxWidgets 3.0.4
libcurl/7.64.1 SecureTransport (LibreSSL/2.8.3) zlib/1.2.11 
nghttp2/1.41.0

Platform: macOS Version 10.16 (Build 20D74), 64 bit, Little endian, wxMac

Build Info:
Date: Feb 22 2021 04:31:03
wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
Boost: 1.75.0
OCC: 7.5.0
Curl: 7.54.0
ngspice: 31
Compiler: Clang 10.0.1 with C++ ABI 1002

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
KICAD_USE_OCC=ON
KICAD_SPICE=ON


-a

___
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] 5.99 Footprint Editor: Can't change text item layer

[Andy Peters]

I’m not sure if this was reported yet but with 5.99 on macOS Big Sur from 
yesterday the footprint editor won’t let me change the layer of a text item. It 
doesn’t matter whether it’s a newly-created footprint or an existing footprint. 

Just open the footprint, open the properties -> General, click on one of the 
entries in the Layer column. The drop-down pops up as expected, and you can 
select a different layer, but that change isn’t accepted once the drop-down is 
closed.

It’s Issue 7671 in Ye Olde Bugge Tracker 
https://gitlab.com/kicad/code/kicad/-/issues/7671

Application: KiCad Footprint Editor

Version: (5.99.0-9281-g2d7e7c515a), release build

Libraries:
wxWidgets 3.0.4
libcurl/7.64.1 SecureTransport (LibreSSL/2.8.3) zlib/1.2.11 
nghttp2/1.41.0

Platform: macOS Version 10.16 (Build 20D74), 64 bit, Little endian, wxMac

Build Info:
Date: Feb 22 2021 04:31:03
wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
Boost: 1.75.0
OCC: 7.5.0
Curl: 7.54.0
ngspice: 31
Compiler: Clang 10.0.1 with C++ ABI 1002

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
KICAD_USE_OCC=ON
KICAD_SPICE=ON


Thanks,

-a

(Oh, by the way, the changes for v6 are mighty impressive. Thanks for all of 
the hard work!)
___
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] 3d-viewer: via diameter calculation off?

[Andy Peters]

> On Jul 8, 2020, at 2:47 PM, Joshua Redstone  wrote:
> 
> Hi,
> I'm a bit new to pcbs and Kicad, but I thought that the effective diameter of 
> a through-hole is the drill diameter minus copper plating thickness (since 
> plating is done after drilling).
> In the 3d-viewer code, it looks like it's increasing the drill diameter to 
> account for the plating so the plated hole is the drill diameter rather than 
> the unplated hole, which seems odd.
> 
> I was thinking of doing a diff to fix that, but wanted to check if I'm 
> reading the code correctly.
> Specifically, in 3d-viewer/3d_canvas/create_layer_items.cpp
> the calculation of a hole's inner diameter is (hole_inner_radius) rather than 
> (hole_inner_radius - [plating_]thickness).  And there's a corresponding 
> offset in the calc of the outer diameter.
> 
> An example: 
> https://gitlab.com/kicad/code/kicad/-/blob/master/3d-viewer/3d_canvas/create_layer_items.cpp#L306
>  
> 
> 
> I played around with rendering some test circuits and confirmed that the 
> rendering seems to be producing holes that are too big.
> 
> Am I reading this right?

Most board houses these days specify hole sizes as “finished hole size,” that 
is, with plating.

That’s because they rarely use drill bits in favor of water jet or whatever.

And it’s a lot easier to specify finished hole size rather than the 
manufacturer and the customer guessing.

-a

___
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] "Footprint Mode" in pcbnew

[Andy Peters]

Hola,

On macOS Catalina, and Kicad 5.1.6.

The pcbnew documentation (section 3.14) refers to something called “footprint 
mode” which allows, among other things, a sort of auto-place feature. Its icon 
is a six-pin DIP IC. with the direction/movement cross on it.

It is supposed to be on the top toolbar but isn’t.

I mailed in an issue to gitlab about this.

-a
___
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] Auto-generated backup files: are they useful?

[Andy Peters]

> On Jun 29, 2020, at 12:23 PM, Jon Evans  wrote:
> 
> Currently, KiCad automatically creates backups of schematic and PCB
> files when you save a file.
> 
[snip]
> 
> In other words, I don't think this feature actually gives enough value
> to make it worth the clutter in the project folder and/or the
> development effort to make it work well with less clutter.
> 
> So, I'd like to hear from others on this: anyone disagree?

One user’s perspective (mine):

Keeping designs in a proper source-code control system eliminates the need for 
such backups.

What, you say, some people don’t use SCC? Oy.

-a
___
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] Exclude symbol from board feature

[Andy Peters]

> On Jun 10, 2020, at 10:30 AM, Wayne Stambaugh  wrote:
> 
> I just pushed a new feature to exclude schematic symbols from being
> pushed to the board on update into the master branch.  I did a write up
> about it on the user forum[1] if you are interested.

HRAY!

-a

___
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] No hotkey for "Set Bus Entry Shape"

[Andy Peters]

> On May 31, 2020, at 12:30 PM, Ian McInerney  wrote:
> 
> There are currently 2 actions on the Eeschema tool framework for changing the 
> bus entry shape, but they don't have a hotkey assigned by default. 
> Additionally, bus entries are able to be mirrored and rotated as normal 
> (using the hotkeys for those actions). So I guess the question is, do we need 
> to have explicit actions for changing the shape of the bus entry when all 
> that is really doing is a mirror/rotate and we allow that anyway?
> 
> -Ian

All right, I just checked in 5.1.6, and the usual X and Y mirror and R rotate 
hotkeys work. But … that’s not obvious, by which I mean if you right-click on 
the bus entry, the context menu does not offer those options like it does if 
you click on a part symbol. It only shows options to move the entry (M), change 
the shape and delete the entry. From the user perspective, then, the X/Y/R 
commands don’t exist. I can’t speak for any other users, but it seems to me 
that the context menu is useful for reminding the user about what commands are 
available/allowable for the thing under the cursor.

I agree that the action for changing the entry shape is redundant, but only if 
the mirror and rotate options are added to the context menu.

And it’s still an annoyance that you can’t see the entry before you place it. 
One _can_ see a part symbol (ghosted) as you move the mouse prior to placement, 
so for consistency the bus entry should work the same way. Place Junction also 
doesn’t show the junction before it’s placed, but at least you know it exists 
only at the mouse pointer.

-a

> 
> On Sun, May 31, 2020 at 8:05 PM Andy Peters  <mailto:de...@latke.net>> wrote:
> 
> 
>> On May 31, 2020, at 6:12 AM, Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote:
>> 
>> Maybe it got dropped when Eeschema was ported to the new tool framework
>> or broken somewhere along the way.  I'm not seeing a way to change the
>> bus entry orientation on master in Linux either so I suspect it got
>> dropped.  I don't see a issue report for this on GitLab so please file
>> an issue so it doesn't get lost in developers mailing list.
> 
> 
> It’s good to know I’m not crazy.
> 
> Issue here: https://gitlab.com/kicad/code/kicad/-/issues/4588 
> <https://gitlab.com/kicad/code/kicad/-/issues/4588>
> 
>> On 5/29/20 7:40 PM, Andy Peters wrote:
>>> In 5.1.6 schematics on macOS Catalina, which is what I’m using, and this 
>>> may be older …
>>> 
>>> When you choose “place wire to bus entry” (or the ‘z’ key) or “place bus to 
>>> bus entry” (or ‘/‘), you don’t see the entry until you click the mouse on 
>>> the schematic. And there’s no way to change the angle of the entry at 
>>> placement time. There is no hotkey entry for that option, and the only way 
>>> I can see to change it is to place the entry, get out of the place mode, 
>>> right-click select then entry and then choose “set bus entry shape” from 
>>> the context menu, and them move the entry to where you actually want it.
>>> 
>>> Yeah, that’s not good.
>>> 
>>> Am I missing something?


___
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] No hotkey for "Set Bus Entry Shape"

[Andy Peters]

> On May 31, 2020, at 6:12 AM, Wayne Stambaugh  wrote:
> 
> Maybe it got dropped when Eeschema was ported to the new tool framework
> or broken somewhere along the way.  I'm not seeing a way to change the
> bus entry orientation on master in Linux either so I suspect it got
> dropped.  I don't see a issue report for this on GitLab so please file
> an issue so it doesn't get lost in developers mailing list.


It’s good to know I’m not crazy.

Issue here: https://gitlab.com/kicad/code/kicad/-/issues/4588 
<https://gitlab.com/kicad/code/kicad/-/issues/4588>

> On 5/29/20 7:40 PM, Andy Peters wrote:
>> In 5.1.6 schematics on macOS Catalina, which is what I’m using, and this may 
>> be older …
>> 
>> When you choose “place wire to bus entry” (or the ‘z’ key) or “place bus to 
>> bus entry” (or ‘/‘), you don’t see the entry until you click the mouse on 
>> the schematic. And there’s no way to change the angle of the entry at 
>> placement time. There is no hotkey entry for that option, and the only way I 
>> can see to change it is to place the entry, get out of the place mode, 
>> right-click select then entry and then choose “set bus entry shape” from the 
>> context menu, and them move the entry to where you actually want it.
>> 
>> Yeah, that’s not good.
>> 
>> Am I missing something?
>> 
>> -a
___
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] No hotkey for "Set Bus Entry Shape"

[Andy Peters]

In 5.1.6 schematics on macOS Catalina, which is what I’m using, and this may be 
older …

When you choose “place wire to bus entry” (or the ‘z’ key) or “place bus to bus 
entry” (or ‘/‘), you don’t see the entry until you click the mouse on the 
schematic. And there’s no way to change the angle of the entry at placement 
time. There is no hotkey entry for that option, and the only way I can see to 
change it is to place the entry, get out of the place mode, right-click select 
then entry and then choose “set bus entry shape” from the context menu, and 
them move the entry to where you actually want it.

Yeah, that’s not good.

Am I missing something?

-a


___
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] What is a global variable, and why we don't need them.

[Andy Peters]

> On Apr 12, 2020, at 6:50 AM, Brian  wrote:
> 
> Just out of curiosity, what’s an example use case for multiple projects open 
> at once, that isn’t served by multiple instances of KiCAD?  I admit I haven’t 
> run into many reasons to have more than one open at a time in my own usage 
> other than occasionally referring to an old project as a reference for a new 
> one.

For starters, you can’t have multiple instances of Kicad running on macOS.

-a
___
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] Back annotate references from PCB

[Andy Peters]

> On Dec 1, 2019, at 1:06 PM, Jon Evans  wrote:
> 
> From another professional user, I have to disagree. There are at least two 
> cases I can think of where changing the footprint during layout is important:
> 
> 1) In my experience, it's common to keep multiple variants of IPC standard 
> SMD footprints, especially for passives. By default, we specify the "medium 
> density" variant of an 0402 resistor or capacitor, but in some cases 
> (critical controlled impedance, small BGA decoupling, etc) we may decide 
> during layout that it is best to switch to the "high density" (minimal pad 
> size) version of the 0402.

> 2) similarly, we might have a design with 0402 passives that we determine 
> during layout needs to switch to 0201 in some cases to make proper layout 
> possible. In this case, it's indeed an entirely different part, not just a 
> variant footprint for the same part, but the decision is made at layout time 
> and back-annotated onto the schematic (which will then drive the BOM). 
> 
> Neither of these workflows is particularly easy in KiCad today, but I'm 
> mostly talking about my experience with commercial tools here. 
> 
> This isn't necessarily me saying that these workflows need to be supported by 
> this current back-annotation effort (I think they also depend on several 
> other large future changes), just saying they are valid in my opinion. 

We do both of what you mention. But (and this is with Altium at the day job) 
when those footprint-change decisions are made, the layout guy finds it easier 
to update the schematics with the correct part and go forward. We do have 
symbols for the same part that call out the different footprints as needed for 
fab reasons.

Our main layout guy has access to the schematics and he keeps both the layout 
and the schematic on screen while working. So sure, a change like this is made 
at layout time, but it certainly seems easier to just change the schematic and 
go forward. Especially since you can do searches in the schematic editor for 
any set of parameters you like and let it change them all at the same time.

But of course everyone has methods that work for them.

-a 


> 
> -Jon 
> 
> On Sun, Dec 1, 2019, 14:46 Andy Peters  <mailto:de...@latke.net>> wrote:
> 
> 
> > On Dec 1, 2019, at 6:59 AM, Vesa Solonen  > <mailto:vesa.solo...@aalto.fi>> wrote:
> > 
> > Eeli Kaikkonen kirjoitti 1.12.2019 klo 0.08:
> > 
> >> BTW, about the possibility of changing the footprint - I have always found
> >> being able to change footprints in pcbnew strange because then it's out of
> >> sync with the schematic and it has to be changed in the schematic manually
> >> and updated to layout anyways. Being able to update it from the layout to
> >> the schematic looks like an obvious missing feature.
> > 
> > I would consider it a missing feature that the schematic-layout path is
> > anything but completely bilateral. Everything should be editable and
> > propagated both ways and question remains does it even make sense to
> > have different files. If a footprint is added or gate/pin swapped on the
> > PCB side the changes should show as rubber bands on the schematic, just
> > like it works from update PCB form schematic. Proper back annotation is
> > a good middle target, but having complete seamless bilateral data and
> > action model is way more usable albeit complex.
> 
> I want to add the perspective of a professional user. 
> 
> We don’t change footprints in the layout editor. Why? Because NE5532D in 
> SOIC-8 is not the same part as NE5532P in PDIP-8. Going backwards in this 
> manner blows up the BOM, unless you can work out some way of back-annotating 
> a different part number for each instance of this device without making 
> mistakes. The footprints in pcbnew have no knowledge of a part number, so 
> there is no way of changing that in layout and bringing it back to schematic.
> 
> (I assume that most people use the schematic as the “master source,” and BOMs 
> and such are generated from it, not layout.)
> 
> The "house part number” decouples a thing on your schematic from what you 
> order. There are a dozen resistor manufacturers, so rather than putting 
> “manufacturer=Panasonic” and “base part number=ERJ-“ in the symbol, you can 
> just put a house part number in a PN field and then a downstream database can 
> map it to what your purchasing person can order.
> 
> Anyway, it’s a lot easier to update the schematic with the new part and then 
> forward-annotate, and this keeps both schematic and layout in sync.
> 
> Pin-swapping and gate-swapping are much more important. The pin swapping 
> makes for an interesting pro

Re: [Kicad-developers] Back annotate references from PCB

[Andy Peters]

> On Dec 1, 2019, at 6:59 AM, Vesa Solonen  wrote:
> 
> Eeli Kaikkonen kirjoitti 1.12.2019 klo 0.08:
> 
>> BTW, about the possibility of changing the footprint - I have always found
>> being able to change footprints in pcbnew strange because then it's out of
>> sync with the schematic and it has to be changed in the schematic manually
>> and updated to layout anyways. Being able to update it from the layout to
>> the schematic looks like an obvious missing feature.
> 
> I would consider it a missing feature that the schematic-layout path is
> anything but completely bilateral. Everything should be editable and
> propagated both ways and question remains does it even make sense to
> have different files. If a footprint is added or gate/pin swapped on the
> PCB side the changes should show as rubber bands on the schematic, just
> like it works from update PCB form schematic. Proper back annotation is
> a good middle target, but having complete seamless bilateral data and
> action model is way more usable albeit complex.

I want to add the perspective of a professional user. 

We don’t change footprints in the layout editor. Why? Because NE5532D in SOIC-8 
is not the same part as NE5532P in PDIP-8. Going backwards in this manner blows 
up the BOM, unless you can work out some way of back-annotating a different 
part number for each instance of this device without making mistakes. The 
footprints in pcbnew have no knowledge of a part number, so there is no way of 
changing that in layout and bringing it back to schematic.

(I assume that most people use the schematic as the “master source,” and BOMs 
and such are generated from it, not layout.)

The "house part number” decouples a thing on your schematic from what you 
order. There are a dozen resistor manufacturers, so rather than putting 
“manufacturer=Panasonic” and “base part number=ERJ-“ in the symbol, you can 
just put a house part number in a PN field and then a downstream database can 
map it to what your purchasing person can order.

Anyway, it’s a lot easier to update the schematic with the new part and then 
forward-annotate, and this keeps both schematic and layout in sync.

Pin-swapping and gate-swapping are much more important. The pin swapping makes 
for an interesting problem, which is making sure the resulting schematic isn’t 
a mess. Most likely an informal (or required) “rule” would be that you draw a 
net from each pin that can be swapped and you give them net labels, but you 
don’t draw that net to any other pin.

Thanks to everyone involved in adding the back-annotation feature!

-a




___
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] 5.1.5 release tag

[Andy Peters]

> On Nov 26, 2019, at 10:43 AM, Seth Hillbrand  wrote:
> 
> On 2019-11-26 08:47, Andy Peters wrote:
> 
>>> On Nov 25, 2019, at 7:02 PM, Adam Wolf  
>>> wrote:
>>> Andy, thank you so much for this.  I normally run through the releases but 
>>> I am quite behind on some work and you definitely prevented the macOS 
>>> release from holding everything up :)
>>> I'll trigger builds tonight--there already is a deep queue for nightlies, 
>>> and in the morning I'll upload them to downloads and let Wayne know so we 
>>> can announce.  Thanks everyone!
>> One more "bug," not sure if it's a bug or by design.
>> I use both Windows and macOS, and I set up Kicad 5.1.4 on a Windows machine. 
>> I wanted to copy my symbol table from the Mac to the PC, and I saw that for 
>> whatever reason my symbol table file didn't use $KICAD_SYMBOL_DIR, and 
>> instead it hardcoded the path to /Users/andy/Library/Application 
>> Support/kicad/library -- and that won't work on Windows. So I changed the 
>> entries to use the $KICAD_SYMBOL_DIR, and then I noticed that the 
>> environment variable on the Mac pointed to /Users/andy/Library/Application 
>> Support/kicad/library
>> I changed it (again, on the Mac) to the usual ~/Library/Application 
>> Support/kicad/library and Kicad didn't like that. I got a (broken) message 
>> box saying,
>> So the home-directory shortcut doesn't work. I honestly don't remember if it 
>> ever worked, or was meant to work.
> 
> Hi Andy-
> 
> Thank you for testing.  Please report all bugs to the bug tracker.  In thread 
> here will be lost and not tracked.

https://bugs.launchpad.net/kicad/+bug/1854087 
<https://bugs.launchpad.net/kicad/+bug/1854087>

-A___
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] What does "when in doubt do it opposite than certain other pcb tool" stand for?

[Andy Peters]

> On Nov 26, 2019, at 10:41 AM, Seth Hillbrand  wrote:
> 
> On 2019-11-26 09:05, Tomasz Wlostowski wrote:
>> On 22/11/2019 17:42, Rene Pöschl wrote:
>>> I would assume this is referencing version 6 of eagle. The current
>>> versions of eagle are actually something that can (in some aspects) be
>>> used as a good example. I would therefore assume that this sentence is
>>> simply out of date and could be removed or at least reworded.
>> I don't have access to that webpage, but whoever has, feel free to
>> remove it.
>> Tom
>> _
> 
> Which website are we talking about?  I followed Rene's link but it just went 
> to the Doxygen site and I don't see that statement there.

It’s here: http://docs.kicad-pcb.org/doxygen/v6_road_map.html 


-a___
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] GitLab migration

[Andy Peters]

> On Nov 25, 2019, at 10:10 AM, jp charras  wrote:
> 
> Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
>> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>>> 2FA would be using something like Google Authenticator on your phone,
>>> a YubiKey or SMS message code to verify your login on a computer in
>>> addition to the password.
>> 
>> It may not affect me as I'm a user of KiCad and occasional reporter of
>> bugs. What gitlab activities would require 2FA? Reading the link
>> supplied about 2FA says it would send a message to a phone. I don't
>> have, or want, a cell phone. How would requiring 2FA affect others
>> without a cell phone who want to use the gitlab repo site?
>> 
> 
> I am also like Kevin:
> I don't have, or want, a cell phone (or any Google account).
> 
> A simple password is not perfect, but at least it is easy to use and
> works from any computer install.
> Kicad gitlab repo is for a FOSS development.
> It is not for Fort Knox access management.

2FA will work with an email address — this is how one of my banks does it. They 
send the code to the email address. It works, and isn’t too annoying, except 
when the mail servers are slow to respond.

I prefer SMS to my iPhone, which when used with iMessages, the code sent to my 
iPhone goes to all of the devices connected to my iCloud account, and then 
magically Safari “knows” that the message was sent and offers to fill in the 
code.

2FA is going to be the way of the world as all banking and such move to it, at 
least until a better authentication mechanism comes along.
___
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] Back annotate references from PCB

[Andy Peters]

> On Nov 22, 2019, at 2:30 PM, Dino Ghilardi  wrote:
> 
> Just my two cents on this.
> 
> Considering that the actual "manual work-around" to do the "back annotation" 
> now can be:
> 
> -Open pcbnew and eeschema at the same time
> -Select the component you want to rename on pcbnew
> -the right symbol gets highlighted (but not selected) automatically in 
> eeschema
> -select the highlighted component in eeschema, press "U" shortcut (edit 
> reference)
> -change the reference in the dialog
> -press F8 to update the pcb
> 
> A possible approach is to use this sequence of operations (...future python 
> script?).
> 
> Since the mechanism to find the correct symbol on eeschema seems yet 
> implemented, probably the only missing parts would be to implement is
> 
> Enable from pcbnew the command "select the highlighted component and/or open 
> the "edit reference" dialog.
> 
> Drawbacks:
> -Requires eeschema and pcbnew open at the same time (may be this is not a  a 
> problem since we also have DRC that opens eeschema when run).
> -Requires to check that schematic and layout are synchronized before starting 
> the back-annotation (probably needed also for all the other implementations).
> -For bigger schematics the full-update via F8 can become slow, so as a future 
> improvement, after a first working implementation could be a way to update 
> only the modified field.

I have done manual back-annotation because automated back-annotation (what 
Brian Piccioni is doing) didn’t exist.

I’m in the habit of doing “geographical re-annotation” after a layout has 
completed. This is where the layout is scanned and, say, the resistor most near 
the upper left is numbered R1, the resistor to its right is then R2, and so on. 
This is purely an aid for the human assembler and the human debugging the 
design. It’s not really interesting for automated assembly.

You can do this manually, on a small design, using the approach you suggest, 
but for anything complex (my last board was 165 mm x 125 mm with about 150 
capacitors, a hundred resistors, and a bunch of ICs) it’s impossible.

So it really needs to be automated. The options, as I see them, are few and 
simple: origin, direction (increasing in X or increasing in Y) and an option to 
not re-annotate a part (maybe don’t change the reference designators for 
connectors). The logic of the sorting is straightforward, but it’s a task best 
left to the machines.

-a
___
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] Back annotate references from PCB

[Andy Peters]

> On Nov 22, 2019, at 12:42 PM, Brian  wrote:
> 
>>> On 22 Nov 2019, at 19:29, Brian >> > wrote:
>>> 
>>> From the peanut gallery:
>>> 
>>> Can someone tell me an example use-case for a single schematic symbol 
>>> corresponding to multiple board entities within a single project?
>>> 
>>> As perhaps a rather naïve PCB designer, it seems like mostly a bad idea to 
>>> me to have anything other than 1:1.
>>> 
>>> Thanks,
>>> -Brian Henning 

>> On 11/22/19 2:37 PM, Jeff Young wrote:
>>> Hi Brian,
>>> 
>>> Imagine you’re doing an audio amplifier.  Your main schematic sheet has 4 
>>> subsheets: PSU, control logic, left channel and right channel.  Both left 
>>> channel and right channel point to the same sub-page.  So there’s a single 
>>> schematic symbol for each part in the left & right channel, which gets 
>>> annotated as two different references (ie: Q101 and Q201), and attached to 
>>> two different footprints.
>>> 
>>> Cheers,
>>> Jeff.
>>> 

> Hi Jeff,
> 
> Thanks for helping me understand this.  So how would someone looking at the 
> schematic know that this one symbol represents both Q101 and Q201?  For that 
> matter, if there's some instructions or a tutorial about creating a situation 
> like this (one schematic drawing representing multiple instances of the 
> subcircuit on the pcb), I'd be interested to learn it.  I have a couple 
> projects in the pipeline where I might find this feature useful; in the past, 
> I've manually copy/pasted sections of a schematic to repeat subcircuits.
> 
> Thanks,
> -Brian

When I first read Brian H’s message, “multiple board entities” stood out — I 
thought he was talking about having more than one physical PCB in the project! 
Now I understand his concern.

Brian — when you have a design which uses multiple instantiations of the same 
sub-sheet, when you look at that design in the schematic editor (are we still 
calling it EESChema?) you can navigate through the sub-sheets using the 
Hierarchical Navigator. In each instance of a sub-sheet, you will see that each 
component has been assigned unique reference designators.

So do a simple test. Create a project. In the project’s main sheet, choose 
Create Hierarchical sheet from the right-hand menu. Give it a reasonable file 
name (like subsheet.sch) and give it a reasonable Sheet Name. (Sheet name is 
basically a reference designator for a sub-sheet.) Enter that sheet, add some 
parts. keep it simple, like a single inverting op-amp circuit, so an op-amp 
symbol and two resistors. Add two power symbols for the op-amp power. Add 
hierarchical labels for the input and output. Don’t worry about annotation yet. 
Save the sheet. 

Navigate back to the top. Right-click on the sub-sheet symbol and choose 
“Import sheet pins.” You need to do this once for each hierarchical label you 
added. This is how you bring nets up to a higher level. Now select that 
sub-sheet symbol by left-clicking/holding and drawing a rectangle around it. 
Right-click and choose “duplicate block.” Now you have a new instance of that 
same sub-sheet. Place it. Then right-click on it, choose “Edit …” (or just hit 
E) and give it a better sheet name. Now you have two unique instances of that 
sub-sheet. Choose Tools -> Annotate Schematic. When that’s done, enter each of 
the sub-sheets — you will see that they each have unique reference designators 
for the same symbols. Also, the non-hierarchical (local) nets in each sub-sheet 
will have unique net labels! So when you export the netlist for PCB it’ll work 
as you expect.

Oh, yeah, when you print out the schematic, you will get as many sheets as you 
have instances of the sub-sheets. So the simple example here, with a top-level 
sheet and two instances of a single sub-sheet will give you three printed pages.

Try it!

-a___
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] 5.1.5 release tag

[Andy Peters]

> On Nov 22, 2019, at 8:02 AM, Adam Wolf  wrote:
> 
> If folks on 10.14 or 10.15 could test
> https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.5-rc1-10_14.dmg,
> and anyone still on 10.13 or lower could test
> https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.5-rc2.dmg,
> that would be great.

I have all three. Will do so this weekend.

-a


> 
> Adam
> 
> On Wed, Nov 20, 2019 at 7:11 PM Adam Wolf  
> wrote:
>> 
>> I set rc1 to build earlier today.  I can upload it when it finishes and if 
>> folks can test it, I can easily rebuild as 5.1.5 tomorrow!
>> 
>> On Wed, Nov 20, 2019, 4:59 PM Wayne Stambaugh  wrote:
>>> 
>>> I'm willing to push the release date up if the MacOS package is ready.
>>> Just let me know.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 11/20/19 5:46 PM, Nick Østergaard wrote:
>>>> 5.1.5 is fairly well rolled out now, thanks to various good people :)
>>>> 
>>>> To make the release official, I think we are only needing the macos
>>>> build. @Adam Wolf  if you need any help, please speak up.
>>>> 
>>>> 
>>>> Nick
>>>> 
>>>> On Wed, 20 Nov 2019 at 19:33, Steven A. Falco  
>>>> wrote:
>>>>> 
>>>>> Fedora Rawhide has 5.1.5 now.  Fedora 30 and 31 will have 5.1.5 in a week 
>>>>> or so, depending on whether we get any karma.
>>>>> 
>>>>> Also of note - as of 5.1.5 we are now using OCC on all builds.  OCE is no 
>>>>> longer needed for current Fedora releases.
>>>>> 
>>>>>Steve
>>>>> 
>>>>> On 11/17/19 11:56 AM, Rene Pöschl wrote:
>>>>>> Libraries have been tagged.
>>>>>> 
>>>>>> On 14/11/2019 18:36, Wayne Stambaugh wrote:
>>>>>>> The 5.1 branch has been tagged for 5.1.5 and the source archive has be
>>>>>>> uploaded to launchpad.  Please tag the library, doc, and translation
>>>>>>> repos so we can fire up those packages builders.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Wayne
>>>>>>> 
>>>>>>> On 11/13/19 3:55 PM, Wayne Stambaugh wrote:
>>>>>>>> It's been a couple of weeks since 5.1.5-rc1 was tagged and everything
>>>>>>>> seems to have stabilized nicely.  I'm going to tag 5.1.5 tomorrow 
>>>>>>>> around
>>>>>>>> noon EST unless something comes up.  I'm assuming the libraries,
>>>>>>>> documentation, and translations are ready to go and that it shouldn't
>>>>>>>> take too long to get most of the installer packages build and uploaded
>>>>>>>> to the KiCad website.  I would like to make the release announcement on
>>>>>>>> Wednesday, November 27th.  It would be something to be thankful for
>>>>>>>> leading into the US Thanksgiving Holiday.  If there are any issues with
>>>>>>>> this date, please let me know.  Thank you everyone for your continued
>>>>>>>> support of the KiCad project.
>>>>>>>> 
>>>>>>>> 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
>>>> 
>>> 
>>> ___
>>> 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

Andy Peters
5511 E Rosewood St
Tucson, AZ 85711
520-907-2262
de...@latke.net




___
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] Project save as

[Andy Peters]

> On Nov 11, 2019, at 1:28 PM, Seth Hillbrand  wrote:
> 
> On 2019-11-11 11:42, Jeff Young wrote:
> 
>> A... I didn't notice that.  We are indeed failing to look for the Protel 
>> extensions.
> 
> Are we renaming generated files?  If we stick with base project files, it's 
> easy to explain where the cut-off is.  Once we go down into generated files, 
> this gets harder and harder especially as we start implementing more exports 
> (IPC-2581, D-365, XY files, etc) where we don't control the extensions.

Unless I’m mistaken, isn’t the use case for “Project Save As” to fork a new 
project from one that exists? In that case, the generated files, like Gerbers 
and the net list, are immediately invalid as soon as the user starts to make 
modifications to the project. Nobody keeps the .o files around after the 
application is built … 

And regarding the use of “Project Save As,” consider the plight of users who 
keep projects in a source-code control repository. I realize that this is a can 
of worms. 

-a
___
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] GitLab migration

[Andy Peters]

> On Oct 9, 2019, at 9:36 AM, Wayne Stambaugh  wrote:
> 
> The lead development team has been discussing migrating the KiCad
> project to GitLab[1].  Given the issues with Launchpad, I think this is
> a good move. 

I presume that the developers and other interested parties will need to create 
accounts on GitLab?

-a


___
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] Mac folks, Catalina help?

[Andy Peters]

> On Oct 7, 2019, at 12:04 PM, Adam Wolf  wrote:
> 
> Hi folks!
> 
> The latest version of macOS went public today, and we have an issue
> where you can't make a new project on it :)
> https://bugs.launchpad.net/kicad/+bug/1834717
> 
> I want to get a better debugging setup in Catalina so I can maybe see
> a better stack trace, but it's going to take a few days.  I spent a
> lot of time over the last two weeks debugging an issue with simulation
> with ngspice issue with Holger (which seem to be much better now!) and
> need to hit some other deadlines before I can spend a lot more time on
> KiCad.
> 
> If there's mac dev folks who have a setup where they can dig in,
> awesome.  If not, that's OK--it'll just take me a bit before I can
> dive into this.
> 
> If someone could amend our website so it's clear that there are issues
> on Catalina right now but we're working through them, that would
> probably help the support load.

I installed Catalina this afternoon and started Kicad 5.1.4 without any 
problems.

Application: KiCad
Version: (5.1.4-0-10_14), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.64.1 SecureTransport (LibreSSL/2.8.3) zlib/1.2.11 nghttp2/1.39.2
Platform: Mac OS X (Darwin 19.0.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
Boost: 1.69.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.54.0
Compiler: Clang 9.0.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
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

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

[Andy Peters]

> On Sep 16, 2019, at 6:12 AM, Clemens Koller  wrote:
> 
> Hello, Tim!
> 
> I agree that in the near future, the demand for (I'd call it) "Table Based 
> Design Entry" will rise tremendously,
> when we reach pincounts in the high hundreds and thousands.
> 
> It is a lot of work to draw and maintain complex MCUs/SoCs/FPGAs in some 
> schematic when pins can have 8 different functions which might change during 
> product development. A current example: i.MX8 [1] with i.e. 625 pins.
> So, it might not even be sufficient to be able to import (and export) .CSVs. 
> It might be a good idea to prepare for some automatism to be able to update 
> and version control pin multiplexing changes!


How about this?

We can all agree that grouping MCU pins by peripheral makes the most sense. So 
rather than having a big box symbol (or symbols) with pins in a default order, 
why not have each part of a component be a peripheral? Instead of having a 
multisymbol part with one or two or three boxes for my EFM32GG11B820F2408GL192 
in the library, instead of EFM32GG11B820F2048GL192 as the part name and within 
the part have all of the valid peripherals for that device? 

Here’s the cool thing. This device has, say, I2C0, I2C1, I2C2, UART0, UART1, 
USART0, USART1, TIMER0, TIMER1, all of it, and there are a fixed number of 
peripherals for a given device. Each peripheral is a symbol (a sub-part of the 
device) you can place on your schematic. Need a UART? Place the EFM32GG11_UART0 
symbol on the schematic. Since this particular chip family gives you several 
choices for each pin, the symbols are “Smart” and have a drop-down menu you use 
to assign the pin. Those assignments also automatically set pin direction and 
the other ERC stuff. For peripherals which have one location for their pins 
obviously this drop-down doesn’t exist.

Cool, right? It can be better. Any pin not explicitly designated for a 
peripheral that can be used as GPIO gets enabled in the GPIO symbol. In that 
symbol then you set the direction, etc after you place it on the schematic.

Since all of the ARM vendors these days have some kind of software tool that 
handles peripheral setup including pin assignments, having the ability to read 
that output (whatever it is) and then parse it and set up the individual blocks 
would be very cool.

Right now I just rely on sensible net names to keep my MCU pinouts straight. I 
used to make a custom symbol for each MCU in a design but that got to be too 
much.

FPGAs are a different can of worms.

-a
___
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] Ctrl-click to highlight in pcbnew missing?

[Andy Peters]

> On Sep 10, 2019, at 11:55 AM, Tomasz Wlostowski  
> wrote:
> 
> On 10/09/2019 20:45, Andy Peters wrote:
>> 
>> Ctrl-Click on macOS defaults to right-button click, harkening back to
>> the days of the Mac’s one-button mouse (“one button oughta be enough for
>> everyone!”).
> 
> Not much changed since then ("unusable keyboard oughta be enough for
> everyone - all they need is to consume our content anyway" - Macbook
> 2018 sales pitch :-)

Oh, good god, don’t get me started on the shitty keyboard on the 2017 Touch Bar 
MacBook Pro on which I type this! But the Mac trackpads are still head and 
shoulders above every comer. 

(Truth be told, this MBP is a GREAT Kicad machine.)

-a
___
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] Ctrl-click to highlight in pcbnew missing?

[Andy Peters]

> On Sep 10, 2019, at 11:35 AM, Tomasz Wlostowski  
> wrote:
> 
> On 10/09/2019 18:49, Seth Hillbrand wrote:
>> One of our goals for v6 is to standardize the user interface to expected
>> UX norms.  There will be a number of large changes to accomplish this
>> and it will modify some workflows.  Moving the whole system to a
>> selection-based interface (eeschema, pl editor as well as pcbnew) is
>> good for long-term uptake of the system as well as making it easier to
>> maintain.
> 
> Well, Ctrl-click to highlight was added by me during early development
> of the GAL, because some other tools I'm quite used to have this
> shortcut and the legacy highlight tool was a bit awkward for me.
> Concerning the UX norms, it's not obvious that Ctrl is the standard way
> of adding/removing items from the current selection. A quick test showed
> that:
> - MS office selection mode (sort of standard for Windows UX), Ctrl and
> Shift have the same behaviour.
> - LibreOffice ignores Ctrl modifier when selecting, only Shift works
> - Same in case of Corel programs.
> I know these keys have different function for selection lists (i.e. the
> explorer window with folder/file icons), but this is not our case. IMHO
> modifier keys (Shift, Alt, Ctrl) in a CAD tool should each have
> different frequently used function.
> 
> If nobody opposes, I'll add an option in pcbnew preferences to select
> between Ctrl-Click and a keyboard-only shortcut for net highlight.

Ctrl-Click on macOS defaults to right-button click, harkening back to the days 
of the Mac’s one-button mouse (“one button oughta be enough for everyone!”).

-a___
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] 5.1.4 release - release announcement/blog entry?

[Andy Peters]

> On Aug 13, 2019, at 10:57 AM, Adam Wolf  wrote:
> 
> macOS is ready!

Hola — downloaded and installed it, and got the complaint about “unidentified 
developer.” I know how to work around that, but I thought the builds were 
signed so the complaint doesn’t pop up?

-a
___
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] fp-info-cache question

[Andy Peters]

> On Jul 23, 2019, at 2:46 PM, Jeff Young  wrote:
> 
> Hi Kevin,
> 
> No this is just a cache of footprint library properties so that we can index 
> and search footprints without loading them all into memory.  It’s entirely 
> for performance.

User question:

Should the project-level cache file be included in the SCC respository, or is 
it rebuilt as necessary?

Thanks.

-a
___
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] New package for macOS 5.1.2 stable including ngspice-30 ?

[Andy Peters]

> On Jul 1, 2019, at 1:38 PM, Nick Østergaard  wrote:
> 
> Good news, it seems like we managed to make the kicad-mac-packaging
> scripts happy.
> 
> After upgrading to ngspice 30 we had to update the include path for
> some unknown reason. But it seems like it should work now. The first
> build has been pushed to the nightly download location. It is not been
> repackaged for stable. I guess Adam will handle that if we don't
> release a 5.1.3 before.
> 
> But I don't think it is ready for primetime yet, first user of the build says:
> 
> <{HD}> haha so hitting the play button crashed all of kicad
> <{HD}> yep, just tried again. The whole thing crashes.
> <{HD}> This is fun and all but I am going out for dinner. I will be
> back in a few hours.
> 
> So if anyone else on mac could try it out? Maybe you Jeff can try it out?
> I think he tested the unified version:
> https://kicad-downloads.s3.cern.ch/osx/nightly/kicad-unified-20190701-113048-53e18489e-10_14.dmg

I will try it tonight. Does anyone have an example circuit with models I can 
use?

-a




> Cheers.
> 
>> On Fri, 21 Jun 2019 at 11:16, Nick Østergaard  wrote:
>> 
>> I see no reason to make ngspice 30 a strict minimum requirement.
>> 
>> Lets just help packagers update to the latest ngspice and we are good.
>> 
>> tor. 13. jun. 2019 18.33 skrev Wayne Stambaugh :
>>> 
 On 6/10/19 4:01 PM, Carsten Schoenert wrote:
 Hello Wayne,
 
> Am 10.06.19 um 20:15 schrieb Wayne Stambaugh:
> We cannot make ngspice 30 the minimum version.  There are far too many
> linux distros where 30 is not available yet.  Please keep in mind,
> Debian stable and the latest Ubuntu LTS version are the benchmarks for
> dependency package versions.  I'm fine with packaging macos and windows
> with 30.
 
 current Debian stable (Stretch) has KiCad version 4.0.5+dfsg1-4 in the
 archive and no package libngspice0 at all (not even in non-free) so
 there is nothing to take care on here.
 
 The current Ubuntu LTS release 18.04 (Bionic Beaver) has KiCad version
 4.0.7+dfsg1-1ubuntu2 and libngspice0 version 27-1.
 At least the KiCad version is long long outdated. So also not really
 relevant too.
 
 But all relevant current Debian releases are providing a recent KiCad
 version and also libngspice0 in version 30.2-1 (from unstable to
 stretch-backports). This is also available in all Downstream of Debian
 means also in Ubuntu >= 'Cosmic Cuttlefish' are providing KiCad
 5.0.0+dfsg1-2, but also libngspice0 in version 27. Updates wont happen.
 
 But Jean-Samuel Reynaud is providing actual versions of KiCad and also
 the depending libngspice0 package and they even work in the always
 outdated Linux Mint distro. So for me your requirements you like to set
 are fulfilled.
 
 And normally the application is defining the requirements. Simulations
 seems to be for some users an critical option. So if the maintainers of
 ngspice hardly suggesting to use the most recent version of ngspice in
 recent KiCad version I would strongly consider to increase this build
 dependency.
 
 In the end it's up to the KiCad maintainers to define the requirements
 for KiCad. It was a long road to get ngspice into Debian main but in the
 end it happened, big thanks to Holger again btw! So Debian has no
 problem to provide KiCad with a depending libngspice0 library >= 30.2.
 
>>> 
>>> Is this a problem for any of the other package devs?  If not, I have no
>>> issue with bumping the minimum version to 30.  If this prevents any
>>> other platforms from being built, then it will have to wait.
>>> 
>>> 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

Re: [Kicad-developers] running multiple versions of KiCad on macOS

[Andy Peters]

> On Jun 12, 2019, at 5:12 PM, Seppe Stas  wrote:
> 
> Andy, I don’t think Adam is talking about the library folders, those can 
> already be easily set using environmental arguments.

Oh, apologies, I think he is referring to the stuff which lives in 
~/Library/Preferences/kicad, where one finds a text file of settings for each 
of the Kicad programs as well as the library tables and more.

I suppose I’m like most users in that I never touch any of those files 
manually. I rely on the programs to set them. And that’s true even for library 
tables. And I kinda forgot it existed.

-a
___
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] running multiple versions of KiCad on macOS

[Andy Peters]

> On Jun 12, 2019, at 2:38 PM, Adam Wolf  wrote:
> 
> Seeing Seppe's patch made me think of something I tried to do last
> time, but ended up running out of time.
> 
> What do folks think about changing the data directory for macOS to
> have the major version, to make it a little easier to run KiCad 5 and
> 6 on the same computer?  Am I opening a can of worms?

“data directory” as in where the libraries etc are stored?

Currently in ~/Library/Application Support/kicad or /Library/Application 
Support/kicad ??

Possibly changed to ~/Library/Application Support/kicad 5/ and 
~/Library/Application Support/kicad 6/ for example?

I don’t have a problem with it, but the question is how to manage it. Assume 
that everyone who already has Kicad installed is using the “default” location. 
When the user upgrades to a new major version, perhaps on first run it should 
ask about the library locations.

But there’s a complication … do those locations exist?

As part of that first run, should the new version offer to upgrade existing 
libraries and store them in the new location?

(And what does that do to users who keep libraries in source-code control and 
the libraries on the computers live in working copies?)

I mean, I agree that if the intent is to be able to run Kicad 5 and Kicad 6 on 
the same machine and those versions have incompatible libraries then yes, we 
need to be able to tell those two installs where their libraries live.

Of course, if Kicad 6 can use Kicad 5’s libraries as is, then there is no need 
for the distinction.

Yes, can of worms indeed.

-a
___
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] Atomic Libraries Proposal

[Andy Peters]

> On May 24, 2019, at 2:54 AM, Simon Richter  wrote:
> 
> Hi,
>   transistor symbols (BCE, BEC, CBE, CEB, EBC, ECB) into one and allow
>   switching mappings during PCB design?

Why is that even necessary? The footprints (TO-92, SOT-23, etc etc) all have 
standard pin numbers. The symbol for the transistor should map the E, C and B 
to the proper pin number 1, 2, 3. If you place transistor MBTA on your 
schematic, the correct footprint and correct pin mapping should automatically 
follow.


-a
___
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] eemodern branch

[Andy Peters]

> On Apr 29, 2019, at 10:28 AM, Kevin Cozens  wrote:
> 
> On 2019-04-29 1:13 p.m., Wayne Stambaugh wrote:
>> On 4/29/19 12:56 PM, Andy Peters wrote:
>>> 
>>> (And now the nattering nabobs of negativity on the EEVBlog forum will have 
>>> one less thing about which to complain.)
>>> 
>> I'm not holding my breath on that.
> 
> Naw... they will just find something else to complain about.

Yep. There are several non-users who demand that the Kicad developers implement 
a full-blown database library system, without bothering to subscribe to this 
mailing list or put forth an honest proposal for such a system.
___
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] eemodern branch

[Andy Peters]

> On Apr 28, 2019, at 8:22 PM, hauptmech  wrote:
> 
> On 29/04/2019 12:52 AM, Jeff Young wrote:
>> 3) Cut/copy/paste is now text-based over the system clipboard.  (This means 
>> you can also copy/paste between schematics, or even between your schematic 
>> and a text editor.)
> 
> I can't tell you how nice this sounds after opening schematics in a text 
> editor to 'copy and paste' for so long. Looking forward to using it.

Amen!

(And now the nattering nabobs of negativity on the EEVBlog forum will have one 
less thing about which to complain.)



___
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] [RFC] Exporter for Mentor Hyperlynx

[Andy Peters]

> On Apr 4, 2019, at 5:16 PM, Tomasz Wlostowski  
> wrote:
> 
> Hi,
> 
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> documented in [1], so here comes a patch that adds a Hyperlynx exporter.

Total wishlist here, but how about implementing a signal-integrity simulator in 
Kicad?

I realize this is like wishing for the moon.

-a
___
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] Feedback on 5.1

[Andy Peters]

On Mar 12, 2019, at 10:21 AM, Ruth Ivimey-Cook  wrote:

> SCHEMA
> Schema: taking part of a diagram and making that into a subsheet seems to 
> involve setting up the new sheet, Cutting components, entering the sheet, 
> then pasting. Could that be one action: Make new sheet with selection?
This would be brilliant.

> Schema: is there an official way to create a subsheet which is used multiple 
> times by a parent for the purposes of duplicating component groups? 
> I tried setting up a sheet with such a group (by editing the .sch file), 
> setting a global connector on it and using that connector to link to the 
> parent sheet and it works, sort of; when syncing the shema to pcb I got 
> complaints that I had multiple references to one sheet, but ignoring that did 
> not seem to have negative consequences. What didn't work was that any local 
> label in the subsheet was not local to that sheet instance but considered 
> shared with its sibling instances, which then messed up pcbnew's ratsnest 
> calculations.
> I don't report this as a bug because to get to this state I had to manually 
> edit the schema file... but it would be nice to be supported properly.
Creating multiple instances of a subsheet has been possible for quite a long 
time. Here’s what you need to do.

On a sheet where you want to create some instances of a subsheet, choose “Place 
Hierarchical Sheet” from the “Place” menu. Give the sheet a useful filename, 
perhaps channel.sch. Also give it a useful Sheet Name, such as ChannelA. This 
sheet name is basically a reference designator for the subsheet.

Enter the subsheet (double-click on it). Edit as you like. Make sure to add 
hierarchical labels to nets that need to connect to things outside of the 
sheet. Remember all power symbols create global nets.

Back on the instantiating sheet, make sure to Import the Sheet Pins for your 
subsheet. Then create another hierarchical sheet. Give it the same file name as 
before, say channel.sch. Give it a different Sheet Name, perhaps ChannelB. When 
you click OK, you’ll get a message box asking for confirmation: 

“channel.sch” already exists. Link “channelB” to this file? 

Click Yes. Import the sheet pins. Wire things up as you wish.

Alternatively, you can group-select the subsheet and duplicate it, then change 
the Sheet Name.

After all of that, annotate the schematic. When you do this each of the parts 
in the subsheet — which all have the same schematic — will have different 
reference designators. This is what you need to ensure that everything is 
unique.

And when you create the netlist for layout, the nets in each (otherwise 
identical) subsheet will have unique net names, too.

> Pcb: I love that we have align and distribute centre/top/left etc. However I 
> would like that to be possible for pcb tasks as well (e.g. align centre all 
> selected ICs, optionally dragging connections).
Already there, but not for the connections. Select the parts to align. 
Right-click, look for the “Align/Distribute” menu entry, mouse in the direction 
of the arrow, choose how you want to align.

> Pcb: I am still unsure that the windowing model Kicad uses is the right one. 
> The app doesn't behave as separate apps, one for schema, one for pcb etc, but 
> neither is it really behaving seamlessly. I think the best would be that each 
> of the current "apps" - schema, etc - becomes a "task window" within the 
> overall kicad app to a greater degree than is the case now.
On the Mac, when you choose to open schematics or layout (or library editors), 
you’ll get a new tab under the Kicad window. The menu bar and title bar will 
reflect the application which has focus. If you don’t like the tabs or if you 
want to see both schematic and layout at the same time, drag one of the tabs 
away from the tab bar and you’ll get that application in its own window. So 
when you can see both schematic and layout at the same time, you’ll see that 
when you select a part in one it’ll be highlighted/selected in the other.

-a___
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] Version 6 development planning

[Andy Peters]

> On Feb 13, 2019, at 5:06 PM, Brian Piccioni  
> wrote:
> 
> Wayne
> 
> On reflection it occurred to me that being able to vary the width of a 
> ratsnest by net (or perhaps netclass) may provide additional utility to being 
> able to vary colour by net.
> 
> Like bolding of text, it would make certain nets stand out. For example, +5V 
> might be red, +5V main buss might be red and extra thick (corresponding to 
> the netclass specification for a power buss, for example).
> 
> Of course, perhaps that is what you meant but I thought I'd put it out there.

One more wishlist item for ratsnests is the ability to turn off some of them 
entirely, perhaps by net class. A common case would be to turn off the ratsnest 
for the ground net. I believe it’s in the Launchpad wishlist, but I thought I’d 
mention it here as a reminder :)

-a
___
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] Pulling mac 5.0.2...

[Andy Peters]

> On Jan 7, 2019, at 3:20 PM, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Just a heads up, the macos 5.0.2 packages are gross for some reason.  I am 
> regenerating them and we'll see what's going on.
> 
> (I am regenerating them at 5.0.2-2)

Gross in what way? I haven’t pulled down a nightly in a couple of weeks.

-a
___
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] Hoping to contribute but I have some questions

[Andy Peters]

On Jan 4, 2019, at 10:51 AM, Brian Piccioni  wrote:
> 
> I am still keen to attempt to incorporate geographical component annotation 
> into KiCad. In general, it is preferable for component annotation to be done 
> relative to the PCB and in some logical order (left/right, top to bottom, 
> etc). Thereafter this information is imported to the schematic. I wrote a 
> standalone utility (RenumKicadPCB) which does this but ideally, we’d want the 
> function built into Kicad.

I’ve said before that this is a vital feature Kicad reallly needs.

Let me know how I can test this.

-a
___
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 user's forum down?

[Andy Peters]

> On Dec 6, 2018, at 10:15 AM, Wayne Stambaugh  wrote:
> 
> I can get it if I use a different browser but Chrome is still giving me
> issues.  Sorry about the noise.

I’ve heard a bunch of my friends complaining about Chrome.

I told them the program is very busy uploading the entire contents of your hard 
disk to the mothership.

-a (Safari user)
___
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] build broken on macOS

[Andy Peters]

> On Dec 4, 2018, at 2:45 PM, Adam Wolf  wrote:
> 
> I think this is also fixed for me!

If you guys point me to a build recipe for macOS, I will set up nightly builds 
on one of my Mojave machines. I used to build Kicad until Adam started posting 
the nightlies but if it would help to have another builder, I’m down.

-a


___
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] MacOS dependencies and minimum version

[Andy Peters]

> On Nov 1, 2018, at 11:23 AM, Jeff Young  wrote:
> 
> My daughter just had to upgrade from 10.11 to 10.12 because something else 
> stopped working.  So we won’t be alone. ;)
> 
> (In any event, I encouraged her to keep more up-to-date.  There’s really not 
> much down-side on the Mac, although I’ll admit I usually don’t go all the way 
> to the latest.)

Another Mac user data point. Every Mac user I know waits a couple of weeks 
after a major release before installing it. Usually it’s to see if a particular 
piece of hardware is supported or not. Otherwise, everyone who can upgrade will.

My old Core2Duo iMac is still on 10.11 because it cannot be upgraded, and 
honestly that machine is too slow to do -anything- much less run Kicad.



> 
>> On 1 Nov 2018, at 16:53, Seth Hillbrand  wrote:
>> 
>> Hi All-
>> 
>> I think we should cease support for 10.11 at 5.0.x. MacOS upgrades are free 
>> and generally support Apple hardware back to 2012 [1].  While there may be 
>> some users who don't want to upgrade their operating system but do want to 
>> upgrade KiCad, that seems unnecessarily obstinate.
>> 
>> -Seth
>> 
>> [1] https://www.apple.com/macos/how-to-upgrade/#hardware-requirements
>> 
>> 
>> Am 2018-11-01 10:28, schrieb Adam Wolf:
>>> It looks like globally, about 15%.  I do not have any insight into how
>>> our users different from the global average.
>>> However, I did not hear a single complaint when we moved the bar from
>>> 10.9 to 10.11, following the rules of "current, plus the two previous
>>> releases" that Apple appears to use.
>>> There are three main reasons why I ask:
>>> 1) 10.14 was released in the middle of the 5 cycle.
>>> 2) there is always more work to be done and not having to dig into
>>> this means more time for the other things, like getting Python 3
>>> working in KiCad on macOS... But I also don't want to ruin a bunch of
>>> user's days either.
>>> 3) Now that it is easy for Mac devs to build and generate packages,
>>> there's more incentive to keep the build process simple and sane.  The
>>> macOS 4.x releases, I'm not joking, were probably only buildable on
>>> one computer on this planet, due to all the weird hand-crafted
>>> dependencies.  I am not saying that looking into or fixing this issue
>>> will immediately cause the Mac builds to be unreproducible and full of
>>> cruft, but it could end up that way and it's important to consider.
>>> Mainly, I want someone else to make this hard choice for me :p
>>> It might be an OK time to switch nightlies over, and see what sort of
>>> pushback we get?  I'm not sure.
>>> Adam
>>> On Thu, Nov 1, 2018, 8:03 AM Wayne Stambaugh >> wrote:
 Hey Adam,
 Do you have any idea how much of an impact that this will have on
 our
 macos user base?  If it's minimal, than I would say go ahead any
 move
 builds to 10.12.  If it's something like half of the users, then
 that is
 problematic.  I wouldn't want to have that big of hit to our user
 base.
 Anyone else have any thoughts on this.  I'm not a mac user so I
 don't
 have a good feel as to whether or not this is going to be an issue.
 Cheers,
 Wayne
 On 10/31/2018 4:40 PM, Adam Wolf wrote:
> Last night our automated builds that build on 10.11 both failed
 because
> the latest version of our dependencies no longer builds on 10.11.
> How much time should we put into this, rather than move the builds
 to
> 10.12 and leave the 10.11 users where they're at?
> Apple does not announce end of life, but if they follow what
 they've
> done in the past, there will be no more security updates for 10.11
 now
> that 10.14 is released.
> Adam
> __

___
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] Notice: GAL branch pushed to master

[Andy Peters]

> On Oct 9, 2018, at 5:59 AM, Tomasz Wlostowski  
> wrote:
> 
> On 09/10/18 14:34, Jeff Young wrote:
>> One of the model-railroad forums I’m on still has a max attachment 
>> resolution of 640 x 480.  My phone can do better than that. ;)
>> 
> 
> 
> Look at this Jeff:
> https://lists.launchpad.net/kicad-developers/msg20860.html
> 
> Next dev goal: make it work on 384x240 2 inch LCD display :)

Piffle! I want it to run on my iPad Pro! :)

-a


___
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] SPICE models and library symbols

[Andy Peters]

> On Aug 13, 2018, at 9:59 AM, Nhat Khai  wrote:
> 
> I may be wrong, but I feel embedded spice model with symbol library or .sch 
> file may be a wrong way. Instead treat spice model like footprint (using 
> spice syntax .cir file directly event better) to allow user directly modify 
> parameters passed into SUBCKT from GUI dialog like current Simulation GUI 
> right now. But if it done it right, I think it give user much more 
> flexibility, and more dynamic spice dialog that can covert all type of model 
> without adding more coding for KiCad. For example, read the "SUBCKT", and 
> allow user to change the value of parameters passed in of SUBCKT.


“Treat spice model like footprint.”

And that’s why the model callout _should_ be embedded in the library symbol.

If I place OPA1652AID onto my schematic, I want it to pull in the SOIC-8 
footprint. CvPCB is to be avoided. For the same reason, why should I need to 
specify the SPICE model after placing a generic op-amp symbol on the board, 
when I can place an OPA1652 symbol and have it already know what model to use?

-a
___
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] Spice simulation on macOS

[Andy Peters]

> On Aug 9, 2018, at 12:06 PM, Maciej Suminski  wrote:
> 
> Hi Andy,
> 
> On 08/09/2018 02:12 AM, Andy Peters wrote:
>> 
>>> On Mar 26, 2018, at 4:30 AM, Maciej Sumiński  
>>> wrote:
>>> 
>>> Would someone running nightlies on macOS test the Spice simulator? In
>>> particular, please simulate demos/simulation/sallen_key from our bundled
>>> demos and see if you get warnings "Unknown model type spice2poly -
>>> ignored". Testing both a self-built nightly and our official package [1]
>>> would be greatly appreciated.
>>> 
>>> Regards,
>>> Orson
>> 
>> 
>> The Sallen-Key demo circuit simulates as expected with the 5.0 release on 
>> macOS High Sierra.
> 
> Thank you for reporting back!
> 
>> One silly question: is there, or will there be, a standard location for 
>> Kicad to find SPICE models and libraries? The demo project has the model 
>> library (and the library for the op-amp symbol) in the project directory.
> 
> There are no standard paths for any library kind and Spice libraries are
> no exception. Are you asking for a dedicated environmental variable to
> set the Spice model path?

You’re right, I am asking for an environment variable that points to the 
models, in much the same way as the environmental variable for a 3D models path 
works.

I started to think about adding fields for Spice models to some component 
symbols, and then quickly realized that that can get ugly. For starters, 
footprint pin numbers and subckt pin assignments won’t match for most things. 
Then it became obvious that I need a separate library or libraries for symbols 
used for Spice. And that’s when I thought about where the models should live. 
In the same directory as the libraries?

-a
___
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] Spice simulation on macOS

[Andy Peters]

> On Mar 26, 2018, at 4:30 AM, Maciej Sumiński  wrote:
> 
> Would someone running nightlies on macOS test the Spice simulator? In
> particular, please simulate demos/simulation/sallen_key from our bundled
> demos and see if you get warnings "Unknown model type spice2poly -
> ignored". Testing both a self-built nightly and our official package [1]
> would be greatly appreciated.
> 
> Regards,
> Orson


The Sallen-Key demo circuit simulates as expected with the 5.0 release on macOS 
High Sierra.

One silly question: is there, or will there be, a standard location for Kicad 
to find SPICE models and libraries? The demo project has the model library (and 
the library for the op-amp symbol) in the project directory.

Thanks,
-a 
___
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] Aim macOS users at kicad-mac-builder and make building on macOS seem less scary

[Andy Peters]

On Jul 23, 2018, at 6:18 AM, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Attached is a docs patch.  Please let me know if it needs any tweaks
> or if you have any questions.
> <0001-Aim-macOS-users-at-kicad-mac-builder-and-make-buildi.patch>

I will try the kicad-mac-builder tonight.

-a



___
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

[Andy Peters]

On Jul 16, 2018, at 10:22 AM, Mark Roszko  wrote:
> 
> Yeathats what I proposed too.
> 
> Every program on Windows that needs side-by-side installs just
> versions both the config and install locations. Thats it.
> 
> EAGLE does it.
> Visual Studio does.
> Altium does it.
> CLion does it.
> All of Jetbrains other product do it.
> Microsoft Word does it
> Adobe does it.
> Python does it.
> MSSQL does it.
> 
> 
> No need for crazy launcher args and extreme actions such as doing
> something like RVM does
> 
> All that needs to be done, is find all instances of wxStandardPaths
> being used for config location.
> Replace it with a standard static function helper. In the helper, it
> appends a version number to the location.
> 
> Thats it. Done. No need to require users to understand command line to
> use a program.
> 
> It works for linux too.
> /home/user/.kicad/
> becomes
> /home/user/.kicad/5.1/

And on the Mac that would be

/Users/andy/Library/Application Support/kicad 

becomes

/Users/andy/Library/Application Support/kicad/5.1

and /Users/andy/Library/Preferences/kicad 

becomes 

/Users/andy/Library/Preferences/kicad/5.1

-a

___
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] Update footprint and get some weird DRC fails

[Andy Peters]

> On Jul 14, 2018, at 7:30 PM, Seth Hillbrand  wrote:
> 
> That's valid.  Would you mind submitting the issue to our bug tracker and 
> we'll fix that in 5.0.1?  I have a fix for the non-copper connectivity issue 
> queued but we should address the array pad numbering issue as well.  If 
> memory serves, there are a few issues with that dialog outstanding...
> 
> -S

Bug report with overly-verbose description is filed at 
https://bugs.launchpad.net/kicad/+bug/1781760

Thanks!

FWIW, for this I just wanted to generate a Gerber file for the paste mask layer 
so I could get a correct stencil made. The board was fabbed and I had stencils 
made, and the stencil had just the one big hole for the exposed pad (not good). 
That’s why I edited the footprint in place. If the board needs a respin, I’ll 
use an updated footprint from my library.

-a




> Am Sa., 14. Juli 2018 um 18:26 Uhr schrieb Andy Peters :
> 
> > On Jul 14, 2018, at 3:33 PM, Seth Hillbrand  wrote:
> > 
> > Hi Andy-
> > 
> > You don't provide enough information to help you here.  You'll need to show 
> > a larger image of your board with other layers enabled and, ideally set 
> > with some transparency so that we can see what's happening.
> > 
> > Connectivity _only_ applies to copper.  So the paste-only pads shouldn't 
> > have any connections unless you also made them copper.  Did you follow 
> > Rene's instructions on the user forum?
> 
> "Connectivity _only_ applies to copper.” Yes, that’s true, and that’s what 
> baffled me. These pads were explicitly set to Layer Copper as None, only the 
> F.Paste layer was checked.
> 
> I did follow Rene’s instructions, except for one point. I created one of the 
> paste-mask-only pads, made sure it had no pad number and no net name, placed 
> it, and then used the array feature to create the needed 3x3 array. His 
> recommendation is to just duplicate pads. 
> 
> And that’s what broke it. It assigned pad numbers to all of the pads. The pad 
> numbers assigned are like such:
> 
> +__+__+__+
> |33|23|13|
> +__+__+__+
> |32|22|12|
> +__+__+__+
> |31|21|11|
> +__+__+__+
> 
> and the pads inherited the net name associated with the pad number, since 
> those pad numbers were already on the footprint.
> 
> When no copper layer is indicated in the pad, then the pad number vanishes 
> from the display. After creating the array, I didn’t see any pad numbers, so 
> I thought that all was well, and did not look at each of the pads to see 
> that, yes, indeed, they _were_ assigned pad numbers, and as such inherited 
> the pad’s net name.
> 
> I can see why the array function would create pad numbers for footprint pins 
> which have a copper layer. It surprised me that it created them for these 
> aperture pads, especially since the pad from which the array was created had 
> no number. Rene does say that "Using the array function is not really 
> possible in this case as it does not allow us to assign no pad number to the 
> resulting pads,” but I didn’t appreciate what that actually meant.
> 
> The DRC wants the user to connect a trace to a non-existent copper part of a 
> pad, and that’s not right.
> 
> Could the array function be modified such that if the original pad has no 
> number, then it should not assign pad numbers to the cloned pads?
> 
> -a
> 
> 
> > -S
> > 
> > Am Sa., 14. Juli 2018 um 14:00 Uhr schrieb :
> > I'm on yesterday's unified package of 5.0.0 rc3 on a mac.
> > 
> > Following my question about why the footprint editor wouldn't let me create 
> > an arbitrary shape for a solder-paste-mask pad, which was not actually 
> > answered but the workaround was actually what I wanted (and I figured out 
> > what I was doing wrong, the pad shape has to be set to Custom), I went and 
> > edited my footprint in place to add the paste-mask-only pads (no copper 
> > layer). They're called aperture pads, I believe, and the footprint looks as 
> > shown in QFN-paste.png.
> > 
> > Then I save it back to the layout, and I get a few connection errors, on a 
> > board which was fully routed. The connection errors refer to traces which 
> > now want to connect to those new aperture pads. I don't know why this 
> > should happen, and I don't know how to fix it! It seems like the 
> > connectivity is borked. I know about the change in the clearances (from 
> > http://kicad-pcb.org/blog/2018/05/Mask-Clearance-Generation-Changes/) but 
> > that doesn't seem to apply here, as it's a connectivity issue. This is 
> > shown in QFN-DRC-fail.png.
> > 
> > I'm willing to believe that I did something wrong, but what!
> > 
> > Thanks ... 



___
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] Update footprint and get some weird DRC fails

[Andy Peters]

> On Jul 14, 2018, at 3:33 PM, Seth Hillbrand  wrote:
> 
> Hi Andy-
> 
> You don't provide enough information to help you here.  You'll need to show a 
> larger image of your board with other layers enabled and, ideally set with 
> some transparency so that we can see what's happening.
> 
> Connectivity _only_ applies to copper.  So the paste-only pads shouldn't have 
> any connections unless you also made them copper.  Did you follow Rene's 
> instructions on the user forum?

"Connectivity _only_ applies to copper.” Yes, that’s true, and that’s what 
baffled me. These pads were explicitly set to Layer Copper as None, only the 
F.Paste layer was checked.

I did follow Rene’s instructions, except for one point. I created one of the 
paste-mask-only pads, made sure it had no pad number and no net name, placed 
it, and then used the array feature to create the needed 3x3 array. His 
recommendation is to just duplicate pads. 

And that’s what broke it. It assigned pad numbers to all of the pads. The pad 
numbers assigned are like such:

+__+__+__+
|33|23|13|
+__+__+__+
|32|22|12|
+__+__+__+
|31|21|11|
+__+__+__+

and the pads inherited the net name associated with the pad number, since those 
pad numbers were already on the footprint.

When no copper layer is indicated in the pad, then the pad number vanishes from 
the display. After creating the array, I didn’t see any pad numbers, so I 
thought that all was well, and did not look at each of the pads to see that, 
yes, indeed, they _were_ assigned pad numbers, and as such inherited the pad’s 
net name.

I can see why the array function would create pad numbers for footprint pins 
which have a copper layer. It surprised me that it created them for these 
aperture pads, especially since the pad from which the array was created had no 
number. Rene does say that "Using the array function is not really possible in 
this case as it does not allow us to assign no pad number to the resulting 
pads,” but I didn’t appreciate what that actually meant.

The DRC wants the user to connect a trace to a non-existent copper part of a 
pad, and that’s not right.

Could the array function be modified such that if the original pad has no 
number, then it should not assign pad numbers to the cloned pads?

-a


> -S
> 
> Am Sa., 14. Juli 2018 um 14:00 Uhr schrieb :
> I'm on yesterday's unified package of 5.0.0 rc3 on a mac.
> 
> Following my question about why the footprint editor wouldn't let me create 
> an arbitrary shape for a solder-paste-mask pad, which was not actually 
> answered but the workaround was actually what I wanted (and I figured out 
> what I was doing wrong, the pad shape has to be set to Custom), I went and 
> edited my footprint in place to add the paste-mask-only pads (no copper 
> layer). They're called aperture pads, I believe, and the footprint looks as 
> shown in QFN-paste.png.
> 
> Then I save it back to the layout, and I get a few connection errors, on a 
> board which was fully routed. The connection errors refer to traces which now 
> want to connect to those new aperture pads. I don't know why this should 
> happen, and I don't know how to fix it! It seems like the connectivity is 
> borked. I know about the change in the clearances (from 
> http://kicad-pcb.org/blog/2018/05/Mask-Clearance-Generation-Changes/) but 
> that doesn't seem to apply here, as it's a connectivity issue. This is shown 
> in QFN-DRC-fail.png.
> 
> I'm willing to believe that I did something wrong, but what!
> 
> Thanks ... 
> 
> 


___
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] "aperture" pads and custom shape primitives.

[Andy Peters]

> On Jul 9, 2018, at 10:24 AM, Seth Hillbrand  wrote:
> 
> Hi Andy-
> 
> In the footprint you mention, note that there are many paste-only pads (see 
> attached image).  To follow Silicon Labs' recommendation, simply create your 
> exposed pad with no paste layer and add multiple paste-only pads in the 
> geometry you desire.

I must have pulled an older version of that footprint, as that one has the 
paste-mask cut-outs and the one I used didn't. I see how that works. No need 
for a pad number, just create a pad with no copper layer and only the 
paste-mask layer and place as many as needed. Perfect.


> Note that there is a tutorial on the user forum 
> (https://forum.kicad.info/t/tutorial-how-to-make-a-footprint-from-scratch/11092/1)
>  that covers this.

Thanks for the link — I had not seen that.


> 
> -S
> 
> Am Mo., 9. Juli 2018 um 10:00 Uhr schrieb Andy Peters :
> I followed the discussion about “new non-copper pad paste and mask 
> clearances,” hoping that it would suggest how to do something. Maybe I’m 
> missing it.
> 
> I’m using a part in a QFN-44 package with the exposed pad. The library guys 
> have created this footprint in 
> https://kicad.github.io/footprints/Package_DFN_QFN and it’s the 
> QFN-44-1EP_7x7mm_P0.5mm_EP5.2x5.2mm guy.
> 
> The recommendation from the chip vendor (Silicon Labs, but I’m sure it’s a 
> standard recommendation) is for solder paste stencil to have a “3x3 array of 
> 1.25 mm square openings on 1.80 mm pitch for the center ground pad.” The 
> library footprint doesn’t have this stencil stuff, it’s just one big open 
> area for solder paste. And I built a board with this footprint and now know 
> why the recommendation is for the smaller openings in the stencil.
> 
> I figured this would be a good use of the “Custom Shape Primitives” feature 
> in the footprint editor. But I can’t figure out how I’m supposed to enter 
> anything into this dialog. The buttons are all grayed out. See:
> 
> 
> 
> 
> This is with yesterday’s “testing” build.
> 
> Am I missing something? Is this feature not yet implemented?
> 
> Application: kicad
> Version: (5.0.0-rc3-dev-5-gfd7f3b8), release build
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
> Platform: Mac OS X (Darwin 17.6.0 x86_64), 64 bit, Little endian, wxMac
> Build Info:
> wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
> Boost: 1.61.0
> OpenCASCADE Community Edition: 6.8.0
> Curl: 7.43.0
> Compiler: Clang 7.3.0 with C++ ABI 1002
> 
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=ON
> USE_WX_OVERLAY=ON
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=OFF
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_USE_OCC=OFF
> 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

Re: [Kicad-developers] macos rc3

[Andy Peters]

> On Jul 6, 2018, at 6:38 PM, Adam Wolf  wrote:
> 
> Hi folks!
> Many people may not know but there were *extensive* changes made to
> the macOS packaging since V4.  After we all get some more sleep I'll
> write up more on the details. :)
> 
> The RC3 build is ready for *developer* and *superfan* testing.
> 
> http://downloads.kicad-pcb.org/osx/testing/kicad-unified-5.0.0-rc3-2.dmg 
> 
Hi, Adam,

I get a 404 error when clicking on that link.

-a



___
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] Eeschema 6.0 file format / data structure

[Andy Peters]

> On Mar 29, 2018, at 3:32 PM, Wayne Stambaugh  wrote:
> 
> As promised, attached are the schematic and symbol file library file formats. 
>  Please note, they are preliminary and need some updates. There was a pretty 
> in depth discussion a while back on the mailing list which you should take a 
> look at so we do not rehash the same discussion unless there is a reason.

One quick comment about the “atomic parts” section in the library format 
document. It calls out 

 (footprint “14-SOP”)

Should we assume the footprint must also include the library from which that 
footprint is pulled? That is, this line would more likely be:

(footprint “Package_SOP:14-SOP”)

and of course Package_SOP has to be in the user’s footprint library table.

thanks,
-a
___
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] Eeschema Subsheets

[Andy Peters]

> On Mar 28, 2018, at 7:34 PM, Seth Hillbrand  wrote:
> 
> ​Hi All-
> 
> I'm working on a bug in renaming sub-sheets.  In testing the fix, I've run up 
> against a set of conflicting paradigms for how subsheets are handled.  I'd 
> like some feedback on how we expect to handle the subsheets.
> 
> Either: 
> 1) we treat them as actual objects such that renaming the sheet's filename 
> renames the file on the computer but keeps the contents unchanged​ or
> ​2) we treat them as links to the objects and renaming the filename​ of the 
> subsheet doesn't change the subsheet's file but instead just changes which 
> file is referenced.
> 
> Right now, we do both depending on whether there is an existing file and more 
> than one reference to the subsheet or not.  This is confusing as it is 
> difficult to determine when an operation will result in actually overwriting 
> an existing file and thereby losing data.
> 
> I'm inclined to make all actions (2).  This would allow a subsheet file to 
> become unlinked from the project if you change the filename referencing it 
> but would not allow overwriting subsheets on disk.
> 
> Does anyone feel strongly that (1) is the correct action?  

If the project is in source-code control, then Kicad renaming a file that’s 
under that control breaks things. ___
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] Proposed roadmap changes

[Andy Peters]

On Mar 8, 2018, at 9:21 AM, Ouabache Designworks  wrote:
> 
> Why don't we run PCB layout on the schematic file and let it call the 
> netlister program every time it runs. This is a simpler process flow with 
> fewer cases where you make the user jump through hoops to get something done.

This makes a ton of sense. When working on a layout, it must match the 
schematic. 

(In the past, we had a rule. When a layout is complete, generate a new netlist 
from the schematic and import it into the layout. If layout reports no changes 
are necessary, the two are in sync and all is well.)

The netlist is just ephemeral, anyway; once it is imported into the layout it’s 
no longer necessary. The netlist is a vestige of the days when PCB CAD packages 
were a collection of disparate programs.

But … 

This action should be one way, that is, changes in the schematic should not 
force an automatic update of the layout. Consider: you made some updates to the 
schematic, and you’d like your colleagues to review it before you commit to it. 
They look at it, make suggestions, which might include not making the changes. 
If the layout automagically updated from your unreviewed changes, then you’d 
have to undo those changes in the layout.

This means that when you open the layout, it can notice that the schematic has 
changed and ask the user if it should be updated to sync with those changes. 
Because the answer might well be no, I am not ready to do that yet. Maybe you 
just want to look at the layout as it is, for whatever reason.

-a
___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 7, 2018, at 9:22 PM, Ouabache Designworks  wrote:
> 
> 
> If you are doing a PCB with a FPGA on it then you really want that FPGA 
> designer to be using kicad to design their padring. Kicad could fill this 
> niche and it would make your job a lot easier.

If only it was that simple. FPGA (and to some extent, microcontroller) pin 
swapping during layout is a holy grail. The problem is that it’s not as simple 
as it seems. The layout person cannot arbitrarily assign pinouts without 
understanding the specific chip I/O architecture and rules and also 
understanding the FPGA design. Our layout guy is literally on the other side of 
a low wall from me, and I hear his cursing about pin selection all the time!

Some examples of why this is not so straightforward.

a) The obvious one is clock inputs. They have to be on specific pins if one 
wants the best routing from the pin to the internal clock buffer, and if one 
wants to take advantage of advanced clocking features (DLLs, PLLs, input 
delays).

b) FPGAs have rules about differential pairs. Pins on specific banks are 
differential inputs or outputs only, pins on other banks can be both. Some have 
internal termination on certain pairs, others don’t. Bank I/O voltage is 
important, so you can’t move the pair to another bank with a different supply.

c) Mind the bank supplies for your signals. You can’t put a 3.3 V signal on a 
2.5 V bank. The schematic and layout tools don’t have a “net type” attribute 
that says, “This is an LVCMOS33 signal” which would bark at you if you tried to 
connect it to a pin that had an LVCMOS25 type attribute. It would be great if 
such a feature existed. 

d) Regional clock inputs require that all of the things that might use that 
clock be constrained to be in the clock region — and the region and the I/O 
bank don’t necessarily map to each other. And the layout person might not 
realize that a pin even needs to be in a specific region. And how would he know 
that a specific pin is in the right region?

e) Lattice MachXO2 (to use a recent example) has limitations on the total 
output current for pins on a bank. It’s not straightforward. The good news is 
that their fitter tool complains if the bank is overloaded. The less good news 
is that there’s no obvious way to communicate that information to the layout. 
Schematic and layout don’t know about pin loading, for example. While pin 
loading could be (and in some high-end schematic tools, is) part of the DRC, 
this particular Lattice constraint would need to have some code that does the 
test.

f) Specialist features such as gigabit serializers and deserializers, memory 
interfaces, and the like, simply cannot be swapped.

An obvious house rule is one we have at the day job: before a PCB is released, 
the FPGA tools are run on the design to ensure that you don’t get timing 
screw-ups and you don’t have illegal pin locations. The problem, of course, is 
that you need to have enough of the FPGA design done before you can do that, 
and there’s always someone with a schedule demanding that the board be sent out 
for fab before you’ve even started simulating your design.

So if we’re talking pie-in-the-sky wish-list: Kicad should have a plug-in that 
can read and parse FPGA constraint files and “know” the FPGA symbol pin names 
and attributes. And after the swapping, which will automatically update the 
schematic, and which has ERC of some sort enforced, Kicad will update the 
constraint file with the new pin assignments.

-a
___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 7, 2018, at 3:04 PM, Ouabache Designworks  wrote:
> 
> 
> 
> On Mon, Mar 5, 2018 at 9:57 AM, Jon Evans  > wrote:
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>  
> 
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0
> 
> -Jon
> 
> 
> 
> 
> My wishlist:
> 
> Follow the unix philosophy. All programs must do one thing and do it well. 
> You solve complex problems by chaining simple tools together. If you don't 
> then your tool becomes bloated and hard to use and maintain. EEschema is 
> heading down this path and we need to strip it down to EEschema Lite and put 
> the ancillary features in their own programs.

What features of EESchema are “core” and what are “ancillary?”

-a___
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] Proposed roadmap changes

[Andy Peters]

On Mar 7, 2018, at 11:46 AM, Seth Hillbrand <seth.hillbr...@gmail.com> wrote:
> 
> You should take a look at Mitja Nemec's action plugin here: 
> https://github.com/MitjaNemec/Kicad_action_plugins
> 
> I think the replicate layout covers a lot of the functionality you are 
> looking for.

Wow, yeah, I will try that! 

> -S
> 
> 2018-03-07 10:25 GMT-08:00 Andrey Kuznetsov <kandre...@gmail.com>:
> Not sure how you would turn this into an effortless feature, but a few months 
> ago I’ve designed just that, replicated channels using the same subsheet, on 
> layout I did it once, then copy pasted and manually renamed each component 
> based on each channel number component.
> 
> On Wed, Mar 7, 2018 at 8:42 AM Andy Peters <de...@latke.net> wrote:
> 
> > On Mar 5, 2018, at 10:57 AM, Jon Evans <j...@craftyjon.com> wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc, I've 
> > had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play with; 
> > I'm happy to send patches against the official roadmaps if get some buy-in 
> > for this.
> >
> > Feel free to comment (either directly on the doc or by email) with thoughts 
> > on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema 
> > for 6.0, with changes to other parts of the software basically being 
> > "whatever people have time left over for".  Everything else has been bumped 
> > to 7.0
> 
> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,” like 
> the Altium feature. Consider a multi-channel design where you have to 
> replicate a layout several times. It would be nice to define the channel in, 
> say, a hierarchical subsheet, and the layout knows that it should replicate 
> the work you do for one channel across the others.
> 
> I realize that this is a completely non-trivial thing to implement, and 
> further I recall some discussion about this but nobody had any real good 
> ideas about how to do it.
> 
> -a
> 


___
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] Proposed roadmap changes

[Andy Peters]

On Mar 7, 2018, at 11:25 AM, Andrey Kuznetsov <kandre...@gmail.com> wrote:
> 
> Not sure how you would turn this into an effortless feature, but a few months 
> ago I’ve designed just that, replicated channels using the same subsheet, on 
> layout I did it once, then copy pasted and manually renamed each component 
> based on each channel number component.

I will argue against manual intervention and manual renaming of anything. The 
possibility of error goes _way_ up. Who wants to rename all of the parts on 16 
channels of analog preamp/ADC driver/ADC? 

-a



> 
> On Wed, Mar 7, 2018 at 8:42 AM Andy Peters <de...@latke.net 
> <mailto:de...@latke.net>> wrote:
> 
> > On Mar 5, 2018, at 10:57 AM, Jon Evans <j...@craftyjon.com 
> > <mailto:j...@craftyjon.com>> wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc, I've 
> > had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play with; 
> > I'm happy to send patches against the official roadmaps if get some buy-in 
> > for this.
> >
> > Feel free to comment (either directly on the doc or by email) with thoughts 
> > on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >  
> > <https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#>
> >
> > Basically what I am proposing is to put most of the energy into Eeschema 
> > for 6.0, with changes to other parts of the software basically being 
> > "whatever people have time left over for".  Everything else has been bumped 
> > to 7.0
> 
> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,” like 
> the Altium feature. Consider a multi-channel design where you have to 
> replicate a layout several times. It would be nice to define the channel in, 
> say, a hierarchical subsheet, and the layout knows that it should replicate 
> the work you do for one channel across the others.
> 
> I realize that this is a completely non-trivial thing to implement, and 
> further I recall some discussion about this but nobody had any real good 
> ideas about how to do it.
> 
> -a
___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> 
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0

I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,” like 
the Altium feature. Consider a multi-channel design where you have to replicate 
a layout several times. It would be nice to define the channel in, say, a 
hierarchical subsheet, and the layout knows that it should replicate the work 
you do for one channel across the others.

I realize that this is a completely non-trivial thing to implement, and further 
I recall some discussion about this but nobody had any real good ideas about 
how to do it.

-a



___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> 
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>  
> 
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0

I’m not sure where it fits into the roadmap, but the main EESchema feature I’d 
like to see implemented is the embedding of schematic symbols into the 
schematic sheet, in the same way that footprints are part of the kicad_pcb file.

Also the whole idea of renumbering the reference designators in a layout to be 
geographical, and then backannotating the designators to the schematic. (A guy 
can dream ..)
-a

___
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] [fun feature request] Create PCB from schematic with one click :)

[Andy Peters]

> On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh  wrote:
> 
> I was thinking one level of abstraction higher where I just input my
> design requirements and it spits out a schematic, full simulation to
> match the design requirements, and a completed board layout.  That would
> make my job a *lot* easier. ;)

Maybe it can do my FPGA design for me, and also write firmware for the ARM 
processor too! Why am I doing all of this hard work when I could be drinking 
coffee and reading the New York Times?

> All kidding aside, I was told by a very highly skilled board designer
> not to waste our time with auto-routers because no one actually uses
> them except for the simplest designs with lots of free board space and
> few or no routing restrictions.  This is someone who uses Altium in his
> day job and has laid out far more boards than I have.  

At the previous day job, we did VME and CompactPCI single-board computers, and 
the layout people took advantage of full-up Specctra autorouting. The designs 
had a lot of wide parallel buses and suchlike which could be autorouted, but 
there was still plenty of stuff on those boards which needed to be routed 
manually. And setting up constraints for the autorouter was still a couple of 
days work.

At the current job everything is smaller. Each product has multiple boards that 
need to connect correctly. Boards are mixed signal, they have power supply 
parts, there are connectors that poke through the enclosure, etc etc etc and 
suffice it to say we never autoroute. Assisted routing, like the Kicad 
push-and-shove, and Altium’s “bus routing” (a feature I’d like to see in Kicad, 
for sure!) goes a long way.


> I'm guessing auto-routers appeal to hobbyists rather than professionals. 

How many questions on forums do you see from hobbyists asking about how to 
autoroute, or wondering if the results from the autorouter are good?

-a
___
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] MacOS Packaging Question

[Andy Peters]

The macOS nightlies still use “old” libraries. By that I mean, for example, 
Housings_SOIC instead of Packages_SOIC and the like.

-a

> On Mar 3, 2018, at 7:53 PM, Nick Østergaard  wrote:
> 
> This is the current scripts used for the current nightlies for macos
> https://github.com/wayneandlayne/KiCadMacOSPackaging.git 
> 
> 
> 2018-03-04 0:37 GMT+01:00 Rene Pöschl  >:
> On 03/03/18 23:32, Seth Hillbrand wrote:
> ​In the current nightly MacOS builds, we package the applications, symbols 
> and 3d models but no footprints.
> 
> Is this an oversight?
> 
> -S​
> 
> 
> 
> This might be because in kicad 4 the footprints where downloaded on demand 
> via the github plugin.
> With the new library setup (single repository for all footprints) this is no 
> longer possible.
> 
> I assume some packages for other operating systems might have a similar 
> problem
> 
> ___
___
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] Rework footprint selection filtering to improve behavior

[Andy Peters]

> On Mar 2, 2018, at 10:28 AM, Andrzej Wolski  wrote:
> 
> Jon,
> 
> I probably didn't express myself clearly. What I mean is a situation when 
> *only* enabled layer if F.Paste and then you disable "Pads Front". Now 
> nothing is visible on the board, but footprints are still selectable.
> 
> In other words, when no single item belonging to footprint is visible, 
> footprints should not be selectable.
> 
> Do you still disagree with me?

I agree with Andrzej. This is the crux of my bug report.

But I understand what Jon is saying, and it doesn’t contradict. If the _pads_ 
(for example) are invisible, but say the silkscreen is visible, then the 
footprint _should_ be selectable.

That, I think, is the difference between layer visibility and item visibility. 
All of the layers could be visible, but if I disable Footprints Front, then 
everything associated with all top-layer footprints vanishes and none of the 
footprints can be selected. That’s the proper operation.

The converse of that is if I leave Footprints Front visibility enabled, and 
then I go and disable all of the layers associated with front footprints, like 
I did in my bug report case (disable all layers except Cmts.User), I am still 
able to select all of the invisible footprints. That’s not correct (IMHO).

-a


> 
> Andrzej
> 
> W dniu 2018-03-02 o 15:42, Jon Evans pisze:
>> Hi Andrzej,
>> 
>> This was my intention, which is why I said I was prepared for other people 
>> to have other opinions :-)
>> 
>> I think that you should still be able to select footprints even if the 
>> "front pads" is hidden from layers like the paste layer, *unless* you are in 
>> high contrast mode.
>> 
>> -Jon
>> 
>> On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski > > wrote:
>> I've tried this patch, and there is a small issue: if you have only eg front 
>> paste layer enabled and front pads are hidden, footprint is still selectable.
>> 
>> Andrzej
>> 
>> 
>> W dniu 2018-02-27 o 04:11, Jon Evans pisze:
>>> This patch changes the selection logic for footprints to fix a reported 
>>> issue[1] and to make the behavior more logical to me.
>>> 
>>> I know that correct selection behavior is something of a personal 
>>> preference, so I'm ready to be flamed :-)
>>> 
>>> The new behavior:
>>> 
>>> A footprint may be selected if:
>>> 1) The corresponding "Footprints" switch is on in the Items tab, AND
>>> 2) One or more of the layers that the footprint draws on is visible
>>> 
>>> This means that if all of the layers are turned off, footprints are not 
>>> selectable (fixes the bug), but it also means that now footprints can be 
>>> selected if any draw layers are visible (for example, if you have only 
>>> F.Mask enabled, you can select a footprint that has solder mask and is on 
>>> the front layer).
>>> 
>>> Before anyone complains, this is only if high-contrast mode is turned OFF.  
>>> When it is on, you can still only select items that *only* exist on that 
>>> layer (to make moving silkscreen around easier, for example)
>>> 
>>> Even though this adds some more for-loops to selection filtering, I have 
>>> not noticed any performance hits on some selection of large boards that I 
>>> tested.  More testing is welcome.
>>> 
>>> [1] https://bugs.launchpad.net/kicad/+bug/1751960 
>>> 
>>> 
>>> -Jon
>>> 

___
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] Mac HighDPI performance

[Andy Peters]

> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand  wrote:
> 
> Andrey-
> 
> I'm moving this to a new thread so that we don't conflate the OpenMP 
> discussion with this.
> 
> Can you test running Kicad with the "Open in Low Resolution" mode enabled?  
> You can activate this by choosing "Get Info" on the main KiCad application 
> and checking the option that says "Open in Low Resolution".  You may need to 
> do the same for the other applications (Eeschema, pcbnew, etc) as well.

testing on my 2017” touch-bar MBP … 

Good g-d, low-res mode looks fuzzy and weird!

I don’t notice any specific differences in EESchema performance. Maybe my 
schematic isn’t busy enough? I’m a fan of using more smaller sheets with less 
info on each than one big sheet with everything.

I know, anecdote is not evidence.

-a


> 
> -Seth
> 
> ​​2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
> Hi,
> 
> So for now I've had a chance to test the motherboard project on my Retina 
> macbook display.
> eeschema: horrible zoom, feels like elastic band zoom and I have all scroll 
> wheel accelerations and similar disabled, zoom response is super laggy, 
> cannot work like this, will need to make schematics on windows.
> pcbnew by order of slowness:
> legacy - pretty slow, zoom lag is major, boo boo
> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom 
> responsiveness
> 
> I'll report tomorrow on 5K LG display.
> ​


___
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] Alternative presentation of Symbol properties

[Andy Peters]

> On Mar 1, 2018, at 5:29 AM, Jeff Young  wrote:
> 
> What do you guys think of this for displaying / editing symbol fields:
> 
> 

Don’t the text items have thickness and width attributes, not just one “size?”

-a
___
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] Oversight in pcbnew footprint properties dialog

[Andy Peters]

Nowhere in the pcbnew footprint properties dialog does it say the name (and 
source library) of the footprint whose properties are being displayed! This is 
a weird oversight. 

This little bit of info is useful! For example, my DRC check complained about 
“footprint C7 has malformed courtyard.” OK, I look at the footprint’s 
properties to see what it’s called (because who can remember) and it’s not in 
that dialog.

To be fair, when a footprint is selected, its relevant details are shown in the 
status bar on the bottom of the screen, and that includes the footprint name. 
But still …

This is with a current nightly build.

-a
___
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] 3D Viewer "Render current view using Raytracing" is ludicrously slow

[Andy Peters]

On Feb 27, 2018, at 9:09 PM, Andrey Kuznetsov <kandre...@gmail.com> wrote:
> 
> Frankly, everything on MacOS is slow in KiCad from 3D to layout to schematic, 
> panning and zooming is horrendous.
> It's probably been 2 months since I tried anything on MacOS, and there have 
> been more than a few improvements committed, but I'm not holding my breath. 
> Especially since schematic isn't using OpenGL and will be re-written for v6.
> 
> I'll try to check the nightlies tomorrow to see how well it works on my 5K 
> display as well as just on the Retina display.

I must disagree. I haven’t had any complaints about performance on my Macs, 
except for that raytracing issue. The laptop is 2017 15” Retina with quad core 
i7 at 2.8 GHz, 16 GB SDRAM and the Radeon 555 graphics, and my desktop is a 
late 2012 2.3 GHz quad Core i7 mini with 16 GB and the standard Intel HD 
Graphics 4000 (the last of the quad core i7 minis!). The desktop drives a 24” 
1920 x 1200 display and a 20” 1680 x 1050 display, and seriously, I cannot 
complain about performance. One board I’m finishing up now is a four-layer job 
that’s reasonably packed with parts.

To be fair, I haven’t done a day-job board (ten layers, big BGAs and such) with 
Kicad. Yet.

-a



> 
> On Tue, Feb 27, 2018 at 3:21 PM, Andy Peters <de...@latke.net 
> <mailto:de...@latke.net>> wrote:
> This is probably way low on the list of priorities …
> 
> On a 2017 MacBook Pro (Retina, touch bar, 16 GB RAM, with the Radeon 555 
> graphics), the "Render current view using Raytracing" is ludicrously slow, as 
> in it takes about a minute to render a “simple” design (front panel thing 
> with LEDs and buttons).
> 
> I admit that I didn’t know what that blue cube in the 3D viewer’s toolbar was 
> for. I guess it’s really a tesseract.
> 
> Anyway, it re-draws the display and then when you zoom or pan it reverts back 
> to the original rendering (which is quite fast).
> 
> -a
> 
> 
> 
> Application: kicad
> Version: (5.0.0-rc2-dev-26-g0d794b2), release build
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
> Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
> Build Info:
> wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
> Boost: 1.61.0
> Curl: 7.43.0
> Compiler: Clang 7.3.0 with C++ ABI 1002
> 
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=ON
> USE_WX_OVERLAY=ON
> 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 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-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

[Kicad-developers] 3D Viewer "Render current view using Raytracing" is ludicrously slow

[Andy Peters]

This is probably way low on the list of priorities …

On a 2017 MacBook Pro (Retina, touch bar, 16 GB RAM, with the Radeon 555 
graphics), the "Render current view using Raytracing" is ludicrously slow, as 
in it takes about a minute to render a “simple” design (front panel thing with 
LEDs and buttons).

I admit that I didn’t know what that blue cube in the 3D viewer’s toolbar was 
for. I guess it’s really a tesseract.

Anyway, it re-draws the display and then when you zoom or pan it reverts back 
to the original rendering (which is quite fast).

-a



Application: kicad
Version: (5.0.0-rc2-dev-26-g0d794b2), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
Boost: 1.61.0
Curl: 7.43.0
Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
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] pcbnew selection oddness

[Andy Peters]

This uses last night’s nightly (macOS).

I imported a DXF file into the Cmts.User layer (nothing else is on it) and I 
need to move it into a specific location. Since there is no “group all of this 
stuff into one thing” feature (which I admittedly hadn’t thought about until 
just now), my imported thing is a bunch of lines and arcs. 

To move it, I turned off all of the layers except Cmts.User and used the mouse 
to draw a selection box around the imported lines. But! The selection includes 
all sorts of other stuff which was invisible. Checking the “Items” visibility I 
see that most things are selected — Footprints, References, Pads, Tracks, Vias, 
Holes. But since their layers are turned off, they’re not visible. (which is 
the expected result.)

Shouldn’t the block-select logic select only stuff which is actually visible? 
That is, if the layer is not visible and I don’t see a thing, I should not be 
able to select that thing, period.

(Aside: is there any way to combine things like a mechanical outline DXF 
imported into an auxiliary layer? I designed a small board that goes behind a 
front panel and I went to check whether it would actually fit, and realized 
that while I can import the panel outline, moving it as one unit, with an 
anchor point like any regular footprint, doesn’t work.)

Thanks, and I have to say that Kicad is really working out here. The two boards 
I want to fab this week are my 9th and 10th Kicad designs.


Application: kicad
Version: (5.0.0-rc2-dev-16-g319b7cf), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
Boost: 1.61.0
Curl: 7.43.0
Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
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

Re: [Kicad-developers] [PATCH] Fix Gerber job file bug and crash issue on MacOS

[Andy Peters]

On Feb 26, 2018, at 12:13 PM, Jon Evans <j...@craftyjon.com> wrote:
> 
> Re-sending these since they may have gotten lost in the other thread.
> These fix some bugs Andy Peters found on GerbView MacOS.

Thanks for the quick fix. I will download a nightly build to verify. (I kinda 
gave up on building Kicad, long story, the nightlies work for me.)
___
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] gerbview on macOS path issue for job files

[Andy Peters]

On macOS High Sierra, latest updates.

I want to send boards out to fab and I’m checking Gerbers. When generating the 
files, I check the “create job file” option.

I launch GerbView from the Kicad project manager. From the GerbView menu, I 
choose “Load Gerber Job File.” The File Open dialog box starts in my project’s 
directory (good!). The Gerbers are in the Gerber/ subdirectory of my project, 
so I mouse to that, and select the .gbrjob file. 

Upon opening, I’m greeted with a Warning message box:

File “/Applications/Kicad/myproj-F.Cu.gtl” not found.

Click OK, GerbView crashes and generates a report to send to Apple. This is 
repeatable.

I look in the job file. There are no paths for any of the Gerber files. So why 
does GerbView assume that the files are in the application installation 
directory?

GerbView will happily open individual files. But the job file parsing logic is 
broken.

-a


Application: kicad
Version: (5.0-dev-4161-g9483960), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
Boost: 1.61.0
Curl: 7.43.0
Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
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

Re: [Kicad-developers] Inc/DecAlpha code review patch

[Andy Peters]

> On Feb 23, 2018, at 6:05 AM, Jeff Young  wrote:
> 
> This patch addresses code review comments to the Inc/DecAlpha bug fix.
> 
> <0004-Address-inc-decAlpha-bug-fix-code-review-comments.patch>

Completely off the topic, but when I saw the subject line, I thought, “Kicad 
runs on the DEC Alpha processor??”

-a (showing his age)
___
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] Rearrange Render panel of PcbNew layer widget; add spacers

[Andy Peters]

On Feb 22, 2018, at 10:48 AM, Jon Evans <j...@craftyjon.com> wrote:
> 
> The tradeoff there is that other users will have a workflow that involves 
> setting up a nice set of layers displayed/hidden for working on a board, and 
> want to switch to another set for another board.
> Maybe saving in the app preferences is okay in the short term, but I think 
> eventually it's best to be able to save custom display states (including 
> layer visibility and other options) in the project.
> Other software has solved this problem by making multiple project files, and 
> having the idea of the "base" project file and the "user settings" project 
> file, with the latter explicitly not going in to version control.
> -Jon

A “dot” file for this sort of preference, which in Unix is hidden by default 
(gotta do an ls -a to see it), seems to me a good compromise. Upon creation of 
the project, a .settings file is created from reasonable defaults (a system 
default? user default?). Changes to the display/rendering configuration get 
saved here. If it gets deleted, or isn’t in the SCC repo and the project is 
checked out elsewhere, it gets recreated from defaults when the program is run. 
If the user cares, it can be added to the SCC repo.

-a


> On Thu, Feb 22, 2018 at 12:15 PM, Andy Peters <de...@latke.net 
> <mailto:de...@latke.net>> wrote:
> 
> On Feb 22, 2018, at 7:58 AM, Jon Evans <j...@craftyjon.com 
> <mailto:j...@craftyjon.com>> wrote:
>> 
>> Currently some of the render visibility stuff is saved in the application 
>> preferences, and some is not saved.
>> I think if there are layers related to board item visibility that aren't 
>> saved, saving them in the project or board makes more sense than saving in 
>> the app config.
> 
> User perspective:
> 
> Saving the render visibility in the project or pcb file “touches” that file, 
> so Kicad will want to save the file when you close the project or PCB. And 
> then your source-code control system thinks that the file has been modified 
> (because it was!). This sort of change has nothing to do with the design, it 
> is only a rendering/display detail.
> 
> A common example: I often use pcbnew (or Altium, it has the same problem) to 
> view a design, without intending to actually modify it. And when doing that, 
> I often change layer visibility and such. When closing the pcb file, the user 
> will be asked to save the file. “But all I did was look at different layers 
> .. I didn’t change the design!” 
> 
> So, please, don’t keep layer visibility/rendering information in the pcb or 
> project file!

___
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] Rearrange Render panel of PcbNew layer widget; add spacers

[Andy Peters]

On Feb 22, 2018, at 7:58 AM, Jon Evans  wrote:
> 
> Currently some of the render visibility stuff is saved in the application 
> preferences, and some is not saved.
> I think if there are layers related to board item visibility that aren't 
> saved, saving them in the project or board makes more sense than saving in 
> the app config.

User perspective:

Saving the render visibility in the project or pcb file “touches” that file, so 
Kicad will want to save the file when you close the project or PCB. And then 
your source-code control system thinks that the file has been modified (because 
it was!). This sort of change has nothing to do with the design, it is only a 
rendering/display detail.

A common example: I often use pcbnew (or Altium, it has the same problem) to 
view a design, without intending to actually modify it. And when doing that, I 
often change layer visibility and such. When closing the pcb file, the user 
will be asked to save the file. “But all I did was look at different layers .. 
I didn’t change the design!” 

So, please, don’t keep layer visibility/rendering information in the pcb or 
project file!

-a

> 
> Re. 3, yes I think that same framework could be used to add some shortcuts 
> for the "render" side pretty easily.
> 
> Re. 2, seems reasonable, haven't looked at the code yet
> 
> I can probably tackle this but can also leave it to Andrzej if you are 
> interested in it.
> 
> @Wayne I guess the first patch can be merged now if you are OK with it, since 
> Jeff isn't worried about conflicts?
> 
> -Jon
> 
> On Thu, Feb 22, 2018 at 9:53 AM, Wayne Stambaugh  > wrote:
> On 2/22/2018 9:10 AM, Andrzej Wolski wrote:
> > If some work on Render panel is still being done, I would have some
> > suggestions:
> > 1. "Text Front" and "Text Back" should be renamed to something like
> > "Footpr. Text Front" It is misleading now.
> 
> I'm fine with this but please do not abbreviate the word footprint.
> 
> > 2. "Bl/Bburied Via" and "Micro Via" could be hidden if they are disabled
> > in design settings.
> 
> This makes sense as long as you do not couple the layer manager UI code
> to the board object code.
> 
> > 3. It would be nice to have right click menu with something like:
> > "Show all footprint related"
> > "Hide all footprint related"
> > "Show all free primitives"
> > "Hide all free primitives"
> > "Show all other???"
> > "Hide all other???"
> > "Show all"
> > "Hide all"
> 
> Don't we already have something like this in the layer manager (see
> attached image)?
> 
> > 4. State of some checkboxes is not saved.
> 
> I think only the layer visibility states are saved in the board file.  I
> would rather not add any more non-board related information the board
> file format than is already there.  This state information could be
> saved in the project file or the application config file.  My preference
> is the project file but it's not a strong preference.
> 
> >
> > If you can't, I could do some of these changes (if it's not too late for
> > them).
> >
> > Cheers,
> > Andrzej
> >
> >
> > W dniu 2018-02-22 o 05:39, Jon Evans pisze:
> >> Hi all,
> >>
> >> This patch rearranges the Render panel to be in a more logical order,
> >> and adds some whitespace.
> >> I divided it into three groupings:
> >> 1) footprint related
> >> 2) other board objects
> >> 3) non-board stuff like grid, ratlines, etc.
> >>
> >> I also bumped out the default size so that scrollbars aren't needed by
> >> default on my Linux system.
> >>
___
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-doc-devs] string change proposal

[Andy Peters]

> On Feb 8, 2018, at 3:15 AM, Andrey Kuznetsov  wrote:
> 
> Wow, that sentence is unnecessarily long.
> 
> By rephrasing, you can cut that text in half. Also, why is text editor and 
> PDF viewer in the same context? Default text editor and default PDF viewer do 
> not open the same files, is this a context for a Group where those 2 are 
> defined, weird…

Why in the same context? My guess is because they are both “preferences,” and 
putting them under the “preferences” menu item makes sense.

-a
___
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-doc-devs] string change proposal

[Andy Peters]

> On Feb 8, 2018, at 3:42 AM, Jeff Young <j...@rokeby.ie> wrote:
> 
> > … or "Set default text editor and PDF viewer programs to open files from 
> > KiCad”
> 
> +1

One could interpret “open files from KiCad” as being “Open files created by 
KiCad.”

The point I was trying to make, and perhaps wasn’t clear on, is that 
applications should never modify operating-system defaults that affect other 
applications. Thus saying “open files from (within) KiCad” is unnecessary, as 
it is understood that this setting affects performing this operation from 
within Kicad only.

I suppose, further, that this whole thing about choosing which PDF viewer and 
which text editor to use is completely unnecessary. Why _wouldn’t_ KiCad open 
text files in the OS default text editor? Why _wouldn’t_ you want it to open 
PDF files in the OS default PDF viewer? I set those defaults in the OS for a 
reason, and I expect applications to uses those defaults.

-a




> 
> 
>> On 8 Feb 2018, at 10:15, Andrey Kuznetsov <kandre...@gmail.com 
>> <mailto:kandre...@gmail.com>> wrote:
>> 
>> Wow, that sentence is unnecessarily long.
>> 
>> By rephrasing, you can cut that text in half. Also, why is text editor and 
>> PDF viewer in the same context? Default text editor and default PDF viewer 
>> do not open the same files, is this a context for a Group where those 2 are 
>> defined, weird...
>> 
>> Telling the user that he "may define" a"Default Text Editor" is redundant, 
>> same for favorite, default is better, that's what is seen across many 
>> programs, you define a default program to open files, you don't define a 
>> favorite program. "These settings" redundant because you are in a settings 
>> editor window, duhh. 
>> 
>> How about "Set default text editor and PDF viewer programs"?
>> 
>> If you want to be more explicit: "Set default text editor and PDF viewer 
>> programs for use by KiCad" or "Set default text editor and PDF viewer 
>> programs to open files from KiCad"
>> 
>> On Wed, Feb 7, 2018 at 8:23 AM, Andy Peters <de...@latke.net 
>> <mailto:de...@latke.net>> wrote:
>> 
>> 
>> > On Feb 7, 2018, at 5:09 AM, Marco Ciampa <ciam...@libero.it 
>> > <mailto:ciam...@libero.it>> wrote:
>> >
>> > Hello,
>> > I am not a native english,
>> 
>> Your English is better than my Italian!
>> 
>> > so I think it is better to ask even for small phrases:
>> >
>> > Here:
>> >
>> > #. type: Plain text
>> > #: kicad.adoc:246
>> > msgid ""
>> > "You may define your favorite text editor and PDF viewer. These settings 
>> > are "
>> > "used whenever you want to open a text or PDF file."
>> >
>> > I would have written it in a more esplicit way like:
>> >
>> > "You may define your favorite text editor and PDF viewer. These settings 
>> > are "
>> > "used by KiCad whenever you want to open a text or PDF file from the 
>> > inside "
>> > "of any of the KiCad tools."
>> >
>> > Comments?
>> 
>> In general, I’m a fan of being as explicit and clear as possible. But, in 
>> this case, I think the user should be aware that s/he’s setting something 
>> from within Kicad, and as such that setting is only relevant when 
>> interacting with a Kicad tool.
>> 
>> -a
___
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 back annotation tool

[Andy Peters]

> On Jan 15, 2018, at 4:17 PM, Dan Weatherill <dan.weather...@cantab.net> wrote:
> 
> This was just intended as a tidy-up of the existing script/GUI I have been 
> using myself for a while. There are at least two other attempts, the one that 
> Andy refers to, and also KRen 
> (https://forum.kicad.info/t/i-wrote-a-program-to-automatically-update-pcb-refdes-and-back-annotate-to-the-schematic/3561)
>  
> probably due to not investigating these enough before getting NIH syndrome I 
> wrote one as well….

kren never worked for me.

The tool I mentioned, at  https://hasanyavuz.ozderya.net/?p=256 
<https://hasanyavuz.ozderya.net/?p=256> , no longer works, at least with the 
nightlies.

-a



> 
> Dan W
> 
> On Monday, 15 January 2018 20:30:52 GMT Nick Østergaard wrote:
>> OK, I was not sure that you intended it as a functional mock-up or proff of
>> concept.
>> 
>> I have not yet had time to test it.
>> 
>> 2018-01-15 18:17 GMT+01:00 Andy Peters <de...@latke.net>:
>>> On Jan 15, 2018, at 12:22 AM, Nick Østergaard <oe.n...@gmail.com> wrote:
>>> 
>>> Also, it is hard to argue this to be used in KiCad when it uses PyQt.
>>> 
>>> 
>>> What I mean is that the functionality should be part of Kicad, not this
>>> particular implementation.
>>> 
>>> For those wondering why this is important — after we (day job, and every
>>> day job I’ve had since college) finish the board layout, we re-annotate
>>> the
>>> PCB so that the reference designators are geographical. This is purely for
>>> the benefit of the humans who assemble, rework and debug designs. When a
>>> board is a sea of parts, being able to find things by physical location
>>> makes life easier.
>>> 
>>> There is already a Python script [1] which does this, and it works well.
>>> 
>>> -a
>>> 
>>> [1] https://hasanyavuz.ozderya.net/?p=256
>>> 
>>> 2018-01-14 22:24 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>:
>>>> On 1/14/2018 3:20 PM, Andy Peters wrote:
>>>>>> On Jan 13, 2018, at 7:16 PM, Dan Weatherill
>>>>>> <dan.weather...@cantab.net>
>>>> 
>>>> wrote:
>>>>>> Dear all,
>>>>>> apologies first for the (unrelated to 5.0 stable) spam.
>>>>>> 
>>>>>> I have been working for a while on a back-annotation tool for kicad.
>>>> 
>>>> It is
>>>> 
>>>>>> finally in a shape where I feel it's worth letting others look at it
>>>> 
>>>> and
>>>> 
>>>>>> getting some feedback. You can find it here:
>>>>>> 
>>>>>> https://github.com/weatherhead99/kicad_backannotate
>>>>>> 
>>>>>> Any issues or comments very welcome!
>>>>>> I hope to work on getting something like this into kicad itself in the
>>>> 
>>>> longer
>>>> 
>>>>>> term.
>>>>> 
>>>>> I will test this soon!
>>>>> 
>>>>> IMHO this functionality should be part of Kicad, not an external tool.
>>>>> 
>>>>> -a
>>>> 
>>>> It's on the v6 road map and will eventually be part of KiCad.  If users
>>>> want to use an external tool to do this, that's fine but it's not
>>>> something that I would include in 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
>>> 
>>> 
>>> Andy Peters
>>> 5511 E Rosewood St
>>> Tucson, AZ 85711
>>> 520-907-2262
>>> de...@latke.net
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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

Andy Peters
5511 E Rosewood St
Tucson, AZ 85711
520-907-2262
de...@latke.net



___
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 back annotation tool

[Andy Peters]

> On Jan 13, 2018, at 7:16 PM, Dan Weatherill  wrote:
> 
> Dear all,
> apologies first for the (unrelated to 5.0 stable) spam.
> 
> I have been working for a while on a back-annotation tool for kicad. It is 
> finally in a shape where I feel it's worth letting others look at it and 
> getting some feedback. You can find it here:
> 
> https://github.com/weatherhead99/kicad_backannotate
> 
> Any issues or comments very welcome! 
> I hope to work on getting something like this into kicad itself in the longer 
> term.

Hi, Dan,

I am trying to get this to work on a macOS High Sierra machine.

I’ve installed Python3, because PyQt5 and its dependency SIP both require it.

When I go to install your module, using either

$ pip install. 

or 

$ python setup.py install

I get an error:

ImportError PyQt5

I installed SIP and PyQt5 using

pip3 install PyQt5

and it seemed be happy.

I imagine that this has to do with your code being python2 and PyQt5 being 
python3?

My python-fu is quite limited … any help is appreciated.

-a 



___
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] Update PCB from Schematic dialog issues

[Andy Peters]

> On Jan 23, 2018, at 7:50 AM, Wayne Stambaugh  wrote:
> 
> On 1/23/2018 9:40 AM, Jeff Young wrote:
>> Yeah, it’s just most noticeable in Read Netlist, but in fact it’s all
>> radio buttons in a box sizer:
> 
> Yuck, that's ugly!  Has it always been like this?  I find it hard to
> believe that no macos users have complained about it before this.  We
> may have to rethink the use of wxStaticBoxSizer if we cannot come up
> with a solution.

macOS user here. 

I’ve not complained about this because “beauty is in the eye of the beholder,” 
and since I rarely run Kicad on other platforms, I didn’t know that this 
behavior was not correct.

-a___
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 back annotation tool

[Andy Peters]

> On Jan 15, 2018, at 12:22 AM, Nick Østergaard <oe.n...@gmail.com> wrote:
> 
> Also, it is hard to argue this to be used in KiCad when it uses PyQt.

What I mean is that the functionality should be part of Kicad, not this 
particular implementation.

For those wondering why this is important — after we (day job, and every day 
job I’ve had since college) finish the board layout, we re-annotate the PCB so 
that the reference designators are geographical. This is purely for the benefit 
of the humans who assemble, rework and debug designs. When a board is a sea of 
parts, being able to find things by physical location makes life easier.

There is already a Python script [1] which does this, and it works well.

-a

[1] https://hasanyavuz.ozderya.net/?p=256


> 
> 2018-01-14 22:24 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>>:
> On 1/14/2018 3:20 PM, Andy Peters wrote:
> >
> >
> >> On Jan 13, 2018, at 7:16 PM, Dan Weatherill <dan.weather...@cantab.net 
> >> <mailto:dan.weather...@cantab.net>> wrote:
> >>
> >> Dear all,
> >> apologies first for the (unrelated to 5.0 stable) spam.
> >>
> >> I have been working for a while on a back-annotation tool for kicad. It is
> >> finally in a shape where I feel it's worth letting others look at it and
> >> getting some feedback. You can find it here:
> >>
> >> https://github.com/weatherhead99/kicad_backannotate 
> >> <https://github.com/weatherhead99/kicad_backannotate>
> >>
> >> Any issues or comments very welcome!
> >> I hope to work on getting something like this into kicad itself in the 
> >> longer
> >> term.
> >
> > I will test this soon!
> >
> > IMHO this functionality should be part of Kicad, not an external tool.
> >
> > -a
> 
> It's on the v6 road map and will eventually be part of KiCad.  If users
> want to use an external tool to do this, that's fine but it's not
> something that I would include in KiCad.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-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

Andy Peters
5511 E Rosewood St
Tucson, AZ 85711
520-907-2262
de...@latke.net



___
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 back annotation tool

[Andy Peters]

> On Jan 13, 2018, at 7:16 PM, Dan Weatherill  wrote:
> 
> Dear all,
> apologies first for the (unrelated to 5.0 stable) spam.
> 
> I have been working for a while on a back-annotation tool for kicad. It is 
> finally in a shape where I feel it's worth letting others look at it and 
> getting some feedback. You can find it here:
> 
> https://github.com/weatherhead99/kicad_backannotate
> 
> Any issues or comments very welcome! 
> I hope to work on getting something like this into kicad itself in the longer 
> term.

I will test this soon!

IMHO this functionality should be part of Kicad, not an external tool. 

-a
___
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] Renaming headers?

[Andy Peters]

> On Jan 9, 2018, at 10:37 AM, Chris Pavlina  wrote:
> 
> There's a plugin for vim called CtrlP that implements fuzzy matching on
> filenames too, which I use. Still, not even fuzzy matching will tell you
> PCB_EDIT_FRAME is in wxPcbStruct.h.

Not that I advocate for its use, Eclipse has its right-click-accessed context 
menu which includes “Open Declaration.” Select a thing in your source, right 
click, choose that, and blammo, the relevant file opens and your mouse goes to 
the declaration of that thing.

-a
___
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] Symbol library editor functionality removed

[Andy Peters]

Apropos of the recent discussion about problems with the ‘/‘ character in 
symbol names (https://lists.launchpad.net/kicad-developers/msg31705.html), I 
went to rename three problematic symbols in my library. I’m on the 24 Dec 2017 
nightly on macOS. (This is all in bug 
https://bugs.launchpad.net/kicad/+bug/1740717).

First and foremost: there has never been a straightforward way to rename a 
symbol in a library from within Kicad. (That is, not editing the library files 
in a text editor.) 

Previously I could copy the symbol using the “Load Component from Current 
Library” command followed by the “Create new component from the current 
component” command. The latter command opens a dialog box asking for the name 
of the new component. Then the user can save the library, delete the old symbol 
(the old name) and then save again. That first save is probably not necessary, 
but it doesn’t hurt.

Now in the current (as of 24 Dec, anyway) builds, the “create new from current” 
command no longer exists. We now have right-click accessed context menus, which 
are fine. All of the libraries in the table are available, so one doesn’t have 
to select the active library. Instead, the hide/reveal triangles let the user 
see all parts in a library.  

So from the context menu: There is “duplicate part,” which makes a clone of the 
selected part in the same library, right below the original, appending _0 (and 
incrementing) to the name of the part. There are “cut part” and “copy part” 
options, along with a “paste part” option, which allow the user to move a part 
from one library to another, or copy it to another library. __None of these 
commands give the user the option to rename the symbol!__

Also, the paste is rather hidden: one has to left-click to select the target 
library then right-click on the library name again to bring up a context menu 
which includes “paste item.” Ideally, the cut, copy and paste of the selected 
item should show up in the main menu’s Edit menu.

To sum up (feature request!):

a) symbol duplicate/cut/copy/paste commands should be accessed through the main 
Edit menu, not a context menu. Never create the copy with a default symbol 
name, always ask the user for a new name.

b) Add a symbol rename command.

In the footprint library editor, if you change the name of the footprint in the 
Footprint Properties dialog, when you go to :Save the footprint in the 
library,” you are asked to give the footprint a name.

-a
___
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] Default Canvas for v5

[Andy Peters]

> On Dec 31, 2017, at 11:06 AM, Tomasz Wlostowski  
> wrote:
> 
> On 31/12/17 18:38, Nick Østergaard wrote:
>> I don't think the term standard for Cairo is good. It is better to call
>> it fallback or faillsafe.
>> 
> 
> How about this:
> 
> - Always start with OpenGL by default.
> - If pcbnew crashes, fall back automagically to Cairo on the next
> launch. Inform that the renderer has been changed due to the crash.

Crashing is always bad. Users will file bug reports. On the Mac, a dialog pops 
up and offers to send a crash report to Apple. Instead, the exception should be 
caught and handled behind the user’s back, so Kicad starts as normal and the 
user is none the wiser.

> - In the case of graphics glitches, inform the users in the FAQ/Manual
> that they can fall back to software renderer in the View menu.
> - Don't use the term 'canvas' or 'view'. Just 'Enable HW acceleration’.

I like that. The fewer technical/programmer terms, the better.



___
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] Default Canvas for v5

[Andy Peters]

> On Dec 31, 2017, at 6:49 AM, Simon Wells  > wrote:
> 
> What about having the default set to cairo, and when the first/once run 
> dialog runs it talks about openGL (this goes against you already set to GAL) 
> but it allows a default that even if it crashes won’t require manually 
> editing a configuration to make it workable

User perspective:

The names for the canvases are “engineering terms,” that is, something named by 
the developers for their own internal use but were never renamed for the end 
user who might have no idea what is meant by “Cairo canvas” or what “GAL” 
stands for. I say that because early on I asked myself, “WTF is this ‘Cairo’ 
thing?”

I now understand (I think …) that Cairo and GAL implement the same features but 
the latter requires proper OpenGL hardware and drivers, and Cairo does not.

So perhaps better terms for these options is “Standard” and “Accelerated 
(OpenGL).” Users know what OpenGL means (I hope, it’s nothing new). As for why 
a user with access to OpenGL hardware would not choose to use it by default? 
Battery life on a laptop, I suppose, but in using Kicad for a few years now I 
can say I’ve never used the Cairo canvas at all.

-a




> Simon
> 
>> On 1/01/2018, at 2:48 AM, Wayne Stambaugh > > wrote:
>> 
>> I spite of my disdain for nagware, I'll tolerate this under the
>> following conditions:
>> 
>> The current canvas is not already on one of the gal canvases.  If the
>> user is already using a gal canvas, a dialog to inform the user about
>> the gal canvas is silly.
>> 
>> It's a one shot dialog that never appears again.
>> 
>> If the gal canvas crashes, the user isn't going to have to manually edit
>> a configuration file to restore the legacy canvas.  This requirement may
>> prevent us from setting the opengl canvas as the default so the solution
>> may not be as easy as it seems.
>> 
>> On 12/31/2017 07:34 AM, Jeff Young wrote:
>>> +1 to the startup dialog idea.
>>> 
>>> I think we also need to set reasonable transparencies in the layers so that 
>>> it looks more like the default legacy canvas.
>> 
>> I don' think this is necessary given that the gal canvas layer colors
>> and transparencies are completely user configurable but I'm not opposed
>> to a default layer color/transparency configuration that looks more like
>> the legacy canvas.
>> 
>>> 
 On 31 Dec 2017, at 10:09, Clemens Koller > wrote:
 
 On 2017-12-31 03:53, Jon Evans wrote:
> I know this would be work for someone to do and maybe I'd offer to do it 
> if the project leaders approve...
> What about a one-time pop-up when first installing a release 5.0 that 
> appears if the config says the user was using legacy canvas, telling them 
> about how to switch and that they should check it out?
> 
> -Jon
 
 +1
 An initial start-up dialog to setup the "users default" after a first 
 install or after a "reset Kicad to defaults, as I messed something up I 
 don't remember" seems very helpful to me. If OpenGL might still crash in 
 rare cases, warn the user in advance and explain, how he can safely step 
 back from using OpenGL in case it doesn't work and how to file a bug 
 report...
 
 Regards,
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New symbol table: problems with '/' characters?

[Andy Peters]

> 
> On 29 Dec 2017 10:25 AM, "Andy Peters" <de...@latke.net 
> <mailto:de...@latke.net>> wrote:
> On Nov 18, 2017, at 6:07 AM, Wayne Stambaugh <stambau...@gmail.com 
> <mailto:stambau...@gmail.com>> wrote:
>> 
>> Diego,
>> 
>> Thank you for the offer but I'm already working on it.  It is not as
>> easy to fix as it would seem.  The problem is what to do when you do not
>> have write access to the library with the invalid characters.  I have a
>> few ideas but it will take me a while to get it the way I want it.
> 
> Hi, Wayne,
> 
> I just ran into this problem. (I’m using the Dec 24 nightly on a High Sierra 
> Mac.) The thing is that my libraries are in a directory to which Kicad should 
> have write access. On my Mac, they’re at ~/Library/Application 
> Support/kicad/library
> 
> The three parts in my library that use a forward-slash in the name are new 
> for a design I am still working on, so renaming them in the library and then 
> replacing the components on the schematic from the library isn’t too painful. 
> That said: should “policy” going forward be to simply not have slashes in 
> part names? I guess this is probably wise, since as I understand it, the 
> .sweet format will be like .pretty with one symbol per file and the file’s 
> name is the symbol name.
> 
> -a

> On Dec 28, 2017, at 6:50 PM, Oliver Walters <oliver.henry.walt...@gmail.com> 
> wrote:
> 
> This "policy" is already in place for the libraries - 
> http://kicad-pcb.org/libraries/klc/G1.1/ 
> <http://kicad-pcb.org/libraries/klc/G1.1/>
Ah, OK, that settles it.

-a



___
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] New symbol table: problems with '/' characters?

[Andy Peters]

On Nov 18, 2017, at 6:07 AM, Wayne Stambaugh  wrote:
> 
> Diego,
> 
> Thank you for the offer but I'm already working on it.  It is not as
> easy to fix as it would seem.  The problem is what to do when you do not
> have write access to the library with the invalid characters.  I have a
> few ideas but it will take me a while to get it the way I want it.

Hi, Wayne,

I just ran into this problem. (I’m using the Dec 24 nightly on a High Sierra 
Mac.) The thing is that my libraries are in a directory to which Kicad should 
have write access. On my Mac, they’re at ~/Library/Application 
Support/kicad/library

The three parts in my library that use a forward-slash in the name are new for 
a design I am still working on, so renaming them in the library and then 
replacing the components on the schematic from the library isn’t too painful. 
That said: should “policy” going forward be to simply not have slashes in part 
names? I guess this is probably wise, since as I understand it, the .sweet 
format will be like .pretty with one symbol per file and the file’s name is the 
symbol name.

-a

> 
> On 11/18/2017 08:00 AM, Diego Herranz wrote:
>> Thanks. I'll chase that bug.
>> 
>> Diego
>> 
>> On 18 Nov 2017 11:35 am, "Nick Østergaard" > 
>> >> wrote:
>> 
>>See https://bugs.launchpad.net/bugs/1732236 
>> 
>>> >
>> 
>>2017-11-18 11:42 GMT+01:00 Diego Herranz
>> 
>> > >>:
>> 
>>Hi,
>> 
>>I'm testing a recent build (41f9c19b) on Ubuntu 16.04 64 bits.
>> 
>>When opening a schematic made with a nightly build ~2 months
>>old, the remapping dialog shows up. So far so good.
>> 
>>I've followed the recommendations
>>in http://kicad-pcb.org/post/symbol-lib-table/ 
>> 
>> and most things
>>seem to be working fine. Every symbol gets remapped but 2. Both
>>of which include '/' in their name (e.g. PIC32MX110F016D-I/PT).
>> 
>>Opening the schematic after the remap, it seems Kicad has
>>changed it to PIC32MX110F016D-I_PT.
>> 
>>In fact, after a bit more searching, I've found out that as soon
>>as the remapping dialog shows up, before clicking on "Remap
>>symbols" the '/' characters have been replaced to '_'. So I'm
>>guessing that is the reason why it can't find the symbols when
>>remapping?
>>"Warning: No symbol 'PIC32MX110F016D-I_PT' found in symbol
>>library table." confirms that the name was changed before the
>>remapping attempt.
>> 
>>I have then tried to edit the broken symbols in Eeschema. When I
>>try to assign "PIC32MX110F016D-I/PT" again, which can be found
>>through the "Choose Symbol" dialog without problems, it complains:
>>" Symbol 'PIC32MX1XXFXXXD-I_PT' not found in library
>>'MCU_Microchip_PIC32'! "
>> 
>>Am I doing something wrong? Is this a bug?
>> 
>>Many thanks,
>>Diego
>> 
>>___
>>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] Ratsnest local ratsnest display option wackiness

[Andy Peters]

I am working in GAL mode, with yesterday’s nightly. I have reported this as bug 
1740156.

There are three controls for ratsnest display: left-hand-side toolbar’s (LHS) 
Hide/Show Board Ratsnest button, Visibility Render tab’s Ratsnest checkbox, and 
the right-hand-side (RHS) toolbar’s Display Local Ratsnest button.

Toggling the LHS Board Ratsnest button toggles the visibility of the whole 
board’s ratsnest, as expected. The icon in this button changes so subtly that 
it’s not at all obvious that it changes! However, the tooltip for this button 
changes correctly. That is, when the ratsnest is visible, the tooltip reads 
“hide board ratsnest,” and when the ratsnest is invisible, it reads “show board 
ratsnest.” This is good — the tooltip should show what will happen if you press 
the button. Also, toggling this button toggles the checkmark in the ratsnest 
visibility option in the render thing. This too is good.

In the visibility window render tab, toggling the Ratsnest checkbox toggles the 
whole board ratsnest, as expected. When the checkbox is off, the ratsnest is 
gone; when on, the ratsnest appears. Also, the LHS toolbar board ratsnest 
button changes tooltip and (very subtly) its icon appropriately. So far so 
good. 

(However, the tooltip for the visibility checkbox always says “show unconnected 
nets as a ratsnest,” so it explains the feature, but doesn’t explain the effect 
of the checkbox toggle. The layer options in the visibility area are different: 
the checkboxes all have tooltips that say “enable this for visibility” and the 
items themselves have tooltips that are descriptive. This is an inconsistency, 
not really a bug.)

Now the really useful feature, the “local ratsnest.” It seems to work when it 
wants! Toggling it when the board ratsnest is enabled has no effect. The whole 
board ratsnest remains visible, the tooltip does not change from  “Display 
local ratsnest” and its icon very subtly changes until you either click on 
something or hit M with the cursor over a footprint, at which point it reverts 
to its previous state.

After some experimentation, it seems as if the only way to enable local 
ratsnest display is to toggle the ratsnest visibility to off, so all ratsnest 
lines vanish, then hover the mouse over a footprint and hit “M," at which time 
the nets connected to that footprint will appear and move as you move the part. 
The ratsnest doesn’t appear when you click on a part to select it, you must hit 
“M.” BUT — this does not hold true for the LHS Board Ratsnest button, that is, 
if you turn board ratsnest off with that button and select and move a part, no 
local ratsnest is displayed. Thus the visibility checkbox and the LHS toolbar 
button are not redundant.

If in that mode, you place the part (left-mouse-button click), the ratsnest 
lines vanish, and press the LHS Board Ratsnest button, the whole board ratsnest 
does not appear until you select or move a footprint. But, if you toggle the 
ratsnest visibility checkbox, the board ratsnest appears immediately.

Finally, it is clear that the RHS Local Ratsnest toolbar button does absolutely 
nothing.

My guess is that the logic should work the following way:

a) LHS ratnest button should toggle ratsnest on and off, with its icon state 
showing the current state and make it obvious.
b) RHS local ratsnest button should toggle between board and local ratsnest
c) Eliminate render tab visibility option for ratsnest entirely.

I understand that c) is where the ratsnest color may be changed, and if the 
user changes the background color to white, then white ratsnest lines become 
invisible. So perhaps the way this all should work is:

a) Eliminate LHS ratsnest toolbar button entirely.
b) Toggle ratsnest visibility with the checkbox in the render tab.
c) RHS ratsnest button toggles between board and local ratnest button. (And its 
tooltip should change with the state.)

I know this is somewhat long-winded but local ratnest display is really 
important when you’re working on a crowded board. 





Application: kicad
Version: (2017-12-24 revision 5708665)-master, release build
Libraries:
wxWidgets 3.0.2
libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
Boost: 1.61.0
Curl: 7.43.0
Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
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

Re: [Kicad-developers] Kicad from scratch, with web technologies. Suggestions?

[Andy Peters]

> On Dec 25, 2017, at 12:03 AM, Cerem Cem ASLAN  wrote:
> 
> There are a few problems between Kicad and us (me). First, you developers are 
> too arrogant. And your software, Kicad, sucks in many aspects. I can build my 
> own EDA, better than yours, there is no need for Kicad.
> 
> Yeah, that was what I was thinking for the last 1.5 years and that's 
> corrected a few days ago: 
> https://forum.kicad.info/t/kicad-from-scratch-with-web-technologies/8962 I 
> realized that "those people" were not developers at all, so there was a total 
> misunderstanding on my side. "Kicad sucks"? Nope, every application might 
> have problems. I'm a developer, an engineer, I know that. Sending bug reports 
> and/or sending patches is one of our responsibility as a user (and this is 
> what I did for our workflow: https://github.com/aktos-io/kicad-tools, 
> https://github.com/aktos-io/kicad-install) . 

Just so the developers know, this troll posted his screed on the Kicad.info 
users’ forum the other day. He conveniently provided a link, and I encourage 
everyone to spend a few minutes reading through it. 

Happy holidays!___
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] Modeless dialog action buttons

[Andy Peters]

> On Dec 23, 2017, at 9:17 AM, Jeff Young  wrote:
> 
> Found another one: Drill Files Generation.

In pcbnew, the netlist import dialog has a “cancel” button, which is useful for 
when you decide you don’t want to do the import, but once the import has 
completed, that button should change to “close.”

I’m not sure that the position of the “cancel” button in that dialog makes 
sense; perhaps it should be at the bottom of the buttons.

-a



> 
>> On 21 Dec 2017, at 14:33, Wayne Stambaugh  wrote:
>> 
>> They should be "Close".  I'll will try to get them fixed soon.
>> 
>> On 12/21/2017 8:00 AM, Jeff Young wrote:
>>> There are several modeless dialogs in pcbnew (for instance, Exchange 
>>> Footprint and Plot) which have action buttons and a “Cancel” button.
>>> 
>>> These shouldn’t be called “Cancel” as they don’t cancel the action.  They 
>>> should be either “Done” or “Close”.
>>> 
>>> Comments?
>>> 
>>> (Resending to fix bogus thread link.)
>>> ___

___
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] Eeschema bus upgrades and new connectivity algorithm

[Andy Peters]

On Dec 19, 2017, at 1:28 PM, Jon Evans  wrote:

> 2) Design needs multiple copies of a similar bus with distinct net names
> 
> Say you are designing a big data collection device.  It has a large FPGA and 
> 8 channels of ADC.  Each ADC needs its own set of signals going straight back 
> to the FPGA (i.e. no shared signals between the ADC)
> You could define buses going to each ADC like this:
> 
> "CH0{D[15..0] CLK_P CLK_N}"
> "CH1{D[15..0] CLK_P CLK_N}"
> and so on.
> 
> This would leave you with nets for each ADC like "CH0.D15", "CH0.CLK_P", etc
> 
> Now you could *optionally* also define an alias for the signals each ADC 
> needs:
> 
> "ADC" => "D[15..0] CLK_P CLK_N"
> 
> Then, you could name your ports/pins/buses like:
> 
> "CH0{ADC}"
> "CH1{ADC}"
> and so on.
> 
> Benefit 1: Even if you don't use aliases, putting a name in front of the bus 
> group means that each channel will get its nets automatically prefixed with 
> "CH0" etc.
> Benefit 2: If you use aliases, your port/pin/label names get much shorter, 
> the same as in the first example.

Oh, good god, I would have given my eyeteeth (which I no longer have) for this 
exact feature on my current design. It supports up to four (but normally just 
two) high-speed (40 MHz sample rate) octal ADCs, each with all LVDS, with bit 
clock, frame clock and DDR serial data lines, all going to a big FPGA. The ADCs 
are on one page, the FPGA is on another, and it’s a mess of lines. A nice way 
to roll all of that up into your buses would have been very handy.
___
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] Eeschema bus upgrades and new connectivity algorithm

[Andy Peters]

> On Dec 19, 2017, at 12:06 AM, Marco Ciampa  wrote:
> 
> 
>> If you define an alias called MEMORY, you can then define *multiple
>> different* memory buses, so they have to have different prefix names. But
>> you can also choose to use aliases *without* a prefix name, and then
>> everywhere you use that alias will be part of the same set of nets.
>> 
>> So, a more realistic and simple example would be:
>> 
>> Define alias "USB" containing "DP", "DM"
> 
> Ok
> 
> If I do not see this definition somewhere on the sheet, am I still able
> to understand the schematics just looking at a print on paper of it?
> 
> If I need to see also the "alias" definition to understand the
> schematics, where can I look at this template definition on the sheets?
> 
>> Now in one sheet you have a USB hub. You can define four different buses
>> with names and the alias, and get nets like "PORT1.DP" and so on.
>> 
>> But on a simpler design, you might not need four ports, so you can just use
>> "{USB}" in your bus name and get nets without any prefix.
> 
> But it seems to me that this is the same name of a net on the bus with
> name "USB"...

I think that this whole bus alias thing will work in the way you want — “still 
able to understand the schematics just by looking at a print on paper of it” 
because at some point, you need to use bus rippers to connect individual 
signals in the bus to pins on a connector or IC or other component. And those 
bus rippers will connect to nets that have fully-qualified names that will make 
sense, assuming the designer gave them sensible names.

-a


___
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] Eeschema bus upgrades and new connectivity algorithm

[Andy Peters]

> On Dec 13, 2017, at 9:15 PM, Jon Evans  wrote:
> 
> Hi all,
> 
> As some of you know, I've been working on some new features for Eeschema that 
> expand the capabilities of buses.
> These features are not yet complete, but I wanted to share my progress to get 
> early feedback.

User perspective: I think the whole idea is GREAT, and I have one question: can 
a bus be brought up through the hierarchy in the same way as a single net, 
perhaps using a (new) Bus Hierarchical Label? Kicad schematics _really_ need 
this feature.

Thanks,
-a
___
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] Joining buses with junctions behavior

[Andy Peters]

> On Dec 10, 2017, at 9:09 AM, Jon Evans  wrote:
> 
> Hi all,
> 
> As I am working on bus features I have dived into all the ways you can use 
> buses (that I haven't always known about myself).
> 
> One thing I noticed was an example given on the docs:
> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buses-labels-power-ports
> 
> Under "Global connections between buses", you have three different named bus 
> segments joined together with a junction, and a description of how their nets 
> will be connected during netlisting.
> 
> a) This behavior seems to be kind of broken at present -- when I try to 
> replicate it, the junction is sometimes automatically removed, and the 
> netlist does not join all of the nets as described in the manual (maybe 
> related to Seth's recent changes?)
> 
> b) Those of you who use this feature: how do you use it?  Do you care that 
> the final netlist arbitrarily picks one of the possible net names? 

User perspective: I honestly had no idea that EESchema would do what is claimed 
in the docs under “Global connections between buses."

"Buses PCA [0..15], ADR [0..7] and BUS [5..10] are connected together (note the 
junction here because the vertical bus wire joins the middle of the horizontal 
bus segment).

"More precisely, the corresponding members are connected together : PCA0, ADR0 
are connected, (as same as PCA1 and ADR1 … PCA7 and ADR7).
Furthermore, PCA5, BUS5 and ADR5 are connected (just as PCA6, BUS6 and ADR6 
like PCA7, BUS7 and ADR7). PCA8 and BUS8 are also connected (just as PCA9 and 
BUS9, PCA10 and BUS10).”

That seems crazy to me.

-a





___
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] terms clarification

[Andy Peters]

> On Nov 25, 2017, at 10:55 AM, Jean-Paul Louis <lou...@yahoo.com> wrote:
> 
> Andy,
> 
> I disagree with your statement that component and part are the same thing.
> 
> A component is a term used for the generic part, like a 10k resistor, a 7474 
> digital IC, a 741 op amp, etc..
> A part on the opposite side is a one to one relationship, unique to a single 
> supplier.
> 
> So you cannot mix component and part unless you are a careless designer who 
> does not care about
> the specifications differences between manufacturers. I have seen too many 
> designs fail when changing supplier.
> A hobbyist might not care in a one of a kind design, but a professional will 
> test for compatibility
> of the various sources in extreme cases, like high and low power supply, and 
> temperatures extremes.

Hi, Jean-Paul,

I suppose I should preface this by saying I’m a long-time do-it-for-a-living 
electronics engineer, so I tend to be careful.

I think perhaps this is a semantic argument with the added joy of language and 
country-of-origin differences. When I said, “‘Component' and ‘part' are 
synonymous,” I think you’re right, they’re not specifically the same thing. In 
context, whether one means “10k resistor” or “10k0 1% 0805 SMD resistor” is 
clear, as is “op-amp” and “OPA551PA.”

The situation you describe — the designer who doesn’t care whether a resistor 
is a 10k 1/8 W through-hole thing or an 0805 or whether 1% or 0.1% or 5% — is 
indulged by CvPCB and the idea that you can assign a footprint to a component 
symbol and get a “part” just before layout. That whole idea makes me crazy, 
it’s so backward, as I’m used to having an approved parts (there’s that word) 
list, and a company CAD library filled with parts that have footprints, 3D 
models and part numbers all in place. The idea is simply choose the part, vet 
it, create a library part once, use it on many designs going forward.

With that distinction made — “part” is synonymous with “fully qualified atomic 
part” and “component” is “generic thing,” how is Mario’s original question 
answered? The symbol library contains symbols, which may be components or may 
be parts. Again, pick something and document it so everyone is on the same 
page! (I’m in too many meetings where there are long-winded semantic 
discussions about things, and when asked my opinion, I say, “I really don’t 
care, just pick something and tell me what I should do!”)

How these concepts, not just the words, translate to other languages is 
something beyond my expertise (I’m monolingual).

—a




> 
> Just my two cents,
> Jean-Paul
> N1JPL
> 
>> On Nov 24, 2017, at 11:15 PM, Andy Peters <de...@latke.net> wrote:
>> 
>> 
>> 
>>> On Nov 22, 2017, at 7:53 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>> 
>>> On 11/22/2017 08:42 AM, jp charras wrote:
>>>> Le 22/11/2017 à 14:28, Marco Ciampa a écrit :
>>>>> On Wed, Nov 22, 2017 at 08:14:02AM -0500, Wayne Stambaugh wrote:
>>>>>> The devs discussed this some time ago and the general consensus is that
>>>>>> symbol is the preferred term.  I've already started converting the UI
>>>>>> strings to use the term symbol.  I'm sure there are UI strings that I
>>>>>> missed.  If you find them, please let me know so I can correct them.
>>>>>> 
>>>>> 
>>>>> I think that then there is some term confusion here ...
>>>>> 
>>>>> #: eeschema/menubar.cpp:462
>>>>> msgid ""
>>>>> "Edit components to symbols library links to switch to an other library 
>>>>> link "
>>>>> "(library IDs)"
>>>>> 
>>>>> This obviously is not "symbol to symbol link" ...
>>>>> 
>>>>> I really think that we should stick with the terms "footprint" and
>>>>> "symbol" only, and get rid of all the "component", "part", "module" and
>>>>> such altogether...
>>>>> 
>>>>> TIA
>>>> 
>>>> Sure 'This obviously is not symbol to symbol link",
>>>> but what is the meaning of "symbol to symbol link"
>>>> 
>>>> Symbols live in symbol libraries, and components in schematic files, at 
>>>> least for this menu.
>>>> And currently a symbol does not live in a schematic,
>>>> and a component has a link (lib id) to the symbol it uses in the schematic.
>>> 
>>> I think the terminology should be "library symbol" and "schematic
>>> symbol".  Both exist but schemat

Re: [Kicad-developers] terms clarification

[Andy Peters]

> On Nov 22, 2017, at 7:53 AM, Wayne Stambaugh  wrote:
> 
> On 11/22/2017 08:42 AM, jp charras wrote:
>> Le 22/11/2017 à 14:28, Marco Ciampa a écrit :
>>> On Wed, Nov 22, 2017 at 08:14:02AM -0500, Wayne Stambaugh wrote:
 The devs discussed this some time ago and the general consensus is that
 symbol is the preferred term.  I've already started converting the UI
 strings to use the term symbol.  I'm sure there are UI strings that I
 missed.  If you find them, please let me know so I can correct them.
 
>>> 
>>> I think that then there is some term confusion here ...
>>> 
>>> #: eeschema/menubar.cpp:462
>>> msgid ""
>>> "Edit components to symbols library links to switch to an other library 
>>> link "
>>> "(library IDs)"
>>> 
>>> This obviously is not "symbol to symbol link" ...
>>> 
>>> I really think that we should stick with the terms "footprint" and
>>> "symbol" only, and get rid of all the "component", "part", "module" and
>>> such altogether...
>>> 
>>> TIA
>> 
>> Sure 'This obviously is not symbol to symbol link",
>> but what is the meaning of "symbol to symbol link"
>> 
>> Symbols live in symbol libraries, and components in schematic files, at 
>> least for this menu.
>> And currently a symbol does not live in a schematic,
>> and a component has a link (lib id) to the symbol it uses in the schematic.
> 
> I think the terminology should be "library symbol" and "schematic
> symbol".  Both exist but schematic symbols have no graphic items other
> than fields.  The actual graphical representation of the symbol itself
> is a link to a symbol in a library.

From a user’s perspective, at least for Mario’s original question:

“Component” and “part” are synonymous. At least, this is the consensus over at 
the kicad.info user forum.

That consensus extends to: A component is a symbol which has an associated 
footprint. This implies that CvPCB is not used, and a component in a symbol 
library has a valid entry in its Footprint field. When you place a component 
onto the schematic, it contains everything necessary to use it in the layout.

If the symbol in the library has an empty footprint field, it is just a symbol. 
A user may create a symbol so something might be included in the BOM. A symbol 
might be created for use with SPICE. The power symbols are just that, symbols.

A “fully atomic part” is a symbol with a footprint and some kind of part number 
information to make it unique. That is, an OPA551PA symbol will have its 
footprint field filled in with DIP8_300 (or some other 8-pin DIP package) and a 
custom Part Number field is added and is filled in with something useful for 
the user.

All that said, whatever nomenclature ends up being chosen should be documented 
so everyone understands what is meant by each term.



___
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] Recent eeschema changes

[Andy Peters]

> On Nov 22, 2017, at 8:35 AM, Julius Schmidt  wrote:
> 
> 
> On Wed, 22 Nov 2017, Wayne Stambaugh wrote:
> 
>> First of all, you cannot opt out of remapping you schematic and expect
>> the library symbol links to continue to work correctly.  The symbol
>> library table is now the only way that library symbols are linked to
>> schematics symbols.  The only reason any of your symbols show up is that
>> they are still in the cache library.
> 
> I see. So I cannot look at old schematics files without converting them
> to the new format. I understand the technical reasons but the act of
> opening modifying a file on-disk that breaks it for older versions
> is not something I'd ever expect a program to do.
> 
> So basically to look at older files I should keep an older version of kicad 
> around …

This “touching” of projects occurs with more applications than I can count. For 
example: every time I want to view a completed Altium project and I change 
layer visibility, Altium marks the layout as modified. It asks me if I want to 
save the file before closing the application.

The solution I’ve found is: let the tool do whatever it wants to do, then 
simply don’t save the files after you’re doing viewing them. At the very least, 
make a copy of the project before viewing. My projects are in a Subversion 
repository, so it’s a simple matter of checking out a new working copy, and 
then deleting the working copy when I’m done.

-a


___
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] Questions regarding .sweet format

[Andy Peters]

> On Sep 18, 2017, at 6:27 AM, Wayne Stambaugh  wrote:
> 
> On 9/17/2017 2:59 AM, Oliver Walters wrote:
>> Hi Wayne, others,
>> 
>> *2. Symbol Variants*
>> *
>> *
>> One of the pressing shortfalls in the current library scheme is that the
>> footprint field is common to all aliases. Thus, if a symbol is made for
>> e.g. a SOIC-8 there cannot be an alias for a DIP-8 version of the
>> symbol. Many components have pin-compatible footprints.
>> 
>> In this case, is it as simple as doing the following:
>> 
>> (part "MYPART_DIP-8" inherets "MYPART_SOIC-8"
>>   (footprint "DIPS:DIP-8"> )
>> 
>> That's how I read the specification document. If my reading is correct,
>> then I think that's great.
> 
> That is exactly how it's supposed to work.  The "inherits" token is very
> powerful.

There has been a lot of discussion about atomic parts over on the user forum. 
I’m a big fan of them. The only support needed from Kicad to implement them, 
really, is the ability to add a simple “PN” (part number) field to the symbol. 
All of the parts in my symbol libraries have this field included and set to 
something useful). Whether the Kicad symbol format is updated to include that 
field by default or whether I have to add it doesn’t matter to me, I’ll add it 
if it doesn’t exist.

If a symbol has aliases which call out different footprints, can those aliases 
also include different PN fields? 

This is necessary because different footprints mean different manufacturer part 
numbers. If the new format supports this, then it’s brilliant and will work for 
me (and the other fans of atomic parts).

Thanks, and I apologize for not reading the specification document to see if 
what I ask for has already been considered.

-a
___
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] Additional Patch for via properties dialog (2)

[Andy Peters]

> On Aug 22, 2017, at 3:10 AM, Simon Küppers  wrote:
> 
> I second this. Working in a Research Institute I can assure you, that very 
> often there are circuit boards with "interesting" stackups and via 
> configurations... These boards are not produced by quick-turn factories like 
> eurocircuits but companies such as ILFA or Optiprint.
> 
> It would be unwise to cut out those users from KiCad.

I third this. We’ve been doing high-density boards with staggered/stacked 
microvias. For these designs, such vias are the only way the design could be 
completed. The boards are obviously not fabbed by the usual quick-turn Chinese 
places.



___
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