Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Jon Evans]

I have confirmed that there are no technical challenges with the migration
plan proposed by Orson.
I made some quick test code that automatically performs the migration
silently (i.e. by choosing a label randomly from the available ones to keep)
Before I go too far down this path (i.e. making a nice GUI for the
migration that lets the user control it, etc), does anyone have any other
concerns with this?
JP, maybe you either created this feature or remember its creation, do you
have any input?

Thanks,
Jon

On Mon, Apr 16, 2018 at 9:48 AM, Jon Evans  wrote:

> I think the logic you describe wouldn't be too bad to implement.
> I already have logic that collects all of the labels attached to a bus
> subgraph (an set of visually-connected bus wires)
> I could just split the bus name from the vector numbers, figure out what
> the size of the output vector should be, and propose a new name to the user.
> I guess it would need a dialog box because the user should get to choose
> what name comes out (there might not always be an obvious "winner", for
> example if each of the three buses in the example had the same width)
>
> If everyone else is on board with this approach, I'll make a test
> implementation to share.
>
> -Jon
>
> On Mon, Apr 16, 2018 at 9:39 AM, Maciej Sumiński 
> wrote:
>
>> I agree this a slightly confusing feature, which requires reading the
>> user manual to discover. I vote for removal, but we need a clever
>> migration plan to do so.
>>
>> I am not sure how easy would it be to implement it, but how about the
>> following automatic fix:
>> - determine the superset of connected buses (PCA[0..15] in the user
>> manual example)
>> - determine the other bus names (ADR[0..7] and BUS[5..10])
>> - rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)
>>
>> I believe such method keeps the connectivity data intact. Obviously it
>> would have to be approved by the user, no silent changes.
>>
>> Cheers,
>> Orson
>>
>> On 04/16/2018 05:05 AM, Jon Evans wrote:
>> > I thought about various ways that we could actually make this feature
>> work,
>> > but the more I thought about it, the more I thought that we would be
>> > bending over backwards to support something that shouldn't exist in the
>> > first place (in my opinion).
>> >
>> > Does anyone have a justification for this feature existing?  I'm not
>> trying
>> > to sound negative here, but if there is no benefit to it, and
>> eliminating
>> > it makes the rest of the behavior simpler to code and more logical and
>> > consistent, we should choose that path.
>> > If an ERC is not enough of a migration, we could also give a more
>> specific
>> > one-time nag dialog telling the user in detail what they are going to
>> have
>> > to do to fix their buses.
>> >
>> >
>> > -Jon
>> >
>> > On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand <
>> seth.hillbr...@gmail.com>
>> > wrote:
>> >
>> >> Hi Jon-
>> >>
>> >> The major issue I think we would need to address is migration.  I don't
>> >> think that only an ERC warning is sufficient in this case.  Users will
>> >> rightfully expect that their old schematics will generate valid
>> netlists
>> >> when opened in a newer KiCad.
>> >>
>> >> One option here would be to translate the implicit net connections into
>> >> explicit ones when bus junctions are encountered.   Unfortunately, I
>> think
>> >> that this feature is lightly used, so we might not get much user
>> feedback
>> >> until they encounter problems and then the problems will be very bad
>> >>
>> >> An alternative might be to increase the functionality of the bus
>> >> junction.  Spitballing here but we might add a "mapping table" dialog
>> that
>> >> allowed the user to specify the winning name and mapping order.  That
>> >> should address your points 2-3 although point 4 might be the issue.  I
>> >> think we could have a default mapping that follows the expected
>> convention
>> >> but allow users to change it by double-clicking on the junction and
>> editing
>> >> the mapping table.  Then previous users could keep their functionality
>> >> while still allowing the arbitrary member arrays you are building.
>> >>
>> >> Thoughts?
>> >> -S
>> >>
>> >>
>> >> 2018-04-15 16:40 GMT-07:00 Jon Evans :
>> >>
>> >>> Hi all,
>> >>>
>> >>> I am proposing to remove some behavior from KiCad as part of my bus
>> >>> connections changes.  I know we generally don't remove features in new
>> >>> releases without good reason, but I think this is an exceptional case.
>> >>>
>> >>> The user manual describes a way in which you can connect multiple
>> >>> different buses together with junctions.  If you aren't already
>> familiar
>> >>> with this behavior, please check out the manual:
>> >>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
>> >>> s-labels-power-ports
>> >>>
>> >>> The section in question is called "Global connections between buses"
>> and
>> >>> comes with the following 

Re: [Kicad-developers] Odd board

[Jon Evans]

The hole is displayed and I can select/move it.

On Mon, Apr 16, 2018 at 9:39 PM, Michael McCormack  wrote:

> Which version of not seeing the problem -
>
>1. The hole is displayed
>2. The hole gets dropped for the PCB file
>
> just curious
>
> Mike
>
> On Mon, Apr 16, 2018 at 9:30 PM, Jon Evans  wrote:
>
>> I tested on Ubuntu and Windows 10 using 5.0rc2 and don't see the problem,
>> so I guess it has been fixed somewhere along the way.
>>
>> On Mon, Apr 16, 2018 at 8:12 PM, Michael McCormack 
>> wrote:
>>
>>> OK, here is the boar file, if you need anything else, please let me know.
>>>
>>> On Mon, Apr 16, 2018 at 6:09 PM, Jeff Young  wrote:
>>>
 Looks like a different bug (2.9mm drill is smaller than 3.2mm pad).

 I can’t reproduce it on 5.0rc2 Mac.  Not sure if that’s because it’s
 fixed in 5.0, or it only shows up on Windows, or it’s something specific to
 Michael’s setup.


 On 16 Apr 2018, at 22:44, Michael McCormack  wrote:

 This is the module snipped from the board file:

   (module Ori:MountingHole_3.2mm_M3_ISO14580 (layer F.Cu) (tedit
 59C8FBCE) (tstamp 5AC4E91C)
 (at 138.25 141.050001)
 (descr "Mounting Hole 3.2mm, no annular, M3, ISO14580")
 (tags "mounting hole 3.2mm no annular m3 iso14580")
 (path /583B5C0A)
 (fp_text reference M1 (at 0 -3.75) (layer F.SilkS) hide
   (effects (font (size 1 1) (thickness 0.15)))
 )
 (fp_text value "M3_Mounting Hole" (at 0 3.75) (layer F.Fab)
   (effects (font (size 1 1) (thickness 0.15)))
 )
 (fp_circle (center 0 0) (end 2.75 0) (layer Cmts.User) (width 0.15))
 (fp_circle (center 0 0) (end 3 0) (layer F.CrtYd) (width 0.05))
 (pad "" np_thru_hole circle (at 0 0) (size 3.2 3.2) (drill 2.9)
 (layers *.Cu *.Mask)
   (clearance 2))
   )

 I am using 4.0.7 under Windows 10, if you decode this is the known bug
 I sincerely apologize for having wasted your time.  I did not see a bug
 that I thought was the same thing.  If not, I will mail it to any and all
 of you to look at.  I won't obfuscate, I'd be afraid to disturb the
 problem.  I see no real problem sharing the board with Kicad developers but
 can also understand why my employer is not keen to have our boards posted
 on the internet.

 Cheers
 Mike


 On Mon, Apr 16, 2018 at 5:13 PM, Jon Evans  wrote:

> That sounds like a bug (if there is invalid data like that, we should
> deal with it in a better way)
> It sounds like it might be easy to make a trivial test case to attach
> to a bug report without using your employer's board as-is
> (maybe by removing everything manually from the kicad_pcb file except
> for the hole in question and the board outline?)
>
> I can't take a look at this right this moment, but I could in the next
> few days if no one else jumps on it first.
>
> -Jon
>
> On Mon, Apr 16, 2018 at 4:35 PM, Michael McCormack 
> wrote:
>
>> This might not be quite the right place to post this, but, I've found
>> something that is a slightly problematic with Kicad and board file.  I 
>> have
>> a PCB that has a NPH hole located off the board, I can't see it or select
>> it inside PCBNew, however, it gets a hole in the gerbers and I can find 
>> it
>> in the kicad_pcb file if I open the file with a text editor.
>>
>> As it is my employer's board, I can't see them being OK with me
>> creating a bug report and posting the board file for just anyone to see;
>> but, as I have used Kicad myself probably a decade I'd send it to someone
>> to evaluate if it would help the project.
>>
>> Is anyone interested?
>>
>> ___
>> 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] Odd board

[Michael McCormack]

Which version of not seeing the problem -

   1. The hole is displayed
   2. The hole gets dropped for the PCB file

just curious

Mike

On Mon, Apr 16, 2018 at 9:30 PM, Jon Evans  wrote:

> I tested on Ubuntu and Windows 10 using 5.0rc2 and don't see the problem,
> so I guess it has been fixed somewhere along the way.
>
> On Mon, Apr 16, 2018 at 8:12 PM, Michael McCormack 
> wrote:
>
>> OK, here is the boar file, if you need anything else, please let me know.
>>
>> On Mon, Apr 16, 2018 at 6:09 PM, Jeff Young  wrote:
>>
>>> Looks like a different bug (2.9mm drill is smaller than 3.2mm pad).
>>>
>>> I can’t reproduce it on 5.0rc2 Mac.  Not sure if that’s because it’s
>>> fixed in 5.0, or it only shows up on Windows, or it’s something specific to
>>> Michael’s setup.
>>>
>>>
>>> On 16 Apr 2018, at 22:44, Michael McCormack  wrote:
>>>
>>> This is the module snipped from the board file:
>>>
>>>   (module Ori:MountingHole_3.2mm_M3_ISO14580 (layer F.Cu) (tedit
>>> 59C8FBCE) (tstamp 5AC4E91C)
>>> (at 138.25 141.050001)
>>> (descr "Mounting Hole 3.2mm, no annular, M3, ISO14580")
>>> (tags "mounting hole 3.2mm no annular m3 iso14580")
>>> (path /583B5C0A)
>>> (fp_text reference M1 (at 0 -3.75) (layer F.SilkS) hide
>>>   (effects (font (size 1 1) (thickness 0.15)))
>>> )
>>> (fp_text value "M3_Mounting Hole" (at 0 3.75) (layer F.Fab)
>>>   (effects (font (size 1 1) (thickness 0.15)))
>>> )
>>> (fp_circle (center 0 0) (end 2.75 0) (layer Cmts.User) (width 0.15))
>>> (fp_circle (center 0 0) (end 3 0) (layer F.CrtYd) (width 0.05))
>>> (pad "" np_thru_hole circle (at 0 0) (size 3.2 3.2) (drill 2.9)
>>> (layers *.Cu *.Mask)
>>>   (clearance 2))
>>>   )
>>>
>>> I am using 4.0.7 under Windows 10, if you decode this is the known bug I
>>> sincerely apologize for having wasted your time.  I did not see a bug that
>>> I thought was the same thing.  If not, I will mail it to any and all of you
>>> to look at.  I won't obfuscate, I'd be afraid to disturb the problem.  I
>>> see no real problem sharing the board with Kicad developers but can also
>>> understand why my employer is not keen to have our boards posted on the
>>> internet.
>>>
>>> Cheers
>>> Mike
>>>
>>>
>>> On Mon, Apr 16, 2018 at 5:13 PM, Jon Evans  wrote:
>>>
 That sounds like a bug (if there is invalid data like that, we should
 deal with it in a better way)
 It sounds like it might be easy to make a trivial test case to attach
 to a bug report without using your employer's board as-is
 (maybe by removing everything manually from the kicad_pcb file except
 for the hole in question and the board outline?)

 I can't take a look at this right this moment, but I could in the next
 few days if no one else jumps on it first.

 -Jon

 On Mon, Apr 16, 2018 at 4:35 PM, Michael McCormack 
 wrote:

> This might not be quite the right place to post this, but, I've found
> something that is a slightly problematic with Kicad and board file.  I 
> have
> a PCB that has a NPH hole located off the board, I can't see it or select
> it inside PCBNew, however, it gets a hole in the gerbers and I can find it
> in the kicad_pcb file if I open the file with a text editor.
>
> As it is my employer's board, I can't see them being OK with me
> creating a bug report and posting the board file for just anyone to see;
> but, as I have used Kicad myself probably a decade I'd send it to someone
> to evaluate if it would help the project.
>
> Is anyone interested?
>
> ___
> 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] Odd board

[Jon Evans]

I tested on Ubuntu and Windows 10 using 5.0rc2 and don't see the problem,
so I guess it has been fixed somewhere along the way.

On Mon, Apr 16, 2018 at 8:12 PM, Michael McCormack  wrote:

> OK, here is the boar file, if you need anything else, please let me know.
>
> On Mon, Apr 16, 2018 at 6:09 PM, Jeff Young  wrote:
>
>> Looks like a different bug (2.9mm drill is smaller than 3.2mm pad).
>>
>> I can’t reproduce it on 5.0rc2 Mac.  Not sure if that’s because it’s
>> fixed in 5.0, or it only shows up on Windows, or it’s something specific to
>> Michael’s setup.
>>
>>
>> On 16 Apr 2018, at 22:44, Michael McCormack  wrote:
>>
>> This is the module snipped from the board file:
>>
>>   (module Ori:MountingHole_3.2mm_M3_ISO14580 (layer F.Cu) (tedit
>> 59C8FBCE) (tstamp 5AC4E91C)
>> (at 138.25 141.050001)
>> (descr "Mounting Hole 3.2mm, no annular, M3, ISO14580")
>> (tags "mounting hole 3.2mm no annular m3 iso14580")
>> (path /583B5C0A)
>> (fp_text reference M1 (at 0 -3.75) (layer F.SilkS) hide
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (fp_text value "M3_Mounting Hole" (at 0 3.75) (layer F.Fab)
>>   (effects (font (size 1 1) (thickness 0.15)))
>> )
>> (fp_circle (center 0 0) (end 2.75 0) (layer Cmts.User) (width 0.15))
>> (fp_circle (center 0 0) (end 3 0) (layer F.CrtYd) (width 0.05))
>> (pad "" np_thru_hole circle (at 0 0) (size 3.2 3.2) (drill 2.9)
>> (layers *.Cu *.Mask)
>>   (clearance 2))
>>   )
>>
>> I am using 4.0.7 under Windows 10, if you decode this is the known bug I
>> sincerely apologize for having wasted your time.  I did not see a bug that
>> I thought was the same thing.  If not, I will mail it to any and all of you
>> to look at.  I won't obfuscate, I'd be afraid to disturb the problem.  I
>> see no real problem sharing the board with Kicad developers but can also
>> understand why my employer is not keen to have our boards posted on the
>> internet.
>>
>> Cheers
>> Mike
>>
>>
>> On Mon, Apr 16, 2018 at 5:13 PM, Jon Evans  wrote:
>>
>>> That sounds like a bug (if there is invalid data like that, we should
>>> deal with it in a better way)
>>> It sounds like it might be easy to make a trivial test case to attach to
>>> a bug report without using your employer's board as-is
>>> (maybe by removing everything manually from the kicad_pcb file except
>>> for the hole in question and the board outline?)
>>>
>>> I can't take a look at this right this moment, but I could in the next
>>> few days if no one else jumps on it first.
>>>
>>> -Jon
>>>
>>> On Mon, Apr 16, 2018 at 4:35 PM, Michael McCormack 
>>> wrote:
>>>
 This might not be quite the right place to post this, but, I've found
 something that is a slightly problematic with Kicad and board file.  I have
 a PCB that has a NPH hole located off the board, I can't see it or select
 it inside PCBNew, however, it gets a hole in the gerbers and I can find it
 in the kicad_pcb file if I open the file with a text editor.

 As it is my employer's board, I can't see them being OK with me
 creating a bug report and posting the board file for just anyone to see;
 but, as I have used Kicad myself probably a decade I'd send it to someone
 to evaluate if it would help the project.

 Is anyone interested?

 ___
 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] DISTCC/CCACHE

[Seth Hillbrand]

For those of you who use these tools, I've added a couple of optional cmake
flags to integrate them more easily.

-DUSE_DISTCC=ON/OFF
-DUSE_CCACHE=ON/OFF

You can use either or both or neither flags.  These default to off, so this
should not affect you unless you use these tools.

If you do use these tools to speed up your compiles, there are two benefits
over the various environment-based methods of using them.  First, cmake
will intelligently use them when testing during its feature-test, so you
don't get OpenGL errors (if you did) when configuring.

Second, it does a better job of detecting elements that can run
concurrently.  My testing shows about a 25% improvement in compile time
from scratch.  Your mileage will vary depending on how many machines are in
your distcc cluster.

If you currently use DISTCC/CCACHE as a re-mapped option using paths, you
will need to remove the CCACHE path from your $PATH environmental variable
before testing with the new flags turned on.

-S
___
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: fixes about hotkeys and menubar."

[Mário Luzeiro]

Hi JP,

since your last commit:
https://github.com/KiCad/kicad-source-mirror/commit/8fcdc4f6c3fb7c10b4088de11d15d95c4345f9d3

this file also needs to be fixed by adding the GR_KB_SHIFT +
https://github.com/KiCad/kicad-source-mirror/blob/9932ff32ae9b2d01a2a7d3ca4db0a6b971e5a0e6/3d-viewer/3d_cache/dialogs/panel_prev_model.h#L164

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

Re: [Kicad-developers] Odd board

[Michael McCormack]

This is the module snipped from the board file:

  (module Ori:MountingHole_3.2mm_M3_ISO14580 (layer F.Cu) (tedit 59C8FBCE)
(tstamp 5AC4E91C)
(at 138.25 141.050001)
(descr "Mounting Hole 3.2mm, no annular, M3, ISO14580")
(tags "mounting hole 3.2mm no annular m3 iso14580")
(path /583B5C0A)
(fp_text reference M1 (at 0 -3.75) (layer F.SilkS) hide
  (effects (font (size 1 1) (thickness 0.15)))
)
(fp_text value "M3_Mounting Hole" (at 0 3.75) (layer F.Fab)
  (effects (font (size 1 1) (thickness 0.15)))
)
(fp_circle (center 0 0) (end 2.75 0) (layer Cmts.User) (width 0.15))
(fp_circle (center 0 0) (end 3 0) (layer F.CrtYd) (width 0.05))
(pad "" np_thru_hole circle (at 0 0) (size 3.2 3.2) (drill 2.9) (layers
*.Cu *.Mask)
  (clearance 2))
  )

I am using 4.0.7 under Windows 10, if you decode this is the known bug I
sincerely apologize for having wasted your time.  I did not see a bug that
I thought was the same thing.  If not, I will mail it to any and all of you
to look at.  I won't obfuscate, I'd be afraid to disturb the problem.  I
see no real problem sharing the board with Kicad developers but can also
understand why my employer is not keen to have our boards posted on the
internet.

Cheers
Mike


On Mon, Apr 16, 2018 at 5:13 PM, Jon Evans  wrote:

> That sounds like a bug (if there is invalid data like that, we should deal
> with it in a better way)
> It sounds like it might be easy to make a trivial test case to attach to a
> bug report without using your employer's board as-is
> (maybe by removing everything manually from the kicad_pcb file except for
> the hole in question and the board outline?)
>
> I can't take a look at this right this moment, but I could in the next few
> days if no one else jumps on it first.
>
> -Jon
>
> On Mon, Apr 16, 2018 at 4:35 PM, Michael McCormack 
> wrote:
>
>> This might not be quite the right place to post this, but, I've found
>> something that is a slightly problematic with Kicad and board file.  I have
>> a PCB that has a NPH hole located off the board, I can't see it or select
>> it inside PCBNew, however, it gets a hole in the gerbers and I can find it
>> in the kicad_pcb file if I open the file with a text editor.
>>
>> As it is my employer's board, I can't see them being OK with me creating
>> a bug report and posting the board file for just anyone to see; but, as I
>> have used Kicad myself probably a decade I'd send it to someone to evaluate
>> if it would help the project.
>>
>> Is anyone interested?
>>
>> ___
>> 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] Odd board

[Jeff Young]

Hi Michael,

Is this in 4.0.*?  Is the hole the same size as the pad?  If so it’s a known 
bug that is fixed in 5.0.

If not then we’d love to get a cut-down version of the board.

Cheers,
Jeff.


> On 16 Apr 2018, at 22:08, Nick Østergaard  wrote:
> 
> Is it not possible for you to obfuscate the board to illustrate the problem? 
> Just delete 99% of the stuff on it to just show a board edge and the hole?
> 
> 2018-04-16 22:35 GMT+02:00 Michael McCormack  >:
> This might not be quite the right place to post this, but, I've found 
> something that is a slightly problematic with Kicad and board file.  I have a 
> PCB that has a NPH hole located off the board, I can't see it or select it 
> inside PCBNew, however, it gets a hole in the gerbers and I can find it in 
> the kicad_pcb file if I open the file with a text editor.
> 
> As it is my employer's board, I can't see them being OK with me creating a 
> bug report and posting the board file for just anyone to see; but, as I have 
> used Kicad myself probably a decade I'd send it to someone to evaluate if it 
> would help the project.
> 
> Is anyone interested?
> 
> ___
> 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] Odd board

[Nick Østergaard]

Is it not possible for you to obfuscate the board to illustrate the
problem? Just delete 99% of the stuff on it to just show a board edge and
the hole?

2018-04-16 22:35 GMT+02:00 Michael McCormack :

> This might not be quite the right place to post this, but, I've found
> something that is a slightly problematic with Kicad and board file.  I have
> a PCB that has a NPH hole located off the board, I can't see it or select
> it inside PCBNew, however, it gets a hole in the gerbers and I can find it
> in the kicad_pcb file if I open the file with a text editor.
>
> As it is my employer's board, I can't see them being OK with me creating a
> bug report and posting the board file for just anyone to see; but, as I
> have used Kicad myself probably a decade I'd send it to someone to evaluate
> if it would help the project.
>
> Is anyone interested?
>
> ___
> 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] Odd board

[Michael McCormack]

This might not be quite the right place to post this, but, I've found
something that is a slightly problematic with Kicad and board file.  I have
a PCB that has a NPH hole located off the board, I can't see it or select
it inside PCBNew, however, it gets a hole in the gerbers and I can find it
in the kicad_pcb file if I open the file with a text editor.

As it is my employer's board, I can't see them being OK with me creating a
bug report and posting the board file for just anyone to see; but, as I
have used Kicad myself probably a decade I'd send it to someone to evaluate
if it would help the project.

Is anyone interested?
___
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] Support for inner layer pads in modules

[Seth Hillbrand]

Hi Darrell-

Please see https://bugs.launchpad.net/kicad/+bug/1466962

Pads on inner layers is a good idea but it needs a full implementation.
This would include (at a minimum) adding the pads to arbitrary layers (not
just In2_Cu), new netnames layers, GAL layers and zone filling
connection/keepout.

It's a bit of an undertaking but if you're interested in helping out with
this during the V6 cycle, you can take on the bug report and submit a patch
for it.

Best-
Seth

2018-04-16 8:55 GMT-07:00 Darrell Harmon :

> Inner layer pads are useful for microwave filters implemented as Kicad
> modules, allowing tracks to connect to them.
>
> I've made a quick and dirty change to support the board I'm currently
> designing:
>
> --- a/pcbnew/class_pad.cpp
> +++ b/pcbnew/class_pad.cpp
> @@ -1248,6 +1248,11 @@ void D_PAD::ViewGetLayers( int aLayers[], int&
> aCount ) const
>  aLayers[aCount++] = LAYER_PAD_BK;
>  aLayers[aCount++] = LAYER_PAD_BK_NETNAMES;
>  }
> +else if( IsOnLayer( In2_Cu ))
> +{
> +aLayers[aCount++] = LAYER_TRACKS;
> +aLayers[aCount++] = LAYER_PADS_NETNAMES;
> +}
>
>  // Check non-copper layers. This list should include all the
> layers that the
>
> The result looks like this (purple fingers are a polygon):
> https://harmoninstruments.com/images/innerpads.png
>
> This needs an IsOnInnerLayer function which does not appear to be in
> the existing source. Also, using LAYER_TRACKS gives gray pads. What
> would be the best way to handle this?
>
> DRC and generated gerbers appear to be correct.
>
> I brought this up in the past on the kicad.info forum:
> https://forum.kicad.info/t/component-with-pads-on-an-inner-layer-for-st
> ripline-microwave-filters/9375/5
>
> Thanks,
> Darrell Harmon
>
> ___
> 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] Spate of bugs in global fields editor (aka BOM editor)

[Wayne Stambaugh]

Please let me know how much effort is involved on your part and we can
make a decision from there.

Thanks,

Wayne

On 4/16/2018 1:18 PM, Jeff Young wrote:
> Can I?  Certainly.
> 
> Without tearing my hair out?  Much more questionable. ;)
> 
> I’ll look into it….
> 
>> On 16 Apr 2018, at 18:10, Wayne Stambaugh  wrote:
>>
>> Is there any way you could do this without dragging in all of the other
>> changes?  If we cannot fix the current table editor, I'm OK with
>> updating to the wxGrid based design but I would prefer to keep the
>> changes to just the table editor.
>>
>> On 4/16/2018 6:02 AM, Jeff Young wrote:
>>> Given the spate of bug reports recently on the global fields editor (the 
>>> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 
>>> 6.0 rewrite which moves it to wxGrid.
>>>
>>> The implementation itself seems pretty sound, but does drag one other 
>>> change list along with it (for dialog consistency and beautification) that 
>>> adjusts the layouts and icons of a bunch of dialogs to be more consistent.
>>>
>>> Thoughts?
>>> ___
>>> 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] Spate of bugs in global fields editor (aka BOM editor)

[Jeff Young]

Can I?  Certainly.

Without tearing my hair out?  Much more questionable. ;)

I’ll look into it….

> On 16 Apr 2018, at 18:10, Wayne Stambaugh  wrote:
> 
> Is there any way you could do this without dragging in all of the other
> changes?  If we cannot fix the current table editor, I'm OK with
> updating to the wxGrid based design but I would prefer to keep the
> changes to just the table editor.
> 
> On 4/16/2018 6:02 AM, Jeff Young wrote:
>> Given the spate of bug reports recently on the global fields editor (the 
>> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 
>> 6.0 rewrite which moves it to wxGrid.
>> 
>> The implementation itself seems pretty sound, but does drag one other change 
>> list along with it (for dialog consistency and beautification) that adjusts 
>> the layouts and icons of a bunch of dialogs to be more consistent.
>> 
>> Thoughts?
>> ___
>> 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] Spate of bugs in global fields editor (aka BOM editor)

[Wayne Stambaugh]

Is there any way you could do this without dragging in all of the other
changes?  If we cannot fix the current table editor, I'm OK with
updating to the wxGrid based design but I would prefer to keep the
changes to just the table editor.

On 4/16/2018 6:02 AM, Jeff Young wrote:
> Given the spate of bug reports recently on the global fields editor (the 
> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 6.0 
> rewrite which moves it to wxGrid.
> 
> The implementation itself seems pretty sound, but does drag one other change 
> list along with it (for dialog consistency and beautification) that adjusts 
> the layouts and icons of a bunch of dialogs to be more consistent.
> 
> Thoughts?
> ___
> 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] Support for inner layer pads in modules

[Darrell Harmon]

Inner layer pads are useful for microwave filters implemented as Kicad
modules, allowing tracks to connect to them.

I've made a quick and dirty change to support the board I'm currently
designing:

--- a/pcbnew/class_pad.cpp
+++ b/pcbnew/class_pad.cpp
@@ -1248,6 +1248,11 @@ void D_PAD::ViewGetLayers( int aLayers[], int&
aCount ) const
 aLayers[aCount++] = LAYER_PAD_BK;
 aLayers[aCount++] = LAYER_PAD_BK_NETNAMES;
 }
+else if( IsOnLayer( In2_Cu ))
+{
+aLayers[aCount++] = LAYER_TRACKS;
+aLayers[aCount++] = LAYER_PADS_NETNAMES;
+}
 
 // Check non-copper layers. This list should include all the
layers that the

The result looks like this (purple fingers are a polygon):
https://harmoninstruments.com/images/innerpads.png

This needs an IsOnInnerLayer function which does not appear to be in
the existing source. Also, using LAYER_TRACKS gives gray pads. What
would be the best way to handle this?

DRC and generated gerbers appear to be correct.

I brought this up in the past on the kicad.info forum:
https://forum.kicad.info/t/component-with-pads-on-an-inner-layer-for-st
ripline-microwave-filters/9375/5

Thanks,
Darrell Harmon

___
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] Spate of bugs in global fields editor (aka BOM editor)

[Jeff Young]

Hi Martin,

We’re currently talking about the “BOM editor” rather than the “Fields editor”. 
 (Click the spreadsheet icon in the eeschema’s top toolbar to get the “BOM 
editor”.

That being said, I have also wxGrid-ized the Fields editor, which can be seen 
here: 
https://git.launchpad.net/~jeyjey/kicad/commit/common?h=6.0=9f89aafd0b26d5eb1fd7442663958c16c8885dd2
 
.

My version is a bit different than yours:
1) it supports things like text size, orientation, style, etc.
2) it still runs from the Fields dialog (both in LibEdit and in Eeschema)

Anyway, once we get into 6.0 we might want to look at combining the best 
features of both.  I definitely like the palette nature of yours.

Cheers,
Jeff.


> On 16 Apr 2018, at 16:02, Martin Schroeder  
> wrote:
> 
> I think that the new field editor is in the wrong place in the
> workflow. Typically I edit fields in the library editor and not on the
> schematic. I then use "Update fields" dialog to import field values.
> One big feature missing from the field editor is ability to
> back-import the fields to the libraries. So updating fields from
> libraries renders the new field editor completely useless where it is
> currently placed int he workflow.
> 
> Typically I want to have atomic private libraries where I create all
> the components ahead of time, assign manufacturer numbers to them and
> then reuse them without worrying about any fields after that. So
> effectively my private component library becomes the source for my
> bom. I then generate my bom from the fields that I have set up in the
> library. I find this to be a more robust way to manage components.
> 
> To make this workflow easier I have started work on a little panel for
> the library editor that allows editing the fields with a grid. I was
> not yet able to use a wxPropertyGrid for this because the program
> crashes for some reason in the constructor for wxPropertyGrid. I do
> not have time today to debug this so I went with normal editable
> wxGrid and a few helper fields. I want to eventually avoid all popup
> dialogs and just have all options readily available in the library
> editor. Together with the new tree browser this is awesome. What would
> also be really nice is if we could Ctrl-C + Ctrl-V inside the
> component tree view. This would greatly simplify local project library
> management. After that it would be nice to also add error checking to
> the erc rules workflow so that we can display errors if for example a
> component is missing a manufacturer number or some other field is
> misplaced.
> 
> I'm also a bit confused about the use of "Value" as actual component
> id in the library. I think this should eventually change such that
> component id is different from component value. Component value should
> actually probably be called "Comment" or something. However I'm
> thinking about an approach to add formatting to the display of the
> value field so that we can have spaces in it and perhaps discard part
> of the id (for example I'm thinking that a component named
> CAP@1nF~10V~0402 could display on the schematic as 1nF 10V 0402.
> 
> I've recorded a video today outlining some of the details of my work
> in progress: https://www.youtube.com/watch?v=J9Bh3xSW2tA
> 
> Code is also available from my branch (martin) from
> https://github.com/mkschreder/kicad.git
> 
> I hope we can either add ability to import back fields into the
> library versions of the components or move the field editor to the
> library editor allowing one to edit fields for all components in the
> library at the same time.
> 
> On Mon, Apr 16, 2018 at 12:02 PM, Jeff Young  wrote:
>> Given the spate of bug reports recently on the global fields editor (the 
>> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 
>> 6.0 rewrite which moves it to wxGrid.
>> 
>> The implementation itself seems pretty sound, but does drag one other change 
>> list along with it (for dialog consistency and beautification) that adjusts 
>> the layouts and icons of a bunch of dialogs to be more consistent.
>> 
>> Thoughts?
>> ___
>> 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] Spate of bugs in global fields editor (aka BOM editor)

[Jeff Young]

There is also:

https://bugs.launchpad.net/kicad/+bug/1729373 


and some of these also apply to the global fields editor:

https://bugs.launchpad.net/kicad/+bug/1764053 


My 6.0 commit can be found here:  
https://git.launchpad.net/~jeyjey/kicad/commit/common?h=6.0=903ef7e7ad24d2c5756b92f5d67a6747f6ea0268
 


That one’s a bit old (in terms of dependencies), but the relevant changes are 
largely the same.

Cheers,
Jeff.


> On 16 Apr 2018, at 14:12, Maciej Sumiński  wrote:
> 
> Hi Jeff,
> 
> Are you referring to lp:#1761378 [1] and lp:#1763223 [2] or there are
> more bugs? If you have the commits already published somewhere, would
> you give links to them? It is easier to evaluate an approach while
> looking at related code.
> 
> Cheers,
> Orson
> 
> 1. https://bugs.launchpad.net/kicad/+bug/1761378
> 2. https://bugs.launchpad.net/kicad/+bug/1763223
> 
> On 04/16/2018 12:02 PM, Jeff Young wrote:
>> Given the spate of bug reports recently on the global fields editor (the 
>> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 
>> 6.0 rewrite which moves it to wxGrid.
>> 
>> The implementation itself seems pretty sound, but does drag one other change 
>> list along with it (for dialog consistency and beautification) that adjusts 
>> the layouts and icons of a bunch of dialogs to be more consistent.
>> 
>> Thoughts?
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Fwd: Right to use KiCad name / logo

[Wayne Stambaugh]

On 4/16/2018 9:35 AM, Gustavo Bruno wrote:
> 2018-04-11 10:46 GMT-03:00 Wayne Stambaugh :
>> On 4/11/2018 9:23 AM, Strontium wrote:
>>> Who pays for that, and who holds it is another question.  But if it
>>> happens,  we should clearly define what's allowed and what's not.  For
>>> example, if you made a board in KiCad, is it allowed to put the KiCad
>>> logo on the boards silkscreen?  What if it's a commercial board, and not
>>> open source?  That sort of thing.
>>
>> As for the KiCad logo on boards designed with KiCad, I personally don't
>> have an issue with anyone adding our logo to their boards be they open
>> or proprietary.  It's free advertising either way.  I doubt many
>> proprietary boards will include any design tool logos.
> 
> Some countries, most notably the US, demands trademark enforcement for
> the the trademark to be kept valid. However, as long as we have clear
> terms (EULA-style, CERN legal team may certainly help with that) that
> explicity allow this kind of use, and define the terms in which it may
> be used, we should not worry.
> 
> IMHO, instead of a KiCad logo, the better way to do this is to have an
> official "Made with KiCad" symbol that makes it clear that it is not
> an official endorsement by the KiCad project, while allowing its use
> with a blanket license.
> 

We already have "Made with KiCad" footprints (although I am surprised
that we don't have a "Made with KiCad" symbol or bitmap to place in
schematics) which are covered under our library license.  However, this
case is the actual KiCad logo for merchandising so any trademarks would
apply.  I am looking into getting KiCad trademarked so we are covered in
this regard.

___
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] Remove bus joining behavior from KiCad after 5.0 release

[Jon Evans]

I think the logic you describe wouldn't be too bad to implement.
I already have logic that collects all of the labels attached to a bus
subgraph (an set of visually-connected bus wires)
I could just split the bus name from the vector numbers, figure out what
the size of the output vector should be, and propose a new name to the user.
I guess it would need a dialog box because the user should get to choose
what name comes out (there might not always be an obvious "winner", for
example if each of the three buses in the example had the same width)

If everyone else is on board with this approach, I'll make a test
implementation to share.

-Jon

On Mon, Apr 16, 2018 at 9:39 AM, Maciej Sumiński 
wrote:

> I agree this a slightly confusing feature, which requires reading the
> user manual to discover. I vote for removal, but we need a clever
> migration plan to do so.
>
> I am not sure how easy would it be to implement it, but how about the
> following automatic fix:
> - determine the superset of connected buses (PCA[0..15] in the user
> manual example)
> - determine the other bus names (ADR[0..7] and BUS[5..10])
> - rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)
>
> I believe such method keeps the connectivity data intact. Obviously it
> would have to be approved by the user, no silent changes.
>
> Cheers,
> Orson
>
> On 04/16/2018 05:05 AM, Jon Evans wrote:
> > I thought about various ways that we could actually make this feature
> work,
> > but the more I thought about it, the more I thought that we would be
> > bending over backwards to support something that shouldn't exist in the
> > first place (in my opinion).
> >
> > Does anyone have a justification for this feature existing?  I'm not
> trying
> > to sound negative here, but if there is no benefit to it, and eliminating
> > it makes the rest of the behavior simpler to code and more logical and
> > consistent, we should choose that path.
> > If an ERC is not enough of a migration, we could also give a more
> specific
> > one-time nag dialog telling the user in detail what they are going to
> have
> > to do to fix their buses.
> >
> >
> > -Jon
> >
> > On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand <
> seth.hillbr...@gmail.com>
> > wrote:
> >
> >> Hi Jon-
> >>
> >> The major issue I think we would need to address is migration.  I don't
> >> think that only an ERC warning is sufficient in this case.  Users will
> >> rightfully expect that their old schematics will generate valid netlists
> >> when opened in a newer KiCad.
> >>
> >> One option here would be to translate the implicit net connections into
> >> explicit ones when bus junctions are encountered.   Unfortunately, I
> think
> >> that this feature is lightly used, so we might not get much user
> feedback
> >> until they encounter problems and then the problems will be very bad
> >>
> >> An alternative might be to increase the functionality of the bus
> >> junction.  Spitballing here but we might add a "mapping table" dialog
> that
> >> allowed the user to specify the winning name and mapping order.  That
> >> should address your points 2-3 although point 4 might be the issue.  I
> >> think we could have a default mapping that follows the expected
> convention
> >> but allow users to change it by double-clicking on the junction and
> editing
> >> the mapping table.  Then previous users could keep their functionality
> >> while still allowing the arbitrary member arrays you are building.
> >>
> >> Thoughts?
> >> -S
> >>
> >>
> >> 2018-04-15 16:40 GMT-07:00 Jon Evans :
> >>
> >>> Hi all,
> >>>
> >>> I am proposing to remove some behavior from KiCad as part of my bus
> >>> connections changes.  I know we generally don't remove features in new
> >>> releases without good reason, but I think this is an exceptional case.
> >>>
> >>> The user manual describes a way in which you can connect multiple
> >>> different buses together with junctions.  If you aren't already
> familiar
> >>> with this behavior, please check out the manual:
> >>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
> >>> s-labels-power-ports
> >>>
> >>> The section in question is called "Global connections between buses"
> and
> >>> comes with the following image and describes how these bus wires with
> >>> different labels are connected together:
> >>>
> >>> Allowing this kind of behavior is problematic for a number of reasons:
> >>>
> >>> 1. It means that net wires and bus wires behave differently, since net
> >>> wires can't have more than one label.  This is potentially confusing
> for
> >>> users.
> >>>
> >>> 2. It means that junctions need a lot of special logic in order to
> >>> resolve which "branch" of a bus is called what name (for example, what
> if
> >>> one of those three branches in the above image didn't have a label?
> What
> >>> would its nets be called?)
> >>>
> >>> 3. Maybe most importantly, it breaks the label->netlist paradigm, since

Re: [Kicad-developers] Serious Lib cache issue, and fix in commit 2974a2c10

[Wayne Stambaugh]

On 4/16/2018 9:25 AM, Maciej Sumiński wrote:
> Hi Wayne,
> 
> I see, but I wonder if there is any benefit in making the colon
> exception just for rescue/cache libraries? I suppose it makes them
> special in the sense they cannot be used as regular libraries due to
> illegal character in symbol names.

Using a colon does have the side effect of not being able to directly
copy and rename the cache library file as a normal library file and add
it to the symbol library table.  This should no longer be necessary
because I fixed a bug in the rescuer that would not rescue symbols from
the cache when they no longer can be found in the library list prior the
symbol library table and have been removed or renamed after the symbol
library table implementation.

> 
> As I said, I am not familiar with caching/rescue code, but I imagine
> that once eeschema finds "LibraryName:SymbolName" missing, it could
> search for "LibraryName_SymbolName" in rescue/cache libraries. I do not
> insist on a change, just taking an opportunity to learn about caching
> mechanism.

That is a possible solution if we want to make the cache library
relocatable as a normal library and I'm not opposed to this.

> 
> Cheers,
> Orson
> 
> On 04/16/2018 03:08 PM, Wayne Stambaugh wrote:
>> Hey Orson,
>>
>> The colons are required to prevent symbol name clashes in the cache
>> library.  I had to prefix the library nickname to the symbol name to
>> prevent symbols from being overwritten when they exist in more than on
>> library.  In other words, cache library symbol names look just like
>> LIB_IDs using the LIB_NICKNAME:SYMBOL_NAME format.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/16/2018 9:03 AM, Maciej Sumiński wrote:
>>> Hi Jean-Pierre,
>>>
>>> I understand the patch and thank you for the fix, but apparently I do
>>> not have enough knowledge about caching in eeschema to comment on the
>>> approach. Frankly, I was a bit surprised to find out that colons are
>>> permitted in symbol names stored in a cache library.
>>>
>>> Regards,
>>> Orson
>>>
>>> On 04/16/2018 11:06 AM, jp charras wrote:
 Hi Wayne and Orson,

 Could you have a look into the fix I committed in rev 2974a2c10.
 Before this fix, the library cache was broken (all symbol names 
 incorrectly saved).
 This is specific to the cache, but really annoying...

 Please, see comments in commit 2974a2c10.

 But I am not sure this is the best way to fix this issue.

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

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

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Wayne Stambaugh]

On 4/16/2018 9:39 AM, Maciej Sumiński wrote:
> I agree this a slightly confusing feature, which requires reading the
> user manual to discover. I vote for removal, but we need a clever
> migration plan to do so.

I'm OK with removing this as well but we definitely need a migration
plan.  Users netlist connectivity should not be broken between versions
of KiCad.

> 
> I am not sure how easy would it be to implement it, but how about the
> following automatic fix:
> - determine the superset of connected buses (PCA[0..15] in the user
> manual example)
> - determine the other bus names (ADR[0..7] and BUS[5..10])
> - rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)

This seems like a reasonable solution.

> 
> I believe such method keeps the connectivity data intact. Obviously it
> would have to be approved by the user, no silent changes.

This is also a must.  Users tend not to like things silently changed.  I
would consider using our message panel control in a dialog and show all
of the bus net changes.

> 
> Cheers,
> Orson
> 
> On 04/16/2018 05:05 AM, Jon Evans wrote:
>> I thought about various ways that we could actually make this feature work,
>> but the more I thought about it, the more I thought that we would be
>> bending over backwards to support something that shouldn't exist in the
>> first place (in my opinion).
>>
>> Does anyone have a justification for this feature existing?  I'm not trying
>> to sound negative here, but if there is no benefit to it, and eliminating
>> it makes the rest of the behavior simpler to code and more logical and
>> consistent, we should choose that path.
>> If an ERC is not enough of a migration, we could also give a more specific
>> one-time nag dialog telling the user in detail what they are going to have
>> to do to fix their buses.
>>
>>
>> -Jon
>>
>> On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand 
>> wrote:
>>
>>> Hi Jon-
>>>
>>> The major issue I think we would need to address is migration.  I don't
>>> think that only an ERC warning is sufficient in this case.  Users will
>>> rightfully expect that their old schematics will generate valid netlists
>>> when opened in a newer KiCad.
>>>
>>> One option here would be to translate the implicit net connections into
>>> explicit ones when bus junctions are encountered.   Unfortunately, I think
>>> that this feature is lightly used, so we might not get much user feedback
>>> until they encounter problems and then the problems will be very bad
>>>
>>> An alternative might be to increase the functionality of the bus
>>> junction.  Spitballing here but we might add a "mapping table" dialog that
>>> allowed the user to specify the winning name and mapping order.  That
>>> should address your points 2-3 although point 4 might be the issue.  I
>>> think we could have a default mapping that follows the expected convention
>>> but allow users to change it by double-clicking on the junction and editing
>>> the mapping table.  Then previous users could keep their functionality
>>> while still allowing the arbitrary member arrays you are building.
>>>
>>> Thoughts?
>>> -S
>>>
>>>
>>> 2018-04-15 16:40 GMT-07:00 Jon Evans :
>>>
 Hi all,

 I am proposing to remove some behavior from KiCad as part of my bus
 connections changes.  I know we generally don't remove features in new
 releases without good reason, but I think this is an exceptional case.

 The user manual describes a way in which you can connect multiple
 different buses together with junctions.  If you aren't already familiar
 with this behavior, please check out the manual:
 http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
 s-labels-power-ports

 The section in question is called "Global connections between buses" and
 comes with the following image and describes how these bus wires with
 different labels are connected together:

 Allowing this kind of behavior is problematic for a number of reasons:

 1. It means that net wires and bus wires behave differently, since net
 wires can't have more than one label.  This is potentially confusing for
 users.

 2. It means that junctions need a lot of special logic in order to
 resolve which "branch" of a bus is called what name (for example, what if
 one of those three branches in the above image didn't have a label? What
 would its nets be called?)

 3. Maybe most importantly, it breaks the label->netlist paradigm, since
 an electrical net will only have one label in the eventual netlist, and
 there is no way to determine which label should "win"

 4. I don't think there's a way to map this behavior onto the new bus
 system I have built that allows arbitrary bus members (instead of just a
 sequential vector) in a way that would make any sense to the user.

 My proposed changes in this area are as follows:

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Maciej Sumiński]

I agree this a slightly confusing feature, which requires reading the
user manual to discover. I vote for removal, but we need a clever
migration plan to do so.

I am not sure how easy would it be to implement it, but how about the
following automatic fix:
- determine the superset of connected buses (PCA[0..15] in the user
manual example)
- determine the other bus names (ADR[0..7] and BUS[5..10])
- rename the other buses to match the superset bus (ADR->PCA, BUS->PCA)

I believe such method keeps the connectivity data intact. Obviously it
would have to be approved by the user, no silent changes.

Cheers,
Orson

On 04/16/2018 05:05 AM, Jon Evans wrote:
> I thought about various ways that we could actually make this feature work,
> but the more I thought about it, the more I thought that we would be
> bending over backwards to support something that shouldn't exist in the
> first place (in my opinion).
> 
> Does anyone have a justification for this feature existing?  I'm not trying
> to sound negative here, but if there is no benefit to it, and eliminating
> it makes the rest of the behavior simpler to code and more logical and
> consistent, we should choose that path.
> If an ERC is not enough of a migration, we could also give a more specific
> one-time nag dialog telling the user in detail what they are going to have
> to do to fix their buses.
> 
> 
> -Jon
> 
> On Sun, Apr 15, 2018 at 10:39 PM, Seth Hillbrand 
> wrote:
> 
>> Hi Jon-
>>
>> The major issue I think we would need to address is migration.  I don't
>> think that only an ERC warning is sufficient in this case.  Users will
>> rightfully expect that their old schematics will generate valid netlists
>> when opened in a newer KiCad.
>>
>> One option here would be to translate the implicit net connections into
>> explicit ones when bus junctions are encountered.   Unfortunately, I think
>> that this feature is lightly used, so we might not get much user feedback
>> until they encounter problems and then the problems will be very bad
>>
>> An alternative might be to increase the functionality of the bus
>> junction.  Spitballing here but we might add a "mapping table" dialog that
>> allowed the user to specify the winning name and mapping order.  That
>> should address your points 2-3 although point 4 might be the issue.  I
>> think we could have a default mapping that follows the expected convention
>> but allow users to change it by double-clicking on the junction and editing
>> the mapping table.  Then previous users could keep their functionality
>> while still allowing the arbitrary member arrays you are building.
>>
>> Thoughts?
>> -S
>>
>>
>> 2018-04-15 16:40 GMT-07:00 Jon Evans :
>>
>>> Hi all,
>>>
>>> I am proposing to remove some behavior from KiCad as part of my bus
>>> connections changes.  I know we generally don't remove features in new
>>> releases without good reason, but I think this is an exceptional case.
>>>
>>> The user manual describes a way in which you can connect multiple
>>> different buses together with junctions.  If you aren't already familiar
>>> with this behavior, please check out the manual:
>>> http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buse
>>> s-labels-power-ports
>>>
>>> The section in question is called "Global connections between buses" and
>>> comes with the following image and describes how these bus wires with
>>> different labels are connected together:
>>>
>>> Allowing this kind of behavior is problematic for a number of reasons:
>>>
>>> 1. It means that net wires and bus wires behave differently, since net
>>> wires can't have more than one label.  This is potentially confusing for
>>> users.
>>>
>>> 2. It means that junctions need a lot of special logic in order to
>>> resolve which "branch" of a bus is called what name (for example, what if
>>> one of those three branches in the above image didn't have a label? What
>>> would its nets be called?)
>>>
>>> 3. Maybe most importantly, it breaks the label->netlist paradigm, since
>>> an electrical net will only have one label in the eventual netlist, and
>>> there is no way to determine which label should "win"
>>>
>>> 4. I don't think there's a way to map this behavior onto the new bus
>>> system I have built that allows arbitrary bus members (instead of just a
>>> sequential vector) in a way that would make any sense to the user.
>>>
>>> My proposed changes in this area are as follows:
>>>
>>> 1. Remove this section from the user manual.
>>>
>>> 2. In my new connectivity algorithm, treat all connected bus wire
>>> segments as being part of the same bus (meaning they all will have the same
>>> "name")
>>>
>>> 3. Add an ERC warning about having more than one label attached to a bus
>>> (the warning would appear in the case of the example picture above)
>>>
>>> 4. Add a note to the user manual stating that this warning is new for 6.0
>>>
>>> The only downside that I can see in this approach is that any 

Re: [Kicad-developers] Serious Lib cache issue, and fix in commit 2974a2c10

[Maciej Sumiński]

Hi Wayne,

I see, but I wonder if there is any benefit in making the colon
exception just for rescue/cache libraries? I suppose it makes them
special in the sense they cannot be used as regular libraries due to
illegal character in symbol names.

As I said, I am not familiar with caching/rescue code, but I imagine
that once eeschema finds "LibraryName:SymbolName" missing, it could
search for "LibraryName_SymbolName" in rescue/cache libraries. I do not
insist on a change, just taking an opportunity to learn about caching
mechanism.

Cheers,
Orson

On 04/16/2018 03:08 PM, Wayne Stambaugh wrote:
> Hey Orson,
> 
> The colons are required to prevent symbol name clashes in the cache
> library.  I had to prefix the library nickname to the symbol name to
> prevent symbols from being overwritten when they exist in more than on
> library.  In other words, cache library symbol names look just like
> LIB_IDs using the LIB_NICKNAME:SYMBOL_NAME format.
> 
> Cheers,
> 
> Wayne
> 
> On 4/16/2018 9:03 AM, Maciej Sumiński wrote:
>> Hi Jean-Pierre,
>>
>> I understand the patch and thank you for the fix, but apparently I do
>> not have enough knowledge about caching in eeschema to comment on the
>> approach. Frankly, I was a bit surprised to find out that colons are
>> permitted in symbol names stored in a cache library.
>>
>> Regards,
>> Orson
>>
>> On 04/16/2018 11:06 AM, jp charras wrote:
>>> Hi Wayne and Orson,
>>>
>>> Could you have a look into the fix I committed in rev 2974a2c10.
>>> Before this fix, the library cache was broken (all symbol names incorrectly 
>>> saved).
>>> This is specific to the cache, but really annoying...
>>>
>>> Please, see comments in commit 2974a2c10.
>>>
>>> But I am not sure this is the best way to fix this issue.
>>>
>>> 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
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] Spate of bugs in global fields editor (aka BOM editor)

[Maciej Sumiński]

Hi Jeff,

Are you referring to lp:#1761378 [1] and lp:#1763223 [2] or there are
more bugs? If you have the commits already published somewhere, would
you give links to them? It is easier to evaluate an approach while
looking at related code.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1761378
2. https://bugs.launchpad.net/kicad/+bug/1763223

On 04/16/2018 12:02 PM, Jeff Young wrote:
> Given the spate of bug reports recently on the global fields editor (the 
> spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 6.0 
> rewrite which moves it to wxGrid.
> 
> The implementation itself seems pretty sound, but does drag one other change 
> list along with it (for dialog consistency and beautification) that adjusts 
> the layouts and icons of a bunch of dialogs to be more consistent.
> 
> Thoughts?
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] Serious Lib cache issue, and fix in commit 2974a2c10

[Wayne Stambaugh]

Hey Orson,

The colons are required to prevent symbol name clashes in the cache
library.  I had to prefix the library nickname to the symbol name to
prevent symbols from being overwritten when they exist in more than on
library.  In other words, cache library symbol names look just like
LIB_IDs using the LIB_NICKNAME:SYMBOL_NAME format.

Cheers,

Wayne

On 4/16/2018 9:03 AM, Maciej Sumiński wrote:
> Hi Jean-Pierre,
> 
> I understand the patch and thank you for the fix, but apparently I do
> not have enough knowledge about caching in eeschema to comment on the
> approach. Frankly, I was a bit surprised to find out that colons are
> permitted in symbol names stored in a cache library.
> 
> Regards,
> Orson
> 
> On 04/16/2018 11:06 AM, jp charras wrote:
>> Hi Wayne and Orson,
>>
>> Could you have a look into the fix I committed in rev 2974a2c10.
>> Before this fix, the library cache was broken (all symbol names incorrectly 
>> saved).
>> This is specific to the cache, but really annoying...
>>
>> Please, see comments in commit 2974a2c10.
>>
>> But I am not sure this is the best way to fix this issue.
>>
>> 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
> 

___
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] Serious Lib cache issue, and fix in commit 2974a2c10

[Maciej Sumiński]

Hi Jean-Pierre,

I understand the patch and thank you for the fix, but apparently I do
not have enough knowledge about caching in eeschema to comment on the
approach. Frankly, I was a bit surprised to find out that colons are
permitted in symbol names stored in a cache library.

Regards,
Orson

On 04/16/2018 11:06 AM, jp charras wrote:
> Hi Wayne and Orson,
> 
> Could you have a look into the fix I committed in rev 2974a2c10.
> Before this fix, the library cache was broken (all symbol names incorrectly 
> saved).
> This is specific to the cache, but really annoying...
> 
> Please, see comments in commit 2974a2c10.
> 
> But I am not sure this is the best way to fix this issue.
> 
> Thanks.
> 




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

[Kicad-developers] Spate of bugs in global fields editor (aka BOM editor)

[Jeff Young]

Given the spate of bug reports recently on the global fields editor (the 
spreadsheet icon in eeschema), I’m thinking perhaps I should back-port my 6.0 
rewrite which moves it to wxGrid.

The implementation itself seems pretty sound, but does drag one other change 
list along with it (for dialog consistency and beautification) that adjusts the 
layouts and icons of a bunch of dialogs to be more consistent.

Thoughts?
___
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] Serious Lib cache issue, and fix in commit 2974a2c10

[jp charras]

Hi Wayne and Orson,

Could you have a look into the fix I committed in rev 2974a2c10.
Before this fix, the library cache was broken (all symbol names incorrectly 
saved).
This is specific to the cache, but really annoying...

Please, see comments in commit 2974a2c10.

But I am not sure this is the best way to fix this issue.

Thanks.

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Fwd: Right to use KiCad name / logo

[Clemens Koller]

On 2018-04-16 07:33, Mark Roszko wrote:
>> "No national law applies" could be either difficult or beneficial for KiCad 
>> in the case of an infringement.
> 
> That doesn't prevent CERN's right as an entity to assert trademark claims in 
> any country where they registered as an entity and claimed trademarks via 
> applications.
> The same way me as an American can go register trademarks in Europe. They can 
> do the same. The statement on wiki is more related to other legal 
> jurisdiction issues.
> CERN already holds a few trademarks and they have a legal team as they are 
> quite largeso best to assume they know what they are doing. (Not that one 
> can't ask other lawyers)

Thank you for your clarification.
Propably it's just good to ask their legal team what they suggest in KiCad's 
case.

Clemens

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