Re: [Kicad-developers] Atomic Libraries Proposal

[Russell Oliver]

Maybe it can be implemented as not a new library format, but through
enhancements to the existing workflow and new symbol format.

If there was an ability to
a) filter symbols in eeschema that have a valid footprint that can be found
in the footprint library.
b) run a dfm check that flags symbols being used that aren't fully
defined.

Another idea i can think of is using hashes to link footprints and symbols.
Each symbol alias could have a linked footprint and a hash to verify that
the footprint is correct.

Cheers
Russ

On Fri, 24 May 2019, 9:29 am Seth Hillbrand,  wrote:

> Hi Rene-
>
> That's a fair critique.  The main benefits are ones that could be
> incorporated as separate tools (import/export, ability to switch between
> atomic and not, etc) once the new format is implemented.  In my use
> case, it is useful to separate the definitions from the libraries and
> switch between atomic libraries, but that might not be sufficiently
> common as to require an extra format.  Hence the request for feedback on
> the workflow.
>
> -Seth
>
> Am 2019-05-23 16:06, schrieb Rene Pöschl:
> > Hi Seth
> >
> > What is the benefit compared to having lets say a more powerful
> > aliasing
> > system that allows bom specific things to be more easily included in
> > the
> > kicad internal library without introducing something different?
> > (especially as i assume the new file format will provide a more
> > powerful
> > option in this regard anyways.)
> >
> > On 23/05/19 21:41, Seth Hillbrand wrote:
> >> Hi All-
> >>
> >> After some discussion, we are trying to decide whether implementing a
> >> basic atomic library support would be useful during v6 or would cause
> >> more headache than worth while trying to work with the solution.
> >>
> >> Background: "Atomic" libraries are ones that have unique names for
> >> symbol+footprint+properties combinations.  These are also referred to
> >> as
> >> "Fully-specified" libraries or sometimes "house libraries".
> >>
> >> The paradigm is outlined in a google document[1].  This is meant to
> >> provide an explicit option for users to create/utilize atomic library
> >> components without affecting the symbol or footprint formats.  It is
> >> also meant to be zero impact to the current, official KiCad libraries.
> >>
> >> The major limitations of the specification are:
> >> - No editing of the atomic library file within KiCad
> >> - The atomic library does not contain symbol or footprint data
> >>
> >> Folks are welcomed to weigh in on whether this approach presents a
> >> viable work flow for them.  I'm happy to take suggestions on the
> >> approach, I may ask you offline for some additional details of how you
> >> use KiCad and/or other tools with libraries at the moment.
> >>
> >> Best-
> >> Seth
> >>
> >>
> >> [1]
> >>
> https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
> >>
> >> ___
> >> Mailing list: https://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] eeSchema V6 - any thoughts as to tabbed schematics?

[Russell Oliver]

One thing I liked from Eagle was the list of sheets as thumbnails to
allow for visual recognition.


Regards
Russell Oliver



On Sat, 4 May 2019 at 10:20, Andrew Lutsenko  wrote:
>
> Hi Brian,
>
> There already is an easier way to navigate sheets than what you describe: 
> click "Navigate schematic hierarchy" button on top toolbar or "View -> Show 
> hierarchical navigator" which both open same view of schematic sheet tree. 
> Single click on any sheet will bring you directly to it so in your example 
> it's just two clicks (if using toolbar), regardless of level of sheet you are 
> coming from/navigating to.
>
> That said I too would love to see faster navigation via tabs, even if it's 
> just "only one tab at a time" deal.
>
> Regards,
> Andrew
>
> On Fri, May 3, 2019 at 4:49 PM Brian Piccioni  
> wrote:
>>
>> Jon
>>
>>
>>
>> My thought was simply that: a quick way of switching between sheets.
>>
>>
>>
>> Lets say I am in the main sheet and want to look at a circuit 2 levels down: 
>> I have to find the right sheet, click it, find the next sheet, click that, 
>> have a look, then backup and backup.
>>
>>
>>
>> I have found it much easier to simply open a new instance of eeSchema, 
>> however, that would present some problems if I touch any of the files due to 
>> coherency issues.
>>
>>
>>
>> It would be much easier to have a sheet list (I thought of tabs because that 
>> is the current paradigm for such things) and select click on the target 
>> sheet then click on the main sheet to return. There may be an easier way of 
>> doing so via, say, a right mouse click or something if wxWidgets is not yet 
>> up to the task.
>>
>>
>>
>> I wasn’t thinking of concurrent viewing at all, and I can see how that would 
>> complicate matters.
>>
>>
>>
>> I was ruminating on this because of my current project to renumber boards. I 
>> have made great progress and expect to start integrating it with PCBNew and 
>> eeSchema as a prototype within a few days.
>>
>>
>>
>> My utility currently caches the schematic hierarchy and it struck me that 
>> with some modification that would permit quick selection of any sheet in the 
>> hierarchy, with the resulting benefits in terms of usability.
>>
>>
>>
>> Not that I’d suggest a hack in production code but one can imagine 
>> prototyping this by essentially inserting a UI in the file open menu item, 
>> keeping track of dirty sheets, and writing the cache out when invoking a 
>> save command.
>>
>>
>>
>> Of course, this is no doubt simplistic given my lack of expertise in the 
>> matter.
>>
>>
>>
>> Brian
>>
>>
>>
>>
>>
>>
>>
>> From: Jon Evans 
>> Sent: May 3, 2019 10:52 AM
>> To: Brian Piccioni 
>> Cc: Kevin Cozens ; kicad-developers 
>> 
>> Subject: Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed 
>> schematics?
>>
>>
>>
>> If this is essentially adding a faster way to switch between sheets, it 
>> should be very straightforward.
>>
>> If instead you want to be able to view more than one sheet at a time (side 
>> by side tabs, or something), it would be more complex because currently 
>> Eeschema has a lot of code that expects only a single sheet active at a time.
>>
>>
>>
>> -Jon
>>
>>
>>
>> On Fri, May 3, 2019 at 10:45 AM Brian Piccioni  
>> wrote:
>>
>> Thanks.
>>
>> I suspect that it doesn't require much change since one would be essentially
>> changing the focus to a sheet in memory rather than reloading it.
>>
>> Brian
>>
>> -Original Message-
>> From: Kicad-developers
>> 
>> On Behalf Of Kevin Cozens
>> Sent: May 3, 2019 10:36 AM
>> To: kicad-developers 
>> Subject: Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed
>> schematics?
>>
>> On Fri, 3 May 2019 at 14:06, Brian Piccioni 
>> wrote:
>> > Currently you have to open another instance of eeSchema or click
>> > through to sheets in order to see other sheets. Tabs would be more
>> > convenient than clicking on a sheet (or multiple levels of sheets),
>> > backing out, etc., at least in many circumstances.
>>
>> That is an interesting idea. It could become an option in addition to the
>> current sheet navigation system. A new option could be added which would be
>> something like

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Russell Oliver]

 Once the schematic and
> symbol library code is swigged out to Python, integrating functionality
> as a third party Python script should be possible since all of the low
> level objects will be exposed to Python scripting in much the same way
> as the low level board objects are exposed in the board and footprint
> editors.
>
> >
> > Best,
> > Jon
> >
> > On Thu, May 2, 2019 at 9:16 PM Russell Oliver  > <mailto:roliver8...@gmail.com>> wrote:
> >
> > Hi All,
> >
> > First off congratulations to everyone involved with KiCon for making
> > it a success and the great progress that is happening with Kicad at
> > the moment.
> >
> > I've been following Dave Vandenbout's work on SKIDL [1] a while but
> > his talk [2] at the conference on SKIDL really showed the power that
> > programmatic circuit design could bring to electronic design
> > especially with a simulation/optimization loop.
> >
> > To that end I wondered weather it would be possible to include the
> > netlist output from a SKIDL script into a traditional schematic,
> > allowing for the best use of both worlds?
> >
> > Given that we currently have subsheets that can be reused multiple
> > times, could it be possible through the inclusion of a netlist reader
> > into Eeschema to read either a netlist file directly or the result of
> > executing a SKIDL script and incorporate that back into the larger
> > netlist?
> >
> > I can imagine a type of hierarchical sheet where the user can specify
> > the nets to be shown as sheet pins, which would be connected to the
> > matching nets from the netlist file.
> >
> > My question to those with more knowledge of the current netlist
> > generation algorithm is how possible this would be?
> >
> > [1] https://github.com/xesscorp/skidl
> > [2] https://www.youtube.com/watch?v=WErQYI2A36M
> >
> > Regards
> > Russell Oliver
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto: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

[Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Russell Oliver]

Hi All,

First off congratulations to everyone involved with KiCon for making
it a success and the great progress that is happening with Kicad at
the moment.

I've been following Dave Vandenbout's work on SKIDL [1] a while but
his talk [2] at the conference on SKIDL really showed the power that
programmatic circuit design could bring to electronic design
especially with a simulation/optimization loop.

To that end I wondered weather it would be possible to include the
netlist output from a SKIDL script into a traditional schematic,
allowing for the best use of both worlds?

Given that we currently have subsheets that can be reused multiple
times, could it be possible through the inclusion of a netlist reader
into Eeschema to read either a netlist file directly or the result of
executing a SKIDL script and incorporate that back into the larger
netlist?

I can imagine a type of hierarchical sheet where the user can specify
the nets to be shown as sheet pins, which would be connected to the
matching nets from the netlist file.

My question to those with more knowledge of the current netlist
generation algorithm is how possible this would be?

[1] https://github.com/xesscorp/skidl
[2] https://www.youtube.com/watch?v=WErQYI2A36M

Regards
Russell Oliver

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

Re: [Kicad-developers] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

[Russell Oliver]

Is it just me or in the ci server down? http://ci.kicad-pcb.org/

I was going to investigate the current build configuration for the
windows nightly installers.
seems it might be possible with a few lines added to the nsis script.
https://github.com/KiCad/kicad-winbuilder/blob/master/nsis/install.nsi#L647


Regards
Russell Oliver

On Tue, 12 Mar 2019 at 21:30, Nick Østergaard  wrote:
>
> https://github.com/KiCad/kicad-winbuilder/issues/53#issuecomment-337167911
>
> tir. 12. mar. 2019 11.07 skrev Russell Oliver :
>>
>> To cut down the download size, can there be a nightly package built
>> that doesn't contain the library, module and 3d files? just enough to
>> overwrite the program files.
>>
>>
>> Regards
>> Russell Oliver
>>
>>
>>
>> On Mon, 11 Mar 2019 at 06:00, Mark Roszko  wrote:
>> >
>> > AFAI CERN has private cluster using Ceph that has an S3 api but its not 
>> > AWS. It's also not as simple as creating a torrent because there still 
>> > needs to be a primary seed server.
>> >
>> > On Sat, Mar 9, 2019 at 6:23 PM Andrew Lutsenko  
>> > wrote:
>> >>
>> >> I think torrents are the best solution.
>> >> Even when servers function normally on each release there is a stampede 
>> >> to download new binary and things slow down to a crawl. I don't know if 
>> >> moving to CERN servers (AWS servers?) will help but torrents certainly 
>> >> would.
>> >>
>> >> It's as simple as creating a torrent with openbittorrent.com tracker or 
>> >> even just a magnet link relying on DHT.
>> >> I can help script this if needed.
>> >>
>> >> On Sat, Mar 9, 2019 at 10:32 AM Marco Ciampa  wrote:
>> >>>
>> >>> On Sat, Mar 09, 2019 at 01:22:39PM -0500, Wayne Stambaugh wrote:
>> >>> > Thanks.  If we are having issues with the CERN download speeds 
>> >>> > (although
>> >>> > it is not entirely evident that is the issue) it would be good to have
>> >>> > alternate mirrors for users to try if they are having issues with the
>> >>> > main download server.
>> >>>
>> >>> Why not adding torrent seeds like done for the Ubuntu iso images or
>> >>> Libreoffice binary files? We must have a torrent tracker somewhere and
>> >>> that should offload servers and should solve the peak download problems
>> >>> if any...
>> >>>
>> >>> --
>> >>>
>> >>>
>> >>> Marco Ciampa
>> >>>
>> >>> I know a joke about UDP, but you might not get it.
>> >>>
>> >>> 
>> >>>
>> >>>  GNU/Linux User #78271
>> >>>  FSFE fellow #364
>> >>>
>> >>> 
>> >>>
>> >>>
>> >>> ___
>> >>> Mailing list: https://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
>> >
>> >
>> >
>> > --
>> > Mark
>> > ___
>> > Mailing list: https://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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

[Russell Oliver]

To cut down the download size, can there be a nightly package built
that doesn't contain the library, module and 3d files? just enough to
overwrite the program files.


Regards
Russell Oliver



On Mon, 11 Mar 2019 at 06:00, Mark Roszko  wrote:
>
> AFAI CERN has private cluster using Ceph that has an S3 api but its not AWS. 
> It's also not as simple as creating a torrent because there still needs to be 
> a primary seed server.
>
> On Sat, Mar 9, 2019 at 6:23 PM Andrew Lutsenko  wrote:
>>
>> I think torrents are the best solution.
>> Even when servers function normally on each release there is a stampede to 
>> download new binary and things slow down to a crawl. I don't know if moving 
>> to CERN servers (AWS servers?) will help but torrents certainly would.
>>
>> It's as simple as creating a torrent with openbittorrent.com tracker or even 
>> just a magnet link relying on DHT.
>> I can help script this if needed.
>>
>> On Sat, Mar 9, 2019 at 10:32 AM Marco Ciampa  wrote:
>>>
>>> On Sat, Mar 09, 2019 at 01:22:39PM -0500, Wayne Stambaugh wrote:
>>> > Thanks.  If we are having issues with the CERN download speeds (although
>>> > it is not entirely evident that is the issue) it would be good to have
>>> > alternate mirrors for users to try if they are having issues with the
>>> > main download server.
>>>
>>> Why not adding torrent seeds like done for the Ubuntu iso images or
>>> Libreoffice binary files? We must have a torrent tracker somewhere and
>>> that should offload servers and should solve the peak download problems
>>> if any...
>>>
>>> --
>>>
>>>
>>> Marco Ciampa
>>>
>>> I know a joke about UDP, but you might not get it.
>>>
>>> 
>>>
>>>  GNU/Linux User #78271
>>>  FSFE fellow #364
>>>
>>> 
>>>
>>>
>>> ___
>>> Mailing list: https://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
>
>
>
> --
> Mark
> ___
> Mailing list: https://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] More default fields in schematic

[Russell Oliver]

I don't know if this approach is what is being proposed but the way I
envisage it working is to have the ability to set a list of default fields
at a project level, which you could also set as your default for new
projects. Not necessarily adding to the list of default fields currently
hard coded into Kicad.

Any time you place a symbol or footprint, it would copy the additional
default fields into the list found in the properties editor.

Users would be free to include what ever fields they like as default. I
typically use MPN and Manufacturer then Digikey, Mouser etc

On Tue, 22 May 2018 04:31 Ingo Kletti,  wrote:

> I'll throw in my weight as my job is supporting students working on
> their assigntments in electronics engineering (40-50 students per
> semester) and for many their first contact with EDA software is KiCad.
>
> I've created a small atomic library representing the parts we have
> readily available but the majority of parts are special to the task at
> hand and need to be sourced from Digikey, Mouser et al.
>
> We could impose a policy about additional fields, but from experience
> I'd say that we would have to reject about half of the projects.
>
> So if the fields like Manufacturer Part Number or Vendor were
> pre-defined, this would give first-time users like our students a much
> better idea about the usefulness of the fields without me and my
> colleagues explaining the same thing over and over.
>
> In addition external tools and plugins would finally know what terms to
> look for and work without the need for fine-tuning for keywords before
> being useful.
>
> And for the argument of "part number must be unique and Manufacturer and
> Vendor must be handled by the company database":
>
> This is complete overkill for one-off project like the ones our students
> work on, but nevertheless we need a way to enable external tools for
> handling the component sourcing.
>
> I guess this is also true for a big but silent part of the Kicad user base.
>
> Regards,
>
> Ingo
>
> ___
> Mailing list: https://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] Partial fix for bug #1758747 Import Eagle Project ignores cream="no" option

[Russell Oliver]

Updated patch, which also should fix rotations for rectangles. This should
be a complete fix for the reported bug.

On Sat, Mar 31, 2018 at 11:07 PM Russell Oliver <roliver8...@gmail.com>
wrote:

> No I won't have time to.
>
> There is still the issue of Eagle rectangles with a rotation applied not
> being imported correctly too.
>
>
> On Sat, 31 Mar 2018 14:03 Seth Hillbrand, <seth.hillbr...@gmail.com>
> wrote:
>
>> Hi Russell-
>>
>> Will you have time to update this patch?  If not, I'm happy to revise it
>> to handle the cases this weekend.  We're getting close to rc2 and I'd like
>> to get your fix in before it is released.
>>
>> Best-
>> Seth
>>
>> 2018-03-27 13:12 GMT-07:00 Seth Hillbrand <seth.hillbr...@gmail.com>:
>>
>>> Hi Russell-
>>>
>>> I was unclear.  The change in the LSET makes sense.  But it looks like
>>> you are not setting the solderpaste margin when the solderpaste layer is
>>> enabled.  I think you need to handle both the case where the paste is
>>> enabled and where it is disabled.
>>>
>>> -S
>>>
>>> 2018-03-27 12:53 GMT-07:00 Russell Oliver <roliver8...@gmail.com>:
>>>
>>>> The cream setting is the eagle equivalent to enabling/disabling the
>>>> soldering paste layer for the pad. Hence the change in the layer set.
>>>>
>>>> On Wed, 28 Mar 2018 03:14 Seth Hillbrand, <seth.hillbr...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Russell-
>>>>>
>>>>> Thanks for the patch.  However, currently, if there is no e.cream
>>>>> setting, the local solderpaste margin gets set.  In your patch, if the
>>>>> setting is missing, that doesn't happen.
>>>>>
>>>>> Is this your intention?
>>>>>
>>>>> -S
>>>>>
>>>>> 2018-03-27 5:06 GMT-07:00 Russell Oliver <roliver8...@gmail.com>:
>>>>>
>>>>>> This fixes the issue where the cream setting is ignored when setting
>>>>>> the layer set for the pad, but the bug report also mentions that the
>>>>>> rotation for rectangles are ignored during import. They rectangle is
>>>>>> niavely converted to a polygon.
>>>>>>
>>>>>> ___
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>
>>


0001-Eagle-Import-Correct-layer-set-based-on-cream-settin.patch
Description: Binary data
___
Mailing list: https://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] Partial fix for bug #1758747 Import Eagle Project ignores cream="no" option

[Russell Oliver]

No I won't have time to.

There is still the issue of Eagle rectangles with a rotation applied not
being imported correctly too.

On Sat, 31 Mar 2018 14:03 Seth Hillbrand, <seth.hillbr...@gmail.com> wrote:

> Hi Russell-
>
> Will you have time to update this patch?  If not, I'm happy to revise it
> to handle the cases this weekend.  We're getting close to rc2 and I'd like
> to get your fix in before it is released.
>
> Best-
> Seth
>
> 2018-03-27 13:12 GMT-07:00 Seth Hillbrand <seth.hillbr...@gmail.com>:
>
>> Hi Russell-
>>
>> I was unclear.  The change in the LSET makes sense.  But it looks like
>> you are not setting the solderpaste margin when the solderpaste layer is
>> enabled.  I think you need to handle both the case where the paste is
>> enabled and where it is disabled.
>>
>> -S
>>
>> 2018-03-27 12:53 GMT-07:00 Russell Oliver <roliver8...@gmail.com>:
>>
>>> The cream setting is the eagle equivalent to enabling/disabling the
>>> soldering paste layer for the pad. Hence the change in the layer set.
>>>
>>> On Wed, 28 Mar 2018 03:14 Seth Hillbrand, <seth.hillbr...@gmail.com>
>>> wrote:
>>>
>>>> Hi Russell-
>>>>
>>>> Thanks for the patch.  However, currently, if there is no e.cream
>>>> setting, the local solderpaste margin gets set.  In your patch, if the
>>>> setting is missing, that doesn't happen.
>>>>
>>>> Is this your intention?
>>>>
>>>> -S
>>>>
>>>> 2018-03-27 5:06 GMT-07:00 Russell Oliver <roliver8...@gmail.com>:
>>>>
>>>>> This fixes the issue where the cream setting is ignored when setting
>>>>> the layer set for the pad, but the bug report also mentions that the
>>>>> rotation for rectangles are ignored during import. They rectangle is
>>>>> niavely converted to a polygon.
>>>>>
>>>>> ___
>>>>> Mailing list: https://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] Eeschema Subsheets

[Russell Oliver]

Will the new schematic file format embed subsheets? Or keep them in
separate files on disk?

On Thu, 29 Mar 2018 15:44 Andy Peters,  wrote:

>
>
> 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
>
___
Mailing list: https://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] Partial fix for bug #1758747 Import Eagle Project ignores cream="no" option

[Russell Oliver]

The cream setting is the eagle equivalent to enabling/disabling the
soldering paste layer for the pad. Hence the change in the layer set.

On Wed, 28 Mar 2018 03:14 Seth Hillbrand, <seth.hillbr...@gmail.com> wrote:

> Hi Russell-
>
> Thanks for the patch.  However, currently, if there is no e.cream setting,
> the local solderpaste margin gets set.  In your patch, if the setting is
> missing, that doesn't happen.
>
> Is this your intention?
>
> -S
>
> 2018-03-27 5:06 GMT-07:00 Russell Oliver <roliver8...@gmail.com>:
>
>> This fixes the issue where the cream setting is ignored when setting the
>> layer set for the pad, but the bug report also mentions that the rotation
>> for rectangles are ignored during import. They rectangle is niavely
>> converted to a polygon.
>>
>> ___
>> Mailing list: https://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] Partial fix for bug #1758747 Import Eagle Project ignores cream="no" option

[Russell Oliver]

This fixes the issue where the cream setting is ignored when setting the
layer set for the pad, but the bug report also mentions that the rotation
for rectangles are ignored during import. They rectangle is niavely
converted to a polygon.


0001-Eagle-Import-Correct-layer-set-based-on-cream-settin.patch
Description: Binary data
___
Mailing list: https://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] Save gates.

[Russell Oliver]

Hi All,

As a follow up to the CvPCB save button discussion, I recently got a some
feedback from my friend who is a daily user of Kicad. In his telling he
recently managed to design a circuit, export the netlist, design and the
board and export gerbers and exit kicad without saving the schematic once.
I'm pretty sure he would have been asked to save it on close but, as a
concept is/should there be a list of actions that cause a save to disk of
project files either specific, ones or the entire project? For want of a
better term in calling them save gates.

Kind Regards
Russell
___
Mailing list: https://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 6.0 work

[Russell Oliver]

Yes, I guess so, unless there is a plan with the new schematic format to
allow "unique/independent" symbols that include modifications from the
library symbol, that are only stored in the schematic.

On Thu, 22 Mar 2018 10:18 Jeff Young, <j...@rokeby.ie> wrote:

> In the Mod-Edit version only, right?  I don’t think we allow editing of
> pins at all in the schematic, do we?
>
> On 21 Mar 2018, at 21:48, Russell Oliver <roliver8...@gmail.com> wrote:
>
> Just thinking that another tab showing the list of pins and their
> properties would be a good addition to this also. If you can copy and paste
> into the grid
>
> On Wed, 21 Mar 2018 23:34 Wayne Stambaugh, <stambau...@gmail.com> wrote:
>
>> Jeff,
>>
>> Looks good to me.  I prefer the in place editing so go ahead and apply
>> this where it makes sense.  I don't like the bare bones properties
>> either.  If wxGrid provides a simple way to hide them, let the user
>> decide which properties to show and/or hide.  There may be use cases
>> where the user would want to manually edit coordinates, orientation,
>> etc.  I see no reason for the artificial limit.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 3/20/2018 6:35 AM, Jeff Young wrote:
>> > Sometimes wxWidgets is your friend.  Turns out we automatically get a
>> > context menu if you click on the header which allows you to set which
>> > columns are displayed.  I’m still not a huge fan of the bare-bones
>> > approach (first 3 columns only), so I’d suggest this as a default:
>> >
>> >
>> > Is everyone happy enough with the idea of in-place field editing through
>> > a grid control that I should carry on with the LibEdit and Footprint
>> > versions?
>> >
>> > (Additional specific feedback on any of the dialogs shown also
>> welcomed.)
>> >
>> > Cheers,
>> > Jeff.
>> >
>> >
>> >> On 18 Mar 2018, at 00:52, Jeff Young <j...@rokeby.ie
>> >> <mailto:j...@rokeby.ie>> wrote:
>> >>
>> >> > I would hide the text properties (with the exception of Show) by
>> >> default.
>> >>
>> >> We do something similar for the Fields Editor:
>> >>
>> >> 
>> >>
>> >> … but it definitely adds a lot of visual complexity to the dialog.
>> >>
>> >> Cheers,
>> >> Jeff.
>> >>
>> >>
>> >>> On 18 Mar 2018, at 00:36, hauptmech <hauptm...@gmail.com
>> >>> <mailto:hauptm...@gmail.com>> wrote:
>> >>>
>> >>> On 18/03/18 03:58, Thomas Pointhuber wrote:
>> >>>> I would hide the text properties (with the exception of Show) by
>> >>>> default. I don't think many people would change for example the
>> position
>> >>>> or orientation using this dialog. Every text attribute also has its
>> own
>> >>>> menu as well which can be used for editing. Instead use the gained
>> space
>> >>>> to add a footprint preview as it was developed for the symbol
>> chooser.
>> >>>> It's annoying to first click on the footprint row to be able to
>> >>>> view/change it.
>> >>>
>> >>> I agree.
>> >>>
>> >>>
>> >>> ___
>> >>> Mailing list: https://launchpad.net/~kicad-developers
>> >>> Post to : kicad-developers@lists.launchpad.net
>> >>> <mailto: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
>> >> <mailto:kicad-developers@lists.launchpad.net>
>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>> >> More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Feedback on 6.0 work

[Russell Oliver]

Just thinking that another tab showing the list of pins and their
properties would be a good addition to this also. If you can copy and paste
into the grid

On Wed, 21 Mar 2018 23:34 Wayne Stambaugh,  wrote:

> Jeff,
>
> Looks good to me.  I prefer the in place editing so go ahead and apply
> this where it makes sense.  I don't like the bare bones properties
> either.  If wxGrid provides a simple way to hide them, let the user
> decide which properties to show and/or hide.  There may be use cases
> where the user would want to manually edit coordinates, orientation,
> etc.  I see no reason for the artificial limit.
>
> Cheers,
>
> Wayne
>
> On 3/20/2018 6:35 AM, Jeff Young wrote:
> > Sometimes wxWidgets is your friend.  Turns out we automatically get a
> > context menu if you click on the header which allows you to set which
> > columns are displayed.  I’m still not a huge fan of the bare-bones
> > approach (first 3 columns only), so I’d suggest this as a default:
> >
> >
> > Is everyone happy enough with the idea of in-place field editing through
> > a grid control that I should carry on with the LibEdit and Footprint
> > versions?
> >
> > (Additional specific feedback on any of the dialogs shown also welcomed.)
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 18 Mar 2018, at 00:52, Jeff Young  >> > wrote:
> >>
> >> > I would hide the text properties (with the exception of Show) by
> >> default.
> >>
> >> We do something similar for the Fields Editor:
> >>
> >> 
> >>
> >> … but it definitely adds a lot of visual complexity to the dialog.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 18 Mar 2018, at 00:36, hauptmech  >>> > wrote:
> >>>
> >>> On 18/03/18 03:58, Thomas Pointhuber wrote:
>  I would hide the text properties (with the exception of Show) by
>  default. I don't think many people would change for example the
> position
>  or orientation using this dialog. Every text attribute also has its
> own
>  menu as well which can be used for editing. Instead use the gained
> space
>  to add a footprint preview as it was developed for the symbol chooser.
>  It's annoying to first click on the footprint row to be able to
>  view/change it.
> >>>
> >>> I agree.
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> 
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] CvPcb Save

[Russell Oliver]

Blind saving from CvPCB to memory or disk?

IMO, saving the schematic to disk should be done consciously by the user,
from the main window of eeschema. Closing the CvPCB should silently update
the footprint links on the schematic in memory.

On Wed, 21 Mar 2018 07:10 Jeff Young, <j...@rokeby.ie> wrote:

> FWIW, I implemented blind-saving the schematic from CvPcb’s Save command
> so I could play around with it, and it feels natural enough...
>
> On 20 Mar 2018, at 19:44, Jeff Young <j...@rokeby.ie> wrote:
>
> I think the cleanest user model would be to make both CvPcb and the Symbol
> Table alternative views of the document.  However, that either suggests a
> tabbed presentation (where two views are not visible at once), or hooking
> up CvPcb and the Symbol Table to reflect changes made in the schema.
>
> Given that the normal use-case is more batch-oriented (the user has other
> tools to do single associations or edit single symbol fields), I don’t
> think it warrants that kind of investment.
>
> So that means we’re stuck with a more modal approach.  (Note that while
> CvPcb is the equivalent of modeless today, it doesn’t update in real-time,
> and silently drops changes made to symbols which no longer exist in the
> schema.)
>
> It sounds like we’re coalescing around having save be active in the
> (modal) dialogs.  How do we communicate that?  Perhaps just a “Save” button
> in the dialog is good enough — it both gives them the idea that this is
> just a dialog to the parent application (so “obviously” Save will save the
> parent schematic), and at least a clue that they can cmd-S as well.
>
> If that’s the direction we want to move in, then I can just have CvPcb’s
> Save write the schema to disk for 5.0.  Re-presenting CvPcb as a dialog is
> probably too large (ie: risky) for 5.0.
>
>
>
> On 20 Mar 2018, at 18:00, Bernhard Stegmaier <stegma...@sw-systems.de>
> wrote:
>
> On a second thought it is basically just another special “Symbol Table”
> edit dialog.
>
> The problem of losing a lot of unsaved work in case of a crash is also
> there for the “Symbol Table” dialog.
> I could hack in a lot of valuable data in custom fields and although this
> dialog has an “Apply” button, you can’t save there.
> I don’t know if some autosave would take care of it…
>
> So, however it is done wrt save/apply it should be the same for both
> “dialogs”.
>
>
> Regards,
> Bernhard
>
> On 20. Mar 2018, at 18:55, Jon Evans <j...@craftyjon.com> wrote:
>
> Yeah I also agree that it should be basically a dialog of eeschema rather
> than a separate program, so I guess it makes sense to write changes
> immediately to the in-memory schematic, and mark it as unsaved for the user
> to consciously hit the save button later if desired.
>
> -Jon
>
> On Tue, Mar 20, 2018 at 1:52 PM, Russell Oliver <roliver8...@gmail.com>
> wrote:
>
>> I second Bernhard's comments.
>> I think it shouldn't seem like a separate program, just another dialog of
>> eeschema that takes the what you see is what you get approach.
>> As long as the footprint references are valid the schematic should be
>> updated when the dialog is closed, and marked modified if there was a
>> change.
>> Saving the schematic to file is then done through eeschema proper.
>>
>> Russell
>>
>> On Wed, 21 Mar 2018 04:40 Bernhard Stegmaier, <stegma...@sw-systems.de>
>> wrote:
>>
>>> Just my 2 cents…
>>> I would immediately write back any change in cvpcb to schematic.
>>> I never understood why I have to hit the button to do that.
>>> There is no PCB preview or something like that in cvpcb, so I have to
>>> apply all changes anyway to check them directly in the PCB.
>>> Then, keep the button and save schematic with it.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 20. Mar 2018, at 18:28, Jon Evans <j...@craftyjon.com> wrote:
>>>
>>> Why don't you like the idea of saving the schematic when you hit the
>>> save button? That seems like a reasonable expected behavior to me at least.
>>>
>>> (I dislike nag dialogs especially when they seem to have no purpose)
>>>
>>> -Jon
>>>
>>> On Tue, Mar 20, 2018 at 1:26 PM, Jeff Young <j...@rokeby.ie> wrote:
>>>
>>>> CvPcb has a Save command (complete with disk icon).  Only it doesn’t do
>>>> that.  (It simply writes the changes back to eeschema.)
>>>>
>>>> If it were a dialog, I’d say that’s not good.  But this is CvPcb, where
>>>> you could easily spend an hour making associations (hitting 

Re: [Kicad-developers] CvPcb Save

[Russell Oliver]

I second Bernhard's comments.
I think it shouldn't seem like a separate program, just another dialog of
eeschema that takes the what you see is what you get approach.
As long as the footprint references are valid the schematic should be
updated when the dialog is closed, and marked modified if there was a
change.
Saving the schematic to file is then done through eeschema proper.

Russell

On Wed, 21 Mar 2018 04:40 Bernhard Stegmaier, 
wrote:

> Just my 2 cents…
> I would immediately write back any change in cvpcb to schematic.
> I never understood why I have to hit the button to do that.
> There is no PCB preview or something like that in cvpcb, so I have to
> apply all changes anyway to check them directly in the PCB.
> Then, keep the button and save schematic with it.
>
>
> Regards,
> Bernhard
>
> On 20. Mar 2018, at 18:28, Jon Evans  wrote:
>
> Why don't you like the idea of saving the schematic when you hit the save
> button? That seems like a reasonable expected behavior to me at least.
>
> (I dislike nag dialogs especially when they seem to have no purpose)
>
> -Jon
>
> On Tue, Mar 20, 2018 at 1:26 PM, Jeff Young  wrote:
>
>> CvPcb has a Save command (complete with disk icon).  Only it doesn’t do
>> that.  (It simply writes the changes back to eeschema.)
>>
>> If it were a dialog, I’d say that’s not good.  But this is CvPcb, where
>> you could easily spend an hour making associations (hitting save every few
>> minutes), only to have your machine and/or Kicad go down with all your
>> changes.  That’s borderline horrific.
>>
>> I don’t like the idea of blind-saving the eeschema document, but I think
>> that would be better than what we have now.
>>
>> Another idea would be to trigger an auto-save for each CvPcb save.  It’s
>> not ideal because the user may think that there aren’t any changes in their
>> eeschema file and therefore ignore the auto-save warning when restarting.
>>
>> Yet another idea would be to foist the decision on the user with a “Save
>> your schematic?” dialog every time you save in CvPcb.  That’s pretty hard
>> to love, but with Orson’s new KIDIALOG we could at least have a “don’t ask
>> me again” checkbox.  Maybe that’s not so bad….
>>
>> 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
>
___
Mailing list: https://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] Dynamic text in schematic and board.

[Russell Oliver]

Hi JP,

Not much really, but would extend the idea to the PCB text and to other
parameters. The user in the forum requested the ability to dynamically
display pad netnames on the silkscreen for example. I think this would be
done as
Including the ability to automatically silkscreen project names, filenames,
modification dates etc to the board would be good too.

Russell



On Mon, Mar 12, 2018 at 6:47 PM jp charras <jp.char...@wanadoo.fr> wrote:

> Le 12/03/2018 à 01:03, Jon Evans a écrit :
> > I think there are perhaps two different features here:
> >
> > 1) an easy way to create a text item that displays an object property
> (in schematic or layout).  In
> > the eventual properties editor, I'm imagining some kind of "show/hide"
> checkbox that when checked
> > creates the text.
> >
> > 2) a text substitution system a la Altium Designer, that lets you
> reference various properties in
> > the value of a text field (so escaped macros, not a dropdown).  This one
> seems less critical if #1
> > is implemented, but it still lets you do some cool stuff.
> >
> > For #1, here's a screenshot of the Altium component properties dialog:
> >
> http://wiki.altium.com/download/attachments/3080263/Component+Properties+Dialog.png
> >
> > (I'm not saying we should necessarily clone Altium, but it's an easy way
> to refer to this feature)
> > You can see in the upper right there is a grid of parameters, which can
> come in from the library and
> > can also be added / edited by the user.
> > For each of them, there is a "visible" checkbox on the left, and if you
> check it, that parameter
> > value will show up on the schematic (and it works in a similar way for
> layout)
>
> These parameters look to me like very similar to our symbol fields.
> Apart the dialog, what is different?
>
> >
> > Here's another example, from Mentor Graphics PADS:
> >
> https://mgc-images.imgix.net/pads_com/pads-c0d37eb2-36c2-44d8-b394-a7fd07861718.png
> >
> > The item properties are accessed through a dockable window that in this
> screenshot is on the right side.
> > The properties are a key/value system, and you can see that there are
> checkboxes for both the keys
> > and the values.
> > If you have a property named "TOLERANCE" with value "10%", you can check
> the value box and get a
> > label saying "10%",
> > or check both boxes to get a label saying "TOLERANCE=10%"
> >
> > -Jon
> >
> > On Sun, Mar 11, 2018 at 7:50 PM, Russell Oliver <roliver8...@gmail.com
> > <mailto:roliver8...@gmail.com>> wrote:
> >
> > Jon,
> >
> > Any thoughts on how you envisage this working? Text substitution
> through using escaped macros or
> > a direct reference that can be picked via say a dropdown box in the
> dialog?
> >
> >
> >
> > On Mon, Mar 12, 2018 at 5:34 AM Jon Evans <j...@craftyjon.com
> <mailto:j...@craftyjon.com>> wrote:
> >
> > Display net name of pad automatically:  You can use this to
> auto-label test points with the
> > net name they are connected to, for example
> >
> > Other places where text substitution is useful to me:
> >
> > - Set project-level properties, like schematic title, part
> number, revision, etc.  Have it
> > automatically show up on every sheet title block and stay in
> sync on the board silkscreen layer.
> >
> > - Add lots of properties to parts (i.e. resistors get voltage,
> tolerance, tempco, etc) and
> > automatically show these as labels on the schematic next to
> refdes and value
> >
> > -Jon
> >
> > On Sun, Mar 11, 2018 at 11:56 AM, Nick Østergaard <
> oe.n...@gmail.com
> > <mailto:oe.n...@gmail.com>> wrote:
> >
> > Den 8. mar. 2018 22.39 skrev "Russell Oliver" <
> roliver8...@gmail.com
> > <mailto:roliver8...@gmail.com>>:
> >
> > As a follow up to the road map discussion I saw a forum
> post asking if it was
> > possible to display the net name of a pad on the
> silkscreen or other layers much
> > like the value or reference fields.
> >
> >
> > Why is this useful? Could you explain the exact use case?
> >
> >
> > While a simple implementation would be to create a text
> item directly linked to each
> > pad that could be enabled, and shows the link to the
>

Re: [Kicad-developers] [RFC] Dynamic text in schematic and board.

[Russell Oliver]

Jon,

Any thoughts on how you envisage this working? Text substitution through
using escaped macros or a direct reference that can be picked via say a
dropdown box in the dialog?



On Mon, Mar 12, 2018 at 5:34 AM Jon Evans <j...@craftyjon.com> wrote:

> Display net name of pad automatically:  You can use this to auto-label
> test points with the net name they are connected to, for example
>
> Other places where text substitution is useful to me:
>
> - Set project-level properties, like schematic title, part number,
> revision, etc.  Have it automatically show up on every sheet title block
> and stay in sync on the board silkscreen layer.
>
> - Add lots of properties to parts (i.e. resistors get voltage, tolerance,
> tempco, etc) and automatically show these as labels on the schematic next
> to refdes and value
>
> -Jon
>
> On Sun, Mar 11, 2018 at 11:56 AM, Nick Østergaard <oe.n...@gmail.com>
> wrote:
>
>> Den 8. mar. 2018 22.39 skrev "Russell Oliver" <roliver8...@gmail.com>:
>>
>> As a follow up to the road map discussion I saw a forum post asking if it
>> was possible to display the net name of a pad on the silkscreen or other
>> layers much like the value or reference fields.
>>
>>
>> Why is this useful? Could you explain the exact use case?
>>
>>
>> While a simple implementation would be to create a text item directly
>> linked to each pad that could be enabled, and shows the link to the
>> relevant pad,  I think a more generic approach would be great to have.
>>
>> I propose that either or both of these options for version 7.
>>
>> a) standalone text items are processed as a template.  A domain specific
>> language would be designed to allow for references to items as direct text
>> substitutions. The implementation, scope and style of this DSL will need to
>> be workshopped and would like your comments on.
>>
>> b) linked text (annotations) showing a graphical link (like the blue line
>> of values and reference ) A text item is created as a link to another item,
>> for which the text is derived from a list of properties of that item. This
>> would include such things as values, references, custom symbol and
>> footprint fields, sizes, positions, net names, net codes.
>>
>> I'm almost certain this would require the updated Schematic object in
>> eeschema, but might already be achievable in pcbnew given its current
>> architecture, but that's more of a guess than anything.
>>
>> Any thoughts, guidance or critiques would be appreciated.
>>
>> Kind Regards
>> Russell
>>
>>
>> ___
>> Mailing list: https://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] Dynamic text in schematic and board.

[Russell Oliver]

I think then that both approaches will rely on an improved object
properties system.
Is there any roadmap on how this will work? I had a thought that it would
be great if everything was kept in a key/value database but that would be
pretty slow.

Russell



On Fri, Mar 9, 2018 at 8:59 AM Jon Evans <j...@craftyjon.com> wrote:

> I think option A is a good feature to add across schematic and layout. A
> macro substitution system for text is very handy especially as we introduce
> a better object properties system.
>
> For example, it would be nice if we could assign arbitrary properties to
> the project as a whole, as well as each schematic  sheet. Then, you can
> refer to these properties in text fields. Useful for schematic templates
> and other things like that.
>
> B is also good.  In Altium you can show/hide any properties of an object,
> which seamlessly creates a "linked" text object as you describe when you
> choose "show".  This is a really nice system.
>
> -Jon
>
>
> On Thu, Mar 8, 2018, 16:39 Russell Oliver <roliver8...@gmail.com> wrote:
>
>> As a follow up to the road map discussion I saw a forum post asking if it
>> was possible to display the net name of a pad on the silkscreen or other
>> layers much like the value or reference fields.
>>
>> While a simple implementation would be to create a text item directly
>> linked to each pad that could be enabled, and shows the link to the
>> relevant pad,  I think a more generic approach would be great to have.
>>
>> I propose that either or both of these options for version 7.
>>
>> a) standalone text items are processed as a template.  A domain specific
>> language would be designed to allow for references to items as direct text
>> substitutions. The implementation, scope and style of this DSL will need to
>> be workshopped and would like your comments on.
>>
>> b) linked text (annotations) showing a graphical link (like the blue line
>> of values and reference ) A text item is created as a link to another item,
>> for which the text is derived from a list of properties of that item. This
>> would include such things as values, references, custom symbol and
>> footprint fields, sizes, positions, net names, net codes.
>>
>> I'm almost certain this would require the updated Schematic object in
>> eeschema, but might already be achievable in pcbnew given its current
>> architecture, but that's more of a guess than anything.
>>
>> Any thoughts, guidance or critiques would be appreciated.
>>
>> Kind Regards
>> Russell
>>
>> ___
>> Mailing list: https://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] Proposed roadmap changes

[Russell Oliver]

>From what I am reading John your call for acting on the files on disk
instead of memory is a call for a clear demarcation of actions that need to
be irrevocable and require the project data to be consistent.

In my opinion this doesn't necessarily require separate programs, just
consistent checks on the current state of the project and its data. A check
and dialog box to force the user to save the all schematic sheets before
exporting the netlist might be sufficient.

Likewise saving the pcb after changing say a selected footprint or changing
the reference or value of a component, would force a back annotation of the
schematic which would also be saved. A change would not be allowed to
persist without it being consistently applied across the project.






On Thu, 8 Mar 2018 15:22 Ouabache Designworks,  wrote:

>
>
> On Wed, Mar 7, 2018 at 8:01 PM, José Ignacio 
> wrote:
>
>> The separate program issue is just an implementation detail. The main
>> thing that Kicad is headed for is the refactoring slated for the 6.0 dev
>> cycle. The cleaner data structure foundation and subsequent decoupling of
>> the logic from the UI classes will allow all sorts of automation that are
>> currently very hard or impossible. The vision that was set since over 5
>> years ago was for Kicad to present a library-like interface to the outside
>> world. It kind of does now on PCBnew only, but things are slowly improving
>> as things get refactored and legacy code gets phased out.
>>
>> I honestly think the last thing Kicad needs right now is a chance of
>> direction, I speak as a user that has been using Kicad professionally for
>> just over 2 years now, working on dozens of PCB projects over that time.
>> The developments in the past few years have been nothing but awesome for a
>> project with Kicad's resources. We just need to be patient, or try to help
>> out in a constructive manner.
>>
>> Over the past couple years I have been using the dev version in
>> production to take advantage of the new features (dealing with
>> versions/instability was a small price to pay for me), I also helped a
>> little bit (as time allowed) with the occasional patch or grumpy bug
>> report. I'd like to thank everyone that has worked on the project so far;
>> It basically has made it possible for me to make a living doing what I
>> enjoy, and I really hope the project can retain the momentum it has built
>> up in the past few months, it just keeps getting better!
>>
>> Thanks,
>> Jose
>>
>>
>>
>
> Nothing that I am asking for is a change of direction. Instead of calling
> a function that operates on data in memory you call a program that operates
> on the same data in the file system.
> You see the same menu pick either way. This will fit in with the
> refactoring.
>
> 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.
>
> John Eaton
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] - File format shim for clearance data

[Russell Oliver]

Forgive my ignorance but why would storing the clearance for each track
segment (if required to by design intent) conflict with a sophisticated
design rule management system?
As a general approach shouldn't KiCad allow freedom of design when the
intention of the designer is clear?

Russell




On Wed, Mar 7, 2018 at 9:30 PM Tomasz Wlostowski 
wrote:

> On 07/03/18 11:02, hauptmech wrote:
> > I have a patch for treating track clearance the same as track width. The
> > user can already specify a track width that is an exception to the
> > netclass width, and now do the same for clearance. (
> > https://youtu.be/05vfAvYwDio )
>
> Hi hauptmech,
>
> I'm sorry but IMHO we can't accept your patch:
> - it changes the file format while we are already in feature freeze.
> This is a way too big change to accept for the V5.
> - we are planning to overhaul the clearance/design rules system in V6.
> Storing the clearance *DIRECTLY* for each track segment/via will
> conflict with any more sophisticated design rule management system.
>
> Tom
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [fun feature request] Create PCB from schematic with one click :)

[Russell Oliver]

I didn't mean to infer that the final location of a part would be
determined by the schematic, just the initial placement of parts in pcbnew
when the netlist is first read. Similar to the spread out all components
tool. A starting point.

I can also imagine a tool that would try to minimise the overall bounding
box of the selection, with maybe a specified minimum gap.

I think there exists plenty of scope for semi automatic processes to boost
designer productivity; dragging tracks attached to a component, grouping
tools, pin swapping. Single/differential track autorouting i.e select a net
or pair and auto route it and present multiple alternatives. Much like the
alternative routes in say Google maps.

And many more that are probably all ready thought of and have been made
into a script.




On Tue, 6 Mar 2018 07:53 Andy Peters, <de...@latke.net> wrote:

>
> > On Mar 5, 2018, at 11:49 AM, Russell Oliver <roliver8...@gmail.com>
> wrote:
> >
> > In terms of automatically arranging  components a force directed graph
> algorithm may work quite nicely, especially if the algorithm is seeded with
> the layout of components on the schematic.
> >
> > A simplistic version would be to just arrange components on board sheet
> as to their position on the schematic sheets.
>
> That approach might be fine for something like a VME CPU board filled with
> 74xxx TTL parts, but modern designs have too many other considerations. For
> example, most things fit into some kind of enclosure, and as such the
> mechanical constraints matter, and then trying to draw a schematic to
> represent placement can make a mess of things. What if the person drawing
> the schematic has no idea at the start what kind of enclosure will be used?
>
> The “seeding” can be in some cases inferred from the netlist and
> connections. This goes to that, that goes to something else, and this that
> there ends up being in the middle. pcbnew’s netlist import generally keeps
> parts on the same schematic page together. Start with stuff that needs to
> be located specifically because of mechanical concerns. It usually turns
> out that parts will go whether they need to go, and that becomes obvious
> once you have them all on the canvas and the rats nest is visible. You
> start with the big parts and fit the supporting parts around them.
>
> I can’t think of any board I’ve done in the last {harumph!} years where I
> drew the schematic in a way that reflected the final parts placement.
>
> -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
>
___
Mailing list: https://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 :)

[Russell Oliver]

The "spring" constants in a force directed graph algorithm could be set by
a user given priority or even by the length of schematic wires.

On Tue, 6 Mar 2018 05:53 Jon Evans, <j...@craftyjon.com> wrote:

> In many commercial tools you can use some or another feature to mark up
> the design at the schematic level with what components "go together".
> Then that information is used during PCB placement, the first-pass arrange
> of components when you start designing a board can place those components
> together, but it is also possible to group them together and move as a
> group easily, etc.
>
> There are even some tools that automatically identify bypass capacitors
> (did the schematic have a capacitor drawn right near a pin on an IC?  In
> that case, assume it's a bypass cap) and can place them right near the IC
> (and run ERCs to make sure you don't have missing bypass caps, DRC to make
> sure they are close enough to the power pin in the layout, etc)
>
>
>
> On Mon, Mar 5, 2018 at 1:49 PM, Russell Oliver <roliver8...@gmail.com>
> wrote:
>
>> In terms of automatically arranging  components a force directed graph
>> algorithm may work quite nicely, especially if the algorithm is seeded with
>> the layout of components on the schematic.
>>
>> A simplistic version would be to just arrange components on board sheet
>> as to their position on the schematic sheets.
>>
>>
>> On Tue, 6 Mar 2018 05:07 Andy Peters, <de...@latke.net> wrote:
>>
>>>
>>>
>>> > On Mar 5, 2018, at 10:49 AM, Wayne Stambaugh <stambau...@gmail.com>
>>> 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
>>>
>>
>> ___
>> Mailing list: https://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] [fun feature request] Create PCB from schematic with one click :)

[Russell Oliver]

In terms of automatically arranging  components a force directed graph
algorithm may work quite nicely, especially if the algorithm is seeded with
the layout of components on the schematic.

A simplistic version would be to just arrange components on board sheet as
to their position on the schematic sheets.

On Tue, 6 Mar 2018 05:07 Andy Peters,  wrote:

>
>
> > 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
>
___
Mailing list: https://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] Improving Eagle Import netlist matching

[Russell Oliver]

Hi Orson,

All I can say is thanks for taking the time to polish this further.

Just went through the matching code and am now kicking myself that i didn't
think of that approach before.

Good pick up on the missing junctions.

Kind Regards
Russell


On 28 Feb 2018 22:14, "Maciej Sumiński" <maciej.sumin...@cern.ch> wrote:

> I think I have finally reached the point where I am completely satisfied
> with the Eagle import results. I do not see any changes when invoking
> 'Update PCB from schematics'. No connectivity issues observed and pretty
> local net labels are used whenever possible.
>
> Thank you Russell, your patch to use local net labels where applicable
> works fine - I have no idea what went wrong on my side previously. Your
> net remapping algorithm for zones also helped, but I had to change it a
> bit.
>
> There are some more patches [1], as I have discovered a few other issues
> that needed fixing:
>
> - Changed the zone/track/via net remapping algorithm to handle unnamed
> nets. The new algorithm maps net names to pads before and after netlist
> updates. Then it is easy to compare the maps and apply the same net name
> changes to tracks and zones.
>
> - Added junction dots when necessary. It turns out if a pin is placed
> perpendicular to a wire, then eeschema does not recognize it as
> connected whereas Eagle does. Normally one gets a junction dot in such
> places when a component is placed manually, so it is done for imported
> schematics as well.
>
> - Adjusted footprint LIB_IDs in imported schematics and board files to
> point to the imported Eagle library.
>
> I will leave the branch for testing for a few days to see if there are
> any problems reported. I am going to merge the branch during the weekend.
>
> Cheers,
> Orson
>
> 1.
> https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+
> ref/eagle_import_fixes
>
> On 02/26/2018 12:10 PM, Russell Oliver wrote:
> > Awesome,
> >
> > I'm excited to finally see v5 come to pass. I think we should nickname
> the
> > release, Godot, since we have all be waiting for it for so long.
> >
> > Russ
> >
> > On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński <maciej.sumin...@cern.ch
> >
> > wrote:
> >
> >> Hi Russell,
> >>
> >> I plan to merge your changes, I have almost finished the refactor to use
> >> KiWay mail. I will test the patches a bit and given no extra issues
> >> appear, I will push them to the master branch.
> >>
> >> Regards,
> >> Orson
> >>
> >> On 02/25/2018 10:30 PM, Russell Oliver wrote:
> >>> Just wondering what approach we are going to use for v5? Global labels
> or
> >>> my latest matching algorithm?
> >>>
> >>> Kind Regards
> >>> Russell
> >>>
> >>>
> >>>
> >>> On 25 Feb 2018 08:43, "Russell Oliver" <roliver8...@gmail.com> wrote:
> >>>
> >>>> Hi Orson,
> >>>>
> >>>> I looked at the Kicad project from the and I don't see any global
> >> labels,
> >>>> just local labels. The PCB will still have the global nets though,
> since
> >>>> they are created during import of the eagle pcb file.
> >>>> Just to be clear my patches are intended to only generate global
> labels
> >>>> when necessary, which should only occur when there are multiple sheets
> >> in
> >>>> the original Eagle schematic.
> >>>>
> >>>> Russell
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <
> >> maciej.sumin...@cern.ch>
> >>>> wrote:
> >>>>
> >>>>> Hi Russell,
> >>>>>
> >>>>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
> >>>>>> Hi Orson,
> >>>>>>
> >>>>>> I wasn't sure about using the KiMail, since I didn't know how
> >> immediate
> >>>>>> those calls are processed plus I didn't have the time to implement
> it
> >>>>> using
> >>>>>> that anyway.
> >>>>>
> >>>>> That is fine, no problem. I realize it takes more time and is a bit
> >>>>> clunky compared to direct function calling, but I can refactor the
> code
> >>>>> to use KiMail.
> >>>>>
> >>>>>> I'm a bit puzzled by the statement that you are getting global
> labels
> >>&

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Awesome,

I'm excited to finally see v5 come to pass. I think we should nickname the
release, Godot, since we have all be waiting for it for so long.

Russ

On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński <maciej.sumin...@cern.ch>
wrote:

> Hi Russell,
>
> I plan to merge your changes, I have almost finished the refactor to use
> KiWay mail. I will test the patches a bit and given no extra issues
> appear, I will push them to the master branch.
>
> Regards,
> Orson
>
> On 02/25/2018 10:30 PM, Russell Oliver wrote:
> > Just wondering what approach we are going to use for v5? Global labels or
> > my latest matching algorithm?
> >
> > Kind Regards
> > Russell
> >
> >
> >
> > On 25 Feb 2018 08:43, "Russell Oliver" <roliver8...@gmail.com> wrote:
> >
> >> Hi Orson,
> >>
> >> I looked at the Kicad project from the and I don't see any global
> labels,
> >> just local labels. The PCB will still have the global nets though, since
> >> they are created during import of the eagle pcb file.
> >> Just to be clear my patches are intended to only generate global labels
> >> when necessary, which should only occur when there are multiple sheets
> in
> >> the original Eagle schematic.
> >>
> >> Russell
> >>
> >>
> >>
> >> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <
> maciej.sumin...@cern.ch>
> >> wrote:
> >>
> >>> Hi Russell,
> >>>
> >>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
> >>>> Hi Orson,
> >>>>
> >>>> I wasn't sure about using the KiMail, since I didn't know how
> immediate
> >>>> those calls are processed plus I didn't have the time to implement it
> >>> using
> >>>> that anyway.
> >>>
> >>> That is fine, no problem. I realize it takes more time and is a bit
> >>> clunky compared to direct function calling, but I can refactor the code
> >>> to use KiMail.
> >>>
> >>>> I'm a bit puzzled by the statement that you are getting global labels
> >>> using
> >>>> the Arduino project. Can you send me your copy of the project and the
> >>> kicad
> >>>> files that are generated?
> >>>
> >>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
> >>> import result to my private server [2].
> >>>
> >>> Best regards,
> >>> Orson
> >>>
> >>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
> >>> ref-design.zip
> >>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
> >>>
> >>>> Kind Regards
> >>>> Russell
> >>>>
> >>>> On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <
> >>> maciej.sumin...@cern.ch>
> >>>> wrote:
> >>>>
> >>>>> Hi Russell,
> >>>>>
> >>>>> I am grateful for your continuous support. I confirm your patch
> handles
> >>>>> local net labels and zones in the attached example
> (orphanzonetest.zip)
> >>>>> correctly, but I am still getting global labels with the Arduino
> >>> project
> >>>>> mentioned by Wayne. Reverting "Fix netlist mapping for zones and
> vias"
> >>>>> is enough to get them back. I will have a look at it soon, but if you
> >>>>> see an obvious fix, do not hesitate to tell me.
> >>>>>
> >>>>> There is at least one thing that needs to be fixed, but I can handle
> >>> it.
> >>>>> One should not extend KIWAY_PLAYER interface with application
> specific
> >>>>> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
> >>>>> simple IPC. I see it had been accepted before, but probably as an
> >>>>> overlook. I have already fixed it for netlist read and generate
> methods
> >>>>> (9e80eff9), one more on my to-do list is ImportFile().
> >>>>>
> >>>>> I also noticed that my two stage netlist update does not always
> update
> >>>>> timestamps in pcbnew, so there is one more thing I should fix.
> >>>>>
> >>>>> To sum up: I am going to merge your patch and apply necessary
> >>>>> KIWAY_PLAYER interface fixes. There are still two issues to address:
> >>>>> - glob

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Just wondering what approach we are going to use for v5? Global labels or
my latest matching algorithm?

Kind Regards
Russell



On 25 Feb 2018 08:43, "Russell Oliver" <roliver8...@gmail.com> wrote:

> Hi Orson,
>
> I looked at the Kicad project from the and I don't see any global labels,
> just local labels. The PCB will still have the global nets though, since
> they are created during import of the eagle pcb file.
> Just to be clear my patches are intended to only generate global labels
> when necessary, which should only occur when there are multiple sheets in
> the original Eagle schematic.
>
> Russell
>
>
>
> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <maciej.sumin...@cern.ch>
> wrote:
>
>> Hi Russell,
>>
>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
>> > Hi Orson,
>> >
>> > I wasn't sure about using the KiMail, since I didn't know how immediate
>> > those calls are processed plus I didn't have the time to implement it
>> using
>> > that anyway.
>>
>> That is fine, no problem. I realize it takes more time and is a bit
>> clunky compared to direct function calling, but I can refactor the code
>> to use KiMail.
>>
>> > I'm a bit puzzled by the statement that you are getting global labels
>> using
>> > the Arduino project. Can you send me your copy of the project and the
>> kicad
>> > files that are generated?
>>
>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
>> import result to my private server [2].
>>
>> Best regards,
>> Orson
>>
>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
>> ref-design.zip
>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
>>
>> > Kind Regards
>> > Russell
>> >
>> > On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <
>> maciej.sumin...@cern.ch>
>> > wrote:
>> >
>> >> Hi Russell,
>> >>
>> >> I am grateful for your continuous support. I confirm your patch handles
>> >> local net labels and zones in the attached example (orphanzonetest.zip)
>> >> correctly, but I am still getting global labels with the Arduino
>> project
>> >> mentioned by Wayne. Reverting "Fix netlist mapping for zones and vias"
>> >> is enough to get them back. I will have a look at it soon, but if you
>> >> see an obvious fix, do not hesitate to tell me.
>> >>
>> >> There is at least one thing that needs to be fixed, but I can handle
>> it.
>> >> One should not extend KIWAY_PLAYER interface with application specific
>> >> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
>> >> simple IPC. I see it had been accepted before, but probably as an
>> >> overlook. I have already fixed it for netlist read and generate methods
>> >> (9e80eff9), one more on my to-do list is ImportFile().
>> >>
>> >> I also noticed that my two stage netlist update does not always update
>> >> timestamps in pcbnew, so there is one more thing I should fix.
>> >>
>> >> To sum up: I am going to merge your patch and apply necessary
>> >> KIWAY_PLAYER interface fixes. There are still two issues to address:
>> >> - global labels in the Arduino test project
>> >> - unassigned timestamps in pcbnew (I think for multisheet schematics)
>> >>
>> >> Regards,
>> >> Orson
>> >>
>> >> On 02/19/2018 12:31 PM, Russell Oliver wrote:
>> >>> here are the patches again after the relevant sections being
>> >> uncrustified.
>> >>>
>> >>> Kind Regards
>> >>> Russell
>> >>>
>> >>> On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh <stambau...@gmail.com
>> >
>> >>> wrote:
>> >>>
>> >>>> This looks a lot more reasonable to me although there may be some
>> corner
>> >>>> cases that we haven't thought about but we can fix those as they pop
>> up.
>> >>>>   I'm sure user's reactions to the all global label solution will be
>> >>>> WTF.  At least that was my reaction.  The amount of work to go back
>> and
>> >>>> fix this manually could put off users.
>> >>>>
>> >>>> Orson, what are your thoughts on this patch.  I would like your input
>> >>>> before we merge this just in case you see something that I 

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Hi Orson,

I looked at the Kicad project from the and I don't see any global labels,
just local labels. The PCB will still have the global nets though, since
they are created during import of the eagle pcb file.
Just to be clear my patches are intended to only generate global labels
when necessary, which should only occur when there are multiple sheets in
the original Eagle schematic.

Russell



On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <maciej.sumin...@cern.ch>
wrote:

> Hi Russell,
>
> On 02/19/2018 08:25 PM, Russell Oliver wrote:
> > Hi Orson,
> >
> > I wasn't sure about using the KiMail, since I didn't know how immediate
> > those calls are processed plus I didn't have the time to implement it
> using
> > that anyway.
>
> That is fine, no problem. I realize it takes more time and is a bit
> clunky compared to direct function calling, but I can refactor the code
> to use KiMail.
>
> > I'm a bit puzzled by the statement that you are getting global labels
> using
> > the Arduino project. Can you send me your copy of the project and the
> kicad
> > files that are generated?
>
> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
> import result to my private server [2].
>
> Best regards,
> Orson
>
> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_
> R3-ref-design.zip
> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
>
> > Kind Regards
> > Russell
> >
> > On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <maciej.sumin...@cern.ch
> >
> > wrote:
> >
> >> Hi Russell,
> >>
> >> I am grateful for your continuous support. I confirm your patch handles
> >> local net labels and zones in the attached example (orphanzonetest.zip)
> >> correctly, but I am still getting global labels with the Arduino project
> >> mentioned by Wayne. Reverting "Fix netlist mapping for zones and vias"
> >> is enough to get them back. I will have a look at it soon, but if you
> >> see an obvious fix, do not hesitate to tell me.
> >>
> >> There is at least one thing that needs to be fixed, but I can handle it.
> >> One should not extend KIWAY_PLAYER interface with application specific
> >> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
> >> simple IPC. I see it had been accepted before, but probably as an
> >> overlook. I have already fixed it for netlist read and generate methods
> >> (9e80eff9), one more on my to-do list is ImportFile().
> >>
> >> I also noticed that my two stage netlist update does not always update
> >> timestamps in pcbnew, so there is one more thing I should fix.
> >>
> >> To sum up: I am going to merge your patch and apply necessary
> >> KIWAY_PLAYER interface fixes. There are still two issues to address:
> >> - global labels in the Arduino test project
> >> - unassigned timestamps in pcbnew (I think for multisheet schematics)
> >>
> >> Regards,
> >> Orson
> >>
> >> On 02/19/2018 12:31 PM, Russell Oliver wrote:
> >>> here are the patches again after the relevant sections being
> >> uncrustified.
> >>>
> >>> Kind Regards
> >>> Russell
> >>>
> >>> On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh <stambau...@gmail.com>
> >>> wrote:
> >>>
> >>>> This looks a lot more reasonable to me although there may be some
> corner
> >>>> cases that we haven't thought about but we can fix those as they pop
> up.
> >>>>   I'm sure user's reactions to the all global label solution will be
> >>>> WTF.  At least that was my reaction.  The amount of work to go back
> and
> >>>> fix this manually could put off users.
> >>>>
> >>>> Orson, what are your thoughts on this patch.  I would like your input
> >>>> before we merge this just in case you see something that I am missing.
> >>>>
> >>>> Russell, if we decide to merge this patch please fix you coding policy
> >>>> violations.  You are using K curly brace placement.
> >>>>
> >>>> On 02/18/2018 06:48 AM, Russell Oliver wrote:
> >>>>> Attached are patches which implement the logic below and a test eagle
> >>>>> project to demonstrate the problem.
> >>>>>
> >>>>> This patch set though includes a revert of Orsons patch to use only
> >>>>> global labels.
> >>>>> At this point before v5, I'm fin

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Hi Orson,

I wasn't sure about using the KiMail, since I didn't know how immediate
those calls are processed plus I didn't have the time to implement it using
that anyway.
I'm a bit puzzled by the statement that you are getting global labels using
the Arduino project. Can you send me your copy of the project and the kicad
files that are generated?

Kind Regards
Russell

On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <maciej.sumin...@cern.ch>
wrote:

> Hi Russell,
>
> I am grateful for your continuous support. I confirm your patch handles
> local net labels and zones in the attached example (orphanzonetest.zip)
> correctly, but I am still getting global labels with the Arduino project
> mentioned by Wayne. Reverting "Fix netlist mapping for zones and vias"
> is enough to get them back. I will have a look at it soon, but if you
> see an obvious fix, do not hesitate to tell me.
>
> There is at least one thing that needs to be fixed, but I can handle it.
> One should not extend KIWAY_PLAYER interface with application specific
> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
> simple IPC. I see it had been accepted before, but probably as an
> overlook. I have already fixed it for netlist read and generate methods
> (9e80eff9), one more on my to-do list is ImportFile().
>
> I also noticed that my two stage netlist update does not always update
> timestamps in pcbnew, so there is one more thing I should fix.
>
> To sum up: I am going to merge your patch and apply necessary
> KIWAY_PLAYER interface fixes. There are still two issues to address:
> - global labels in the Arduino test project
> - unassigned timestamps in pcbnew (I think for multisheet schematics)
>
> Regards,
> Orson
>
> On 02/19/2018 12:31 PM, Russell Oliver wrote:
> > here are the patches again after the relevant sections being
> uncrustified.
> >
> > Kind Regards
> > Russell
> >
> > On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh <stambau...@gmail.com>
> > wrote:
> >
> >> This looks a lot more reasonable to me although there may be some corner
> >> cases that we haven't thought about but we can fix those as they pop up.
> >>   I'm sure user's reactions to the all global label solution will be
> >> WTF.  At least that was my reaction.  The amount of work to go back and
> >> fix this manually could put off users.
> >>
> >> Orson, what are your thoughts on this patch.  I would like your input
> >> before we merge this just in case you see something that I am missing.
> >>
> >> Russell, if we decide to merge this patch please fix you coding policy
> >> violations.  You are using K curly brace placement.
> >>
> >> On 02/18/2018 06:48 AM, Russell Oliver wrote:
> >>> Attached are patches which implement the logic below and a test eagle
> >>> project to demonstrate the problem.
> >>>
> >>> This patch set though includes a revert of Orsons patch to use only
> >>> global labels.
> >>> At this point before v5, I'm fine with just using global labels, but I
> >>> think this patch set works well
> >>>
> >>>
> >>> Kind Regards
> >>> Russell
> >>>
> >>>
> >>>
> >>> On Sun, Feb 18, 2018 at 1:58 PM Russell Oliver <roliver8...@gmail.com
> >>> <mailto:roliver8...@gmail.com>> wrote:
> >>>
> >>> Yes there should be a way to match them up.
> >>>
> >>> The logic for it is as follows, for the complex case:
> >>>
> >>> An eagle project with 2 nets (A and B) that are used for zones and
> >>> stitching vias and each appears only on separate sheets, Y and Z
> >>> respectively.
> >>>
> >>> During the import two subsheets are created.
> >>>
> >>> After import in kicad currently each net would be given the local
> >>> net of /Y/A and /Z/B
> >>>
> >>> Pads on footprints are updated after the netlist and then propagate
> >>> to tracks and standard vias.
> >>>
> >>> This leaves the zones and stitching vias on the orphaned nets, A
> and
> >>> B. Therefore they are then set to the net with the matching local
> >>> net with the suffix "/A" and "/B".
> >>>
> >>> The original logic detected a net that appears on two eagle sheet
> >>> and used global labels, which would result in a global kicad net.
> >>>
> >>> F

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

here are the patches again after the relevant sections being uncrustified.

Kind Regards
Russell

On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh <stambau...@gmail.com>
wrote:

> This looks a lot more reasonable to me although there may be some corner
> cases that we haven't thought about but we can fix those as they pop up.
>   I'm sure user's reactions to the all global label solution will be
> WTF.  At least that was my reaction.  The amount of work to go back and
> fix this manually could put off users.
>
> Orson, what are your thoughts on this patch.  I would like your input
> before we merge this just in case you see something that I am missing.
>
> Russell, if we decide to merge this patch please fix you coding policy
> violations.  You are using K curly brace placement.
>
> On 02/18/2018 06:48 AM, Russell Oliver wrote:
> > Attached are patches which implement the logic below and a test eagle
> > project to demonstrate the problem.
> >
> > This patch set though includes a revert of Orsons patch to use only
> > global labels.
> > At this point before v5, I'm fine with just using global labels, but I
> > think this patch set works well
> >
> >
> > Kind Regards
> > Russell
> >
> >
> >
> > On Sun, Feb 18, 2018 at 1:58 PM Russell Oliver <roliver8...@gmail.com
> > <mailto:roliver8...@gmail.com>> wrote:
> >
> > Yes there should be a way to match them up.
> >
> > The logic for it is as follows, for the complex case:
> >
> > An eagle project with 2 nets (A and B) that are used for zones and
> > stitching vias and each appears only on separate sheets, Y and Z
> > respectively.
> >
> > During the import two subsheets are created.
> >
> > After import in kicad currently each net would be given the local
> > net of /Y/A and /Z/B
> >
> > Pads on footprints are updated after the netlist and then propagate
> > to tracks and standard vias.
> >
> > This leaves the zones and stitching vias on the orphaned nets, A and
> > B. Therefore they are then set to the net with the matching local
> > net with the suffix "/A" and "/B".
> >
> > The original logic detected a net that appears on two eagle sheet
> > and used global labels, which would result in a global kicad net.
> >
> > For the case where only one eagle sheet exists a local label can and
> > is used, resulting in a net local the root sheet. e.g. "/C".
> > Therefore the suffix matching will also work.
> >
> > What I will require is an easy way to get the list of nets currently
> > in the schematic inside of pcbnew . Which when I looked  before
> > didn't really exist, except for the pcb update code that uses the
> > KiMail system. At the very least a string array of unique net names
> > would be enough.
> >
> >
> > Kind Regards
> > Russell
> >
> >
> >
> >
> >
> >
> > On 18 Feb 2018 11:38, "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > I'm not too sure about our global label solution.  The results
> are
> > rather heinous.  Take a look at the Ardunino ATMega 2560
> > board[1] that I
> > demoed at FOSDEM imported using the new label semantics.  I
> > don't think
> > users are going to be OK with this.  Is there no way we can use
> > normal
> > labels properly in hierarchical Eagle schematics?
> >
> > [1]:
> >
> https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-ref-design.zip
> >
> > On 02/17/2018 05:54 AM, Maciej Suminski wrote:
> >  > Hi Russell,
> >  >
> >  > No worries, the change was easy. I was mostly interested in
> > your view
> >  > about the change, and you confirm the main concern is the
> > appearance of
> >  > imported schematics.
> >  >
> >  > I am not sure if netlist updater is able to link a symbol and
> its
> >  > corresponding footprint when sheetpath is not complete, but
> > if that is
> >  > the case then your other idea could be a better solution here.
> >  >
> >  > Best regards,
> >  > Orson
> >  >
> >  > On 02/17/2018 12:18 AM, Russell Oliver wrote:
> &g

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Yes there should be a way to match them up.

The logic for it is as follows, for the complex case:

An eagle project with 2 nets (A and B) that are used for zones and
stitching vias and each appears only on separate sheets, Y and Z
respectively.

During the import two subsheets are created.

After import in kicad currently each net would be given the local net of
/Y/A and /Z/B

Pads on footprints are updated after the netlist and then propagate to
tracks and standard vias.

This leaves the zones and stitching vias on the orphaned nets, A and B.
Therefore they are then set to the net with the matching local net with the
suffix "/A" and "/B".

The original logic detected a net that appears on two eagle sheet and used
global labels, which would result in a global kicad net.

For the case where only one eagle sheet exists a local label can and is
used, resulting in a net local the root sheet. e.g. "/C". Therefore the
suffix matching will also work.

What I will require is an easy way to get the list of nets currently in the
schematic inside of pcbnew . Which when I looked  before didn't really
exist, except for the pcb update code that uses the KiMail system. At the
very least a string array of unique net names would be enough.


Kind Regards
Russell






On 18 Feb 2018 11:38, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

> I'm not too sure about our global label solution.  The results are
> rather heinous.  Take a look at the Ardunino ATMega 2560 board[1] that I
> demoed at FOSDEM imported using the new label semantics.  I don't think
> users are going to be OK with this.  Is there no way we can use normal
> labels properly in hierarchical Eagle schematics?
>
> [1]:
> https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-ref-design.zip
>
> On 02/17/2018 05:54 AM, Maciej Suminski wrote:
> > Hi Russell,
> >
> > No worries, the change was easy. I was mostly interested in your view
> > about the change, and you confirm the main concern is the appearance of
> > imported schematics.
> >
> > I am not sure if netlist updater is able to link a symbol and its
> > corresponding footprint when sheetpath is not complete, but if that is
> > the case then your other idea could be a better solution here.
> >
> > Best regards,
> > Orson
> >
> > On 02/17/2018 12:18 AM, Russell Oliver wrote:
> >> Hi all,
> >>
> >> Sorry I didn't get to it sooner. Been busy at a new job.
> >>
> >> I was going to say that globals will work fine except for the visual
> >> aspect. Though I think just replacing the global net on the pcb with the
> >> net from the schematic with the matching end label ( ignoring any sheet
> >> path)  should work too, since it will be unique anyway if importing
> from an
> >> eagle schematic.
> >>
> >> Kind Regards
> >> Russell
> >>
> >>
> >> On 17 Feb 2018 10:06, "Maciej Suminski" <maciej.sumin...@cern.ch>
> wrote:
> >>
> >> Alright, I switched the importer to use global net labels. Perhaps
> >> schematics are not always the prettiest ones, but at least they are
> >> equivalent to the original project.
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 02/16/2018 02:59 PM, Wayne Stambaugh wrote:
> >>> If using global nets resolves the issue and doesn't cause any other
> >>> issues, it has my vote as well.
> >>>
> >>> On 02/16/2018 08:36 AM, Maciej Sumiński wrote:
> >>>> I vote for switching to global nets. I may handle this, just want to
> be
> >>>> sure Russell has not started already working on it, so there is no
> work
> >>>> duplication.
> >>>>
> >>>> Regards,
> >>>> Orson
> >>>>
> >>>> On 02/16/2018 02:17 PM, Wayne Stambaugh wrote:
> >>>>> Gentlemen,
> >>>>>
> >>>>> What is the status of this bug fix?  I know there was some discussion
> >>>>> about this patch.  Do we have path forward on this yet?  I would
> like to
> >>>>> get this into rc1 if possible.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Wayne
> >>>>> On 02/14/2018 08:17 AM, Russell Oliver wrote:
> >>>>>> Please find the attached patch for this issue.
> >>>>>>
> >>>>>> On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński <
> >> maciej.sumin...@cern.ch
> >>>>>> <mailto:maciej.sumin...@cern.ch>> wrote:
> >&

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

I'll work on it further and hopefully it can be included in maybe a point
release or v6.

My main concern is that zones and stitching vias aren't left on orphaned
nets after the netlist is first synced with the schematic during import,
which the global labels solve.



On 17 Feb 2018 21:54, "Maciej Suminski" <maciej.sumin...@cern.ch> wrote:

Hi Russell,

No worries, the change was easy. I was mostly interested in your view
about the change, and you confirm the main concern is the appearance of
imported schematics.

I am not sure if netlist updater is able to link a symbol and its
corresponding footprint when sheetpath is not complete, but if that is
the case then your other idea could be a better solution here.

Best regards,
Orson

On 02/17/2018 12:18 AM, Russell Oliver wrote:
> Hi all,
>
> Sorry I didn't get to it sooner. Been busy at a new job.
>
> I was going to say that globals will work fine except for the visual
> aspect. Though I think just replacing the global net on the pcb with the
> net from the schematic with the matching end label ( ignoring any sheet
> path)  should work too, since it will be unique anyway if importing from
an
> eagle schematic.
>
> Kind Regards
> Russell
>
>
> On 17 Feb 2018 10:06, "Maciej Suminski" <maciej.sumin...@cern.ch> wrote:
>
> Alright, I switched the importer to use global net labels. Perhaps
> schematics are not always the prettiest ones, but at least they are
> equivalent to the original project.
>
> Cheers,
> Orson
>
> On 02/16/2018 02:59 PM, Wayne Stambaugh wrote:
>> If using global nets resolves the issue and doesn't cause any other
>> issues, it has my vote as well.
>>
>> On 02/16/2018 08:36 AM, Maciej Sumiński wrote:
>>> I vote for switching to global nets. I may handle this, just want to be
>>> sure Russell has not started already working on it, so there is no work
>>> duplication.
>>>
>>> Regards,
>>> Orson
>>>
>>> On 02/16/2018 02:17 PM, Wayne Stambaugh wrote:
>>>> Gentlemen,
>>>>
>>>> What is the status of this bug fix?  I know there was some discussion
>>>> about this patch.  Do we have path forward on this yet?  I would like
to
>>>> get this into rc1 if possible.
>>>>
>>>> Thanks,
>>>>
>>>> Wayne
>>>> On 02/14/2018 08:17 AM, Russell Oliver wrote:
>>>>> Please find the attached patch for this issue.
>>>>>
>>>>> On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński <
> maciej.sumin...@cern.ch
>>>>> <mailto:maciej.sumin...@cern.ch>> wrote:
>>>>>
>>>>> Hi Russell,
>>>>>
>>>>> On 02/11/2018 05:41 AM, Russell Oliver wrote:
>>>>> > Hi All,
>>>>> >
>>>>> > I've discovered the cause of a problem when importing Eagle
>>>>> Projects and
>>>>> > getting the schematic and boards synced.
>>>>> >
>>>>> > Currently when importing an Eagle schematic, labels for nets
that
>>>>> are only
>>>>> > found one Eagle sheet are imported as local KiCad labels. This
>>>>> preserves
>>>>> > the visual design of the schematic some what. For eagle
> schematics
>>>>> with
>>>>> > more than 1 sheet, where hierarchical sheets are created in
> Kicad,
>>>>> global
>>>>> > labels are created to tie the nets together across the sheets
the
>>>>> same as
>>>>> > Eagle due to its lack of scopes for net names.
>>>>> >
>>>>> > The problem is that the imported PCB will have net names that
are
>>>>> global
>>>>> > e.g "VBUS" while the imported schematic may end up with local
>>>>> netname for
>>>>> > the root sheet e.g "/VBUS". This will cause errors for boards
> with
>>>>> zones
>>>>> > and named vias with the original/global netname e.g."VBUS"
>>>>> >
>>>>> > My proposal to fix this is to create another pass in the netlist
>>>>> generation
>>>>> > code that would remove the forward slash '/' for unique local
> nets
>>>>> in the
>>>>> > root sheet provided it does not clash with an existing net name.
>>>>>
>>>>> Go

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Hi all,

Sorry I didn't get to it sooner. Been busy at a new job.

I was going to say that globals will work fine except for the visual
aspect. Though I think just replacing the global net on the pcb with the
net from the schematic with the matching end label ( ignoring any sheet
path)  should work too, since it will be unique anyway if importing from an
eagle schematic.

Kind Regards
Russell


On 17 Feb 2018 10:06, "Maciej Suminski" <maciej.sumin...@cern.ch> wrote:

Alright, I switched the importer to use global net labels. Perhaps
schematics are not always the prettiest ones, but at least they are
equivalent to the original project.

Cheers,
Orson

On 02/16/2018 02:59 PM, Wayne Stambaugh wrote:
> If using global nets resolves the issue and doesn't cause any other
> issues, it has my vote as well.
>
> On 02/16/2018 08:36 AM, Maciej Sumiński wrote:
>> I vote for switching to global nets. I may handle this, just want to be
>> sure Russell has not started already working on it, so there is no work
>> duplication.
>>
>> Regards,
>> Orson
>>
>> On 02/16/2018 02:17 PM, Wayne Stambaugh wrote:
>>> Gentlemen,
>>>
>>> What is the status of this bug fix?  I know there was some discussion
>>> about this patch.  Do we have path forward on this yet?  I would like to
>>> get this into rc1 if possible.
>>>
>>> Thanks,
>>>
>>> Wayne
>>> On 02/14/2018 08:17 AM, Russell Oliver wrote:
>>>> Please find the attached patch for this issue.
>>>>
>>>> On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński <
maciej.sumin...@cern.ch
>>>> <mailto:maciej.sumin...@cern.ch>> wrote:
>>>>
>>>> Hi Russell,
>>>>
>>>> On 02/11/2018 05:41 AM, Russell Oliver wrote:
>>>> > Hi All,
>>>> >
>>>> > I've discovered the cause of a problem when importing Eagle
>>>> Projects and
>>>> > getting the schematic and boards synced.
>>>> >
>>>> > Currently when importing an Eagle schematic, labels for nets that
>>>> are only
>>>> > found one Eagle sheet are imported as local KiCad labels. This
>>>> preserves
>>>> > the visual design of the schematic some what. For eagle
schematics
>>>> with
>>>> > more than 1 sheet, where hierarchical sheets are created in
Kicad,
>>>> global
>>>> > labels are created to tie the nets together across the sheets the
>>>> same as
>>>> > Eagle due to its lack of scopes for net names.
>>>> >
>>>> > The problem is that the imported PCB will have net names that are
>>>> global
>>>> > e.g "VBUS" while the imported schematic may end up with local
>>>> netname for
>>>> > the root sheet e.g "/VBUS". This will cause errors for boards
with
>>>> zones
>>>> > and named vias with the original/global netname e.g."VBUS"
>>>> >
>>>> > My proposal to fix this is to create another pass in the netlist
>>>> generation
>>>> > code that would remove the forward slash '/' for unique local
nets
>>>> in the
>>>> > root sheet provided it does not clash with an existing net name.
>>>>
>>>> Good catch. I would rather not modify the netlist generator code,
but
>>>> add another pass in the board importer. I suggest the following:
>>>> - Move netlist generation from kicad/import_project.cpp to
>>>> SCH_EDIT_FRAME::ImportFile().
>>>> - Move netlist import from kicad/import_project.cpp to
>>>> PCB_EDIT_FRAME::ImportFile().
>>>> - After importing a board and its netlist, go through the list of
zones
>>>> and try to assign '/' + zone->GetNetname(). If such netlist
exists, then
>>>> it means the assigned net is a local one and needs renaming. The
only
>>>> problem here is a potential conflict if there exist both 'netname'
>>>> (local label) and '/netname' (global label). I guess such case
deserves
>>>> a huge warning, so the user needs to verify the import result.
>>>>
>>>> I suppose the last special case should be simply reported by the
ERC
>>>> even without importing a project, as it creates a connection
between two
>>>> seemingly not related nets.
>>>>
>>>> Thoughts?
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> > Kind Regards
>>>> > Russell
>>>> >
>>>> >
>>>> > P.S During debugging this issue, I discovered that a local label
>>>> and global
>>>> > label of the same name on the same sheet are connected regardless
>>>> of any
>>>> > wires. Which if there is a hierarchical sheet can lead to the
same
>>>> net for
>>>> > 2 wire segments on separate sheets connected only to local
labels,
>>>> if the
>>>> > identical global label is somewhere else on both sheets. Is this
the
>>>> > expected behaviour? or just a side effect?
>>>> >
>>>>
>>>>
>>>
>>
>>
>
___
Mailing list: https://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] Improving Eagle Import netlist matching

[Russell Oliver]

Please find the attached patch for this issue.

On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński <maciej.sumin...@cern.ch>
wrote:

> Hi Russell,
>
> On 02/11/2018 05:41 AM, Russell Oliver wrote:
> > Hi All,
> >
> > I've discovered the cause of a problem when importing Eagle Projects and
> > getting the schematic and boards synced.
> >
> > Currently when importing an Eagle schematic, labels for nets that are
> only
> > found one Eagle sheet are imported as local KiCad labels. This preserves
> > the visual design of the schematic some what. For eagle schematics with
> > more than 1 sheet, where hierarchical sheets are created in Kicad, global
> > labels are created to tie the nets together across the sheets the same as
> > Eagle due to its lack of scopes for net names.
> >
> > The problem is that the imported PCB will have net names that are global
> > e.g "VBUS" while the imported schematic may end up with local netname for
> > the root sheet e.g "/VBUS". This will cause errors for boards with zones
> > and named vias with the original/global netname e.g."VBUS"
> >
> > My proposal to fix this is to create another pass in the netlist
> generation
> > code that would remove the forward slash '/' for unique local nets in the
> > root sheet provided it does not clash with an existing net name.
>
> Good catch. I would rather not modify the netlist generator code, but
> add another pass in the board importer. I suggest the following:
> - Move netlist generation from kicad/import_project.cpp to
> SCH_EDIT_FRAME::ImportFile().
> - Move netlist import from kicad/import_project.cpp to
> PCB_EDIT_FRAME::ImportFile().
> - After importing a board and its netlist, go through the list of zones
> and try to assign '/' + zone->GetNetname(). If such netlist exists, then
> it means the assigned net is a local one and needs renaming. The only
> problem here is a potential conflict if there exist both 'netname'
> (local label) and '/netname' (global label). I guess such case deserves
> a huge warning, so the user needs to verify the import result.
>
> I suppose the last special case should be simply reported by the ERC
> even without importing a project, as it creates a connection between two
> seemingly not related nets.
>
> Thoughts?
>
> Regards,
> Orson
>
> > Kind Regards
> > Russell
> >
> >
> > P.S During debugging this issue, I discovered that a local label and
> global
> > label of the same name on the same sheet are connected regardless of any
> > wires. Which if there is a hierarchical sheet can lead to the same net
> for
> > 2 wire segments on separate sheets connected only to local labels, if the
> > identical global label is somewhere else on both sheets. Is this the
> > expected behaviour? or just a side effect?
> >
>
>
>


0001-Eagle-Schematic-Import-Fix-netlist-mapping-for-zones.patch
Description: Binary data
___
Mailing list: https://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] Add empty eeschema page layout for Eagle schematic import. Bug #1729722

[Russell Oliver]

Updated patch.

On Tue, Feb 13, 2018 at 9:41 AM Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 02/12/2018 05:21 PM, Russell Oliver wrote:
> > So a file created on disk in the project folder that is then added as a
> > path in the project specification?
>
> Yes.  Just set m_PageLayoutDescrFileName to empty.kicad_wks for both the
> schematic and the board BASE_SCREEN objects and you should be good to go.
>
> >
> > As a more general concept then should every project have a layout file
> > in the project folder?
>
> Only when the default worksheet cannot be used.  If you are OK with the
> default worksheet, then no worksheet file is required.
>
> >
> >
> >
> > On 13 Feb 2018 02:59, "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > I prefer adding an empty.kicad_wks file be added to the project and
> then
> > set the board and schematic worksheets to this file.  This would
> negate
> > the file format rev bumps.
> >
> > On 2/12/2018 10:48 AM, Maciej Sumiński wrote:
> > > Hi Russell,
> > >
> > > You are right, it adds a special case for project file format, so
> > > technically it is a version bump. Alternatively one could simply
> > create
> > > "empty.kicad_wks" and store there the contents of
> > emptyPageLayout[]. It
> > > seems safer, but on the other hand I would like to be able to
> specify
> > > that design uses an empty worksheet layout.
> > >
> > > Wayne, what do you think? Is it acceptable that we add a reserved
> > > keyword "empty" to indicate an empty worksheet layout for a
> > project? If
> > > so, we need to implement it both for pcbnew and eeschema.
> > >
> > > Regards,
> > > Orson
> > >
> > > On 02/11/2018 12:24 AM, Russell Oliver wrote:
> > >> Hi Orson and Wayne
> > >>
> > >> I have updated the patch from your changes Orson, so that the
> > change is
> > >> saved using the project file settings, by setting the schematic
> > layout file
> > >> path as "empty" eg
> > >> PageLayoutDescrFile=empty
> > >>
> > >> It is technically a file format change, but it also provides the
> > option to
> > >> those that do not want a border to specify it for a schematic.
> > >>
> > >> Kind Regards
> > >> Russell
> > >>
> > >>
> > >> On Thu, Feb 8, 2018 at 10:25 PM Maciej Sumiński
> > <maciej.sumin...@cern.ch <mailto:maciej.sumin...@cern.ch>>
> > >> wrote:
> > >>
> > >>> There is still one problem to be solved here: worksheet layout
> > is not
> > >>> saved in schematic file, so the default worksheet is restored
> > when an
> > >>> imported project is saved and reloaded.
> > >>>
> > >>> I have nothing against the patch, it gives a nicer first
> impression.
> > >>>
> > >>> Cheers,
> > >>> Orson
> > >>>
> > >>> On 02/07/2018 04:44 PM, Wayne Stambaugh wrote:
> > >>>> Thanks for testing this.  I know I'm being paranoid but we've
> > been bit
> > >>>> by this before.  Maybe someday our unit testing will actually
> get
> > >>>> implemented.
> > >>>>
> > >>>> Wayne
> > >>>>
> > >>>> On 2/7/2018 8:21 AM, Russell Oliver wrote:
> > >>>>> I just tested printing then and it worked fine. plus one
> person's
> > >>>>> unhandled edge case is another's unit test.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Thu, Feb 8, 2018 at 12:05 AM Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>
> > >>>>> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> > wrote:
> > >>>>>
> > >>>>> Be careful with zero length line segments.  They have been
> > known to
> > >>>>> cause issues in the past.  We recently fixed a print bug
&

Re: [Kicad-developers] [PATCH] Add empty eeschema page layout for Eagle schematic import. Bug #1729722

[Russell Oliver]

So a file created on disk in the project folder that is then added as a
path in the project specification?

As a more general concept then should every project have a layout file in
the project folder?



On 13 Feb 2018 02:59, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

I prefer adding an empty.kicad_wks file be added to the project and then
set the board and schematic worksheets to this file.  This would negate
the file format rev bumps.

On 2/12/2018 10:48 AM, Maciej Sumiński wrote:
> Hi Russell,
>
> You are right, it adds a special case for project file format, so
> technically it is a version bump. Alternatively one could simply create
> "empty.kicad_wks" and store there the contents of emptyPageLayout[]. It
> seems safer, but on the other hand I would like to be able to specify
> that design uses an empty worksheet layout.
>
> Wayne, what do you think? Is it acceptable that we add a reserved
> keyword "empty" to indicate an empty worksheet layout for a project? If
> so, we need to implement it both for pcbnew and eeschema.
>
> Regards,
> Orson
>
> On 02/11/2018 12:24 AM, Russell Oliver wrote:
>> Hi Orson and Wayne
>>
>> I have updated the patch from your changes Orson, so that the change is
>> saved using the project file settings, by setting the schematic layout
file
>> path as "empty" eg
>> PageLayoutDescrFile=empty
>>
>> It is technically a file format change, but it also provides the option
to
>> those that do not want a border to specify it for a schematic.
>>
>> Kind Regards
>> Russell
>>
>>
>> On Thu, Feb 8, 2018 at 10:25 PM Maciej Sumiński <maciej.sumin...@cern.ch>
>> wrote:
>>
>>> There is still one problem to be solved here: worksheet layout is not
>>> saved in schematic file, so the default worksheet is restored when an
>>> imported project is saved and reloaded.
>>>
>>> I have nothing against the patch, it gives a nicer first impression.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 02/07/2018 04:44 PM, Wayne Stambaugh wrote:
>>>> Thanks for testing this.  I know I'm being paranoid but we've been bit
>>>> by this before.  Maybe someday our unit testing will actually get
>>>> implemented.
>>>>
>>>> Wayne
>>>>
>>>> On 2/7/2018 8:21 AM, Russell Oliver wrote:
>>>>> I just tested printing then and it worked fine. plus one person's
>>>>> unhandled edge case is another's unit test.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 8, 2018 at 12:05 AM Wayne Stambaugh <stambau...@gmail.com
>>>>> <mailto:stambau...@gmail.com>> wrote:
>>>>>
>>>>> Be careful with zero length line segments.  They have been known
to
>>>>> cause issues in the past.  We recently fixed a print bug where a
>>> zero
>>>>> diameter circle was causing pages not to print.
>>>>>
>>>>> On 2/7/2018 7:45 AM, Russell Oliver wrote:
>>>>> > Hi Orson,
>>>>> >
>>>>> > I'm completely fine with any simplifications and style changes.
>>>>> >
>>>>> > With regards to the zero length line, it appears on line 110 of
>>> your
>>>>> > patch file.
>>>>> > 110: +"(line (name segm1:Line) (start 0 0) (end 0 0))\n"
>>>>> >
>>>>> > JP mentions in a comment to the bug report that there is a
legacy
>>>>> > compatibility requirement to have at least one item in the page
>>>>> layout,
>>>>> > otherwise the default layout it used. This was for old
schematics
>>> that
>>>>> > do not have a page layout specified.
>>>>> >
>>>>> > Kind Regards
>>>>> > Russell
>>>>> >
>>>>> >
>>>>> > On Wed, Feb 7, 2018 at 12:13 AM Maciej Sumiński
>>>>> <maciej.sumin...@cern.ch <mailto:maciej.sumin...@cern.ch>
>>>>> > <mailto:maciej.sumin...@cern.ch <mailto:maciej.sumin...@cern.ch
>>>>>>
>>>>> wrote:
>>>>> >
>>>>> > Hi Russell,
>>>>> >
>>>>> > Thank you very much for the patch. It works as expected and
I
>>>>> would like
>>>>> > 

[Kicad-developers] Improving Eagle Import netlist matching

[Russell Oliver]

Hi All,

I've discovered the cause of a problem when importing Eagle Projects and
getting the schematic and boards synced.

Currently when importing an Eagle schematic, labels for nets that are only
found one Eagle sheet are imported as local KiCad labels. This preserves
the visual design of the schematic some what. For eagle schematics with
more than 1 sheet, where hierarchical sheets are created in Kicad, global
labels are created to tie the nets together across the sheets the same as
Eagle due to its lack of scopes for net names.

The problem is that the imported PCB will have net names that are global
e.g "VBUS" while the imported schematic may end up with local netname for
the root sheet e.g "/VBUS". This will cause errors for boards with zones
and named vias with the original/global netname e.g."VBUS"

My proposal to fix this is to create another pass in the netlist generation
code that would remove the forward slash '/' for unique local nets in the
root sheet provided it does not clash with an existing net name.

Kind Regards
Russell


P.S During debugging this issue, I discovered that a local label and global
label of the same name on the same sheet are connected regardless of any
wires. Which if there is a hierarchical sheet can lead to the same net for
2 wire segments on separate sheets connected only to local labels, if the
identical global label is somewhere else on both sheets. Is this the
expected behaviour? or just a side effect?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Eagle schematic import, label placement fix.

[Russell Oliver]

This fixes an issue i found during some testing. Small labels are added to
connect segments sharing the same net name in the eagle schematic. These
were placed in the middle of a wire, but other wires may cross at this
point without being connected by a junction. When the netlist is created
the label will connect these wires anyway leading to a incorrect netlist.
These labels are now added at a wire end where existing connection rules
apply.

Russell


0001-Eagle-Schematic-Import-Label-Placement-fix.patch
Description: Binary data
___
Mailing list: https://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] Add empty eeschema page layout for Eagle schematic import. Bug #1729722

[Russell Oliver]

I just tested printing then and it worked fine. plus one person's unhandled
edge case is another's unit test.



On Thu, Feb 8, 2018 at 12:05 AM Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Be careful with zero length line segments.  They have been known to
> cause issues in the past.  We recently fixed a print bug where a zero
> diameter circle was causing pages not to print.
>
> On 2/7/2018 7:45 AM, Russell Oliver wrote:
> > Hi Orson,
> >
> > I'm completely fine with any simplifications and style changes.
> >
> > With regards to the zero length line, it appears on line 110 of your
> > patch file.
> > 110: +"(line (name segm1:Line) (start 0 0) (end 0 0))\n"
> >
> > JP mentions in a comment to the bug report that there is a legacy
> > compatibility requirement to have at least one item in the page layout,
> > otherwise the default layout it used. This was for old schematics that
> > do not have a page layout specified.
> >
> > Kind Regards
> > Russell
> >
> >
> > On Wed, Feb 7, 2018 at 12:13 AM Maciej Sumiński <maciej.sumin...@cern.ch
> > <mailto:maciej.sumin...@cern.ch>> wrote:
> >
> > Hi Russell,
> >
> > Thank you very much for the patch. It works as expected and I would
> like
> > to merge it, but there are two things.
> >
> > I have simplified the patch a bit (moved the empty layout to an
> existing
> > file, minor code formatting fixes), so please confirm you are ok with
> > committing it under your name.
> >
> > Another question is about "there is a 0 length line to fool something
> > somewhere." comment for const char emptyLayout[]. Could you say
> > something more about it? I could not spot a 0 length line in the
> layout
> > description, so perhaps we can remove it to avoid confusion.
> >
> > Regards,
> > Orson
> >
> > On 02/03/2018 01:27 AM, Russell Oliver wrote:
> > > Attached is a patch that adds an empty layout using the same
> > method as the
> > > SetDefaultLayout function, which is then called by the Eagle
> schematic
> > > plugin to leave only the imported frame visible.
> > >
> > > https://bugs.launchpad.net/kicad/+bug/1729722
> > >
> > > Kind Regards
> > > Russell
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > <mailto: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
> > <mailto: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] [PATCH] Add empty eeschema page layout for Eagle schematic import. Bug #1729722

[Russell Oliver]

Hi Orson,

I'm completely fine with any simplifications and style changes.

With regards to the zero length line, it appears on line 110 of your patch
file.
110: +"(line (name segm1:Line) (start 0 0) (end 0 0))\n"

JP mentions in a comment to the bug report that there is a legacy
compatibility requirement to have at least one item in the page layout,
otherwise the default layout it used. This was for old schematics that do
not have a page layout specified.

Kind Regards
Russell


On Wed, Feb 7, 2018 at 12:13 AM Maciej Sumiński <maciej.sumin...@cern.ch>
wrote:

> Hi Russell,
>
> Thank you very much for the patch. It works as expected and I would like
> to merge it, but there are two things.
>
> I have simplified the patch a bit (moved the empty layout to an existing
> file, minor code formatting fixes), so please confirm you are ok with
> committing it under your name.
>
> Another question is about "there is a 0 length line to fool something
> somewhere." comment for const char emptyLayout[]. Could you say
> something more about it? I could not spot a 0 length line in the layout
> description, so perhaps we can remove it to avoid confusion.
>
> Regards,
> Orson
>
> On 02/03/2018 01:27 AM, Russell Oliver wrote:
> > Attached is a patch that adds an empty layout using the same method as
> the
> > SetDefaultLayout function, which is then called by the Eagle schematic
> > plugin to leave only the imported frame visible.
> >
> > https://bugs.launchpad.net/kicad/+bug/1729722
> >
> > Kind Regards
> > Russell
> >
> >
> >
> > ___
> > Mailing list: https://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] [PATCH] Add a menu item to save a project under a new name.

[Russell Oliver]

Yeah, I realized this after a sent the patch in, though I think it also
calls into question the logic behind the archive project function. Though I
am surprised about the sub directory files problem.

I do think it's an important feature to have though, so any help from
anyone would be appreciated.

Kind Regards
Russell


On 6 Feb 2018 03:18, "jp charras" <jp.char...@wanadoo.fr> wrote:

Le 05/02/2018 à 06:07, Russell Oliver a écrit :
> Copies project files into a new directory with the project name replaced
in each file name if
> preset. Uses the same set of extensions as the archive project feature to
filter the files.
>

Hi Russel,

I tested your patch, but it does not work very well:
- subdirectories are not duplicated. Instead of, the files inside subdirs
are copied to the new root
dir.
- lib tables are not copied.

There is also a problem with libraries inside the project (like a rescue
lib)
They are renamed, but lib tables should be modified, according to the
renaming.

This is a tricky problem.

--
Jean-Pierre CHARRAS

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

[Kicad-developers] [PATCH] Add a menu item to save a project under a new name.

[Russell Oliver]

Copies project files into a new directory with the project name replaced in
each file name if preset. Uses the same set of extensions as the archive
project feature to filter the files.


0001-Add-a-menu-item-to-save-a-project-under-a-new-name.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Bug #1731802 Unable to open eagle footprint lib, No error message just empty footprint editor

[Russell Oliver]

Fixes the bug by removing a line that deleted the imported footprint
templates every time the plugin init function is called.


0001-Fix-empty-footprints-when-using-Eagle-libraries.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Add empty eeschema page layout for Eagle schematic import. Bug #1729722

[Russell Oliver]

Attached is a patch that adds an empty layout using the same method as the
SetDefaultLayout function, which is then called by the Eagle schematic
plugin to leave only the imported frame visible.

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

Kind Regards
Russell


0001-Add-empty-eeschema-page-layout-for-Eagle-schematic-i.patch
Description: Binary data
___
Mailing list: https://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] Math expression support for pad editor.

[Russell Oliver]

Hi All,

Just a query for Michael: can your parser be modified to include references
to dialog variables, ie while writing an expression for y axis position,
using the label posx or something would refer to the value currently within
that text box?

Kind Regards
Russell


On 24 Nov 2017 06:54, "jp charras"  wrote:

Le 23/11/2017 à 20:45, Michael Geselbracht a écrit :
> Hi,
> I have replaced the useless file info comments by a GPLv3 header  in
order to make my "libeval" code
> license-wise compatible to the Kicad project.
>
>  - Michael
>
>

Thanks Michael,

Could you add a bit of comments?
Currently God and you know the meaning of the code.
One day, only God will know the meaning of this code.

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
___
Mailing list: https://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] Testing New eagle import, problems

[Russell Oliver]

Hi Lachlan,

I was the main developer of the Eagle schematic import plugin and I know
the layout of the Pcbnew Eagle import code pretty well. So If you can
describe further the errors you are seeing that would be great, even if its
just links to the original Eagle files and screen shots of the offending
areas.

Wayne: I'm thinking we to start with to change the text of the Import
Project menu option from "Eagle Cad" to something like "Eagle CAD 6.x+
XML".

Kind Regards
Russell

On Sat, Nov 11, 2017 at 11:58 AM Wayne Stambaugh 
wrote:

> Lachlan,
>
> It looks like your attachment got blocked.  Is there another way to get
> it to us?
>
> Cheers,
>
> Wayne
>
> On 11/10/2017 7:26 PM, Lachlan Audas wrote:
> > A few quick test show the Eagle import has some problems, on the
> Developers
> > version.
> >
> > I would  suggest you do a binary file check,  on sch/pcb files,   and
> warn
> > the user,   that Kicad only supports XML, 6.0+ instead of giving
> confusing
> > passer error messages when it finds a binary file. Example:
> >
> https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/RT5350F/RT5350F-
> > OLinuXino/RT5350F_OLinuXino_Rev_E
> >
> > Others  from OLIMEX  also show up the a number of problems with text
> > showing when they should not, and not displaying text when they should.
> > Example:  Attached.   Sorry for the file size,  But I'm not sure if the
> > mailing list server will block compressed files.
> >
> > Lachlan
> >
> >
> >
> > ___
> > Mailing list: https://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] [PATCH] PcbNew Eagle Plugin: Remove layer restriction on some graphic items, fix undrawn items and place values on fabrication layers.

[Russell Oliver]

Thanks everyone for your input. I'll revert patch and move to creating the
IO_ERROR exceptions for unimportable items.

As an aside, is there a particular reason why polygons are not editable in
the footprint editor? Even if they were restricted to non-copper?

Regards
Russell

On Tue, Sep 26, 2017 at 12:34 AM Wayne Stambaugh 
wrote:

> On 9/25/2017 9:13 AM, jp charras wrote:
> > Le 25/09/2017 à 10:22, Maciej Sumiński a écrit :
> >> Hi Russell,
> >>
> >> Would you provide a board example that would be affected by the change?
> >> It would be very helpful to test the patch.
> >>
> >> I am not really sure whether EDGE_MODULEs drawn on copper layers will be
> >> exported to Gerbers and I am certain that they will not be taken into
> >> account during DRC or zone fill calculations. If my suspicions are
> >> correct, then IMHO presence of such footprints should lead to a warning
> >> message and nothing more. Perhaps they could be converted to custom
> >> shape pads, but I am not sure it is always applicable or trivial.
> >>
> >> Regards,
> >> Orson
> >
> > I am also not especially thrilled by allowing EDGE_MODULEs items on
> copper layers for 2 reasons:
> > - DRC does not take in account these items.
> > - EDGE_MODULEs polygonal shapes are not editable in the footprint editor.
> > Therefore you cannot remove or change them.
> >
> > They are allowed in a very specific case: automatically generated
> microwave footprints.
> > (and I recently modified a microwave footprint type to use a custom pad).
> >
> > A warning message is currently the only one reliable way to manage this
> kind of item.
> > Allowing EDGE_MODULEs items on copper layers during Eagle to Pcbnew
> import process is the best way
> > to create serious issues and mistakes.
> > In short: on a copper layer, you cannot easily put graphic items.
> >
> > Remark: EDGE_MODULEs items on copper layers are handled in zone filling
> and plot functions.
> > However, because they are not belonging a net (because in Pcbnew they
> are not currently linked to a
> > pad), they cannot be perfectly handled.
>
> Thank you for the input JP.
>
> Russel, you will have to change your patch accordingly.  I see two
> possible options, neither will be easy.  Convert to a custom pad or
> convert to another layer and warn the user about the issues so they can
> manually fix them.  The custom pad conversion complexity is obvious.
> The user warning is not as easy as it would seem.  No UI code is allowed
> in plugins.  This means that you must queue up messages, raise an
> IO_ERROR exception, and catch that in the UI code.
>
> >
> >>
>
> <<>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Eagle schematic and project import.

[Russell Oliver]

Hi Orson,

Please find attached a small patch that handles multiple pad connections.

Regards
Russell

On Sat, Sep 23, 2017 at 11:03 AM Russell Oliver <roliver8...@gmail.com>
wrote:

> Hi,
>
> Maciej : I had a look at the rounding issue and I couldn't find an
> obvious reason for it.
> It might be due to the translation of all components to the middle of the
> sheet, but I round that off to the nearest 100mil.
>
> I'll take a look at that pin mapping problem, I think your solution of
> multiple pins will work fine.
>
> Regards
> Russell
>
>
> On Sat, Sep 23, 2017 at 1:20 AM Maciej Sumiński <maciej.sumin...@cern.ch>
> wrote:
>
>> On 09/20/2017 05:38 PM, jp charras wrote:
>> > Le 20/09/2017 à 17:32, Maciej Sumiński a écrit :
>> >> On 09/20/2017 05:29 PM, jp charras wrote:
>> >> [snip]
>> >>> After tests with 2 schematics I found a rounding issue in coordinates
>> (especially wires and pins):
>> >>> Many coordinates are very near (1 mil, therefore one Eeschema unit)
>> the 50 mils grid but not exactly
>> >>> on grid (for instance 499 instead of 500 mils)
>> >>> The a few values I checked are smaller (one mil) than the grid
>> coordinate, so I am thinking this is
>> >>> a rounding issue.
>> >>
>> >> Would you share an example schematic file, so we could investigate the
>> >> problem?
>> >>
>> >> Regards,
>> >> Orson
>> >
>> > Attached the 2 schematics I tested.
>> > They can be found on Github.
>>
>> Jean-Pierre,
>>
>> Could you help me find pins/wires that are not connected due to rounding
>> errors? I did my best, but I cannot find anything neither by looking at
>> the files saved in KiCad format nor in ERC reports.
>>
>> I noticed only missing junction marks on some of the T-shaped wire
>> connections, but they are missing in the original Eagle files, so I
>> assume it is fine.
>>
>> There is a minor bug that causes small squares on pins (as if they were
>> not connected), but as soon you move a single component, they all
>> disappear. This should be investigated, but it is not a rounding problem.
>>
>> Regards,
>> Orson
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>


0001-Eagle-Import-Handle-muli-pad-pins.patch
Description: Binary data
___
Mailing list: https://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] Eagle schematic and project import.

[Russell Oliver]

Hi,

Maciej : I had a look at the rounding issue and I couldn't find an obvious
reason for it.
It might be due to the translation of all components to the middle of the
sheet, but I round that off to the nearest 100mil.

I'll take a look at that pin mapping problem, I think your solution of
multiple pins will work fine.

Regards
Russell


On Sat, Sep 23, 2017 at 1:20 AM Maciej Sumiński 
wrote:

> On 09/20/2017 05:38 PM, jp charras wrote:
> > Le 20/09/2017 à 17:32, Maciej Sumiński a écrit :
> >> On 09/20/2017 05:29 PM, jp charras wrote:
> >> [snip]
> >>> After tests with 2 schematics I found a rounding issue in coordinates
> (especially wires and pins):
> >>> Many coordinates are very near (1 mil, therefore one Eeschema unit)
> the 50 mils grid but not exactly
> >>> on grid (for instance 499 instead of 500 mils)
> >>> The a few values I checked are smaller (one mil) than the grid
> coordinate, so I am thinking this is
> >>> a rounding issue.
> >>
> >> Would you share an example schematic file, so we could investigate the
> >> problem?
> >>
> >> Regards,
> >> Orson
> >
> > Attached the 2 schematics I tested.
> > They can be found on Github.
>
> Jean-Pierre,
>
> Could you help me find pins/wires that are not connected due to rounding
> errors? I did my best, but I cannot find anything neither by looking at
> the files saved in KiCad format nor in ERC reports.
>
> I noticed only missing junction marks on some of the T-shaped wire
> connections, but they are missing in the original Eagle files, so I
> assume it is fine.
>
> There is a minor bug that causes small squares on pins (as if they were
> not connected), but as soon you move a single component, they all
> disappear. This should be investigated, but it is not a rounding problem.
>
> Regards,
> Orson
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] PcbNew Eagle Plugin: Remove layer restriction on some graphic items, fix undrawn items and place values on fabrication layers.

[Russell Oliver]

Wayne,

After my quick look at JP's custom pad code, I think the patch is still
valid simply because it allows for the quick conversion between copper
layer graphical items in an Eagle footprint to the equivalent KiCad item.
Eagle Cad does not have an equivalent custom pad shape feature which groups
graphical items as a pad within the footprint. As JP mentioned the
conversion to a proper custom KiCad pad shape would be non trivial. I have
seen Eagle users, use multiple graphical elements on separate layers to
define a pad, e.g. A polygon for copper, another for paste, another for
mask, and sometimes these do not overlap completely. Which if I assume
correctly is not supported by a custom KiCad pad?

I'll  find some Eagle boards with custom footprints (mostly antenna's) to
show how its being used.

Regards
Russell

On Thu, Sep 21, 2017 at 1:26 AM Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Russell,
>
> Is this patch still valid now that JP merged his custom pad work or does
> it need to be reworked to support custom pads?  I would like to get all
> of the Eagle changes into master for the stable 5 branch.
>
> Thanks,
>
> Wayne
>
> On 8/27/2017 4:39 AM, Russell Oliver wrote:
> > Hi All,
> >
> > Attached is a patch that does some minor code changes in the PcbNew
> > Eagle plugin which solves a few issues I encountered while testing the
> > eagle schematic plugin and project import feature.
> >
> > The first was that some footprints such as Wifi trace antennas use
> > graphic lines to form the footprint, but the plugin restricted the
> > import of lines and other items to non-copper layers. I think that if
> > you are prepared to import Eagle boards into Kicad you should be
> > prepared to check all your footprints for issues and not have the plugin
> > presuppose that lines on copper layers shouldn't exist.
> >
> > The second is matching the Eagle tValues and bValues layers with the
> > kicad Fabrication layers instead of the silkscreen layers, to match
> > current standard Kicad practive for component values.
> >
> > The third is that some EDGE_MODULE board items were not being drawn due
> > to missing calls to EDGE_MODULE::SetDrawCoord().
> >
> > Kind Regards
> > Russell
> >
> >
> >
> >
> >
> > ___
> > Mailing list: https://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] [PATCH] Eagle schematic and project import.

[Russell Oliver]

Hi,

Jean-Pierre: can you send me a link to the files you tested it on?

Also for opening either an Eagle schematic or board file, the intended
workflow starts within the KiCad launcher. File > Import Project > Eagle
Cad. This launches both Eeschema, Pcbnew for the matching files and then
synchronises the timestamps across the files.

Regards
Russell



On Fri, Sep 15, 2017 at 1:52 AM Bernhard Stegmaier <stegma...@sw-systems.de>
wrote:

> The selection issues on MacOS should be fixed in wxWidgets already - at
> least, there is a patch around for it if it hasn’t landed in 4.0.x yet (if
> it ever will…).
> We have to use a custom wxWidgets for MacOS anyway, so this shouldn’t be a
> reason for not using the selector.
>
>
> Regards,
> Bernhard
>
> > On 14. Sep 2017, at 14:05, jp charras <jp.char...@wanadoo.fr> wrote:
> >
> > Le 14/09/2017 à 10:33, Russell Oliver a écrit :
> >> Hi All,
> >>
> >> Below is a link to the patch hosted on Dropbox.
> >>
> >> https://www.dropbox.com/s/ig6mp9os0bzyev7/eagle-import.patch?dl=0
> >>
> >> Kind Regards
> >> Russell Oliver
> >>
> >
> > Thanks, Russel.
> >
> > I tried to test if on Windows (W7, 32 bits) but unfortunately it crashes
> (segmentation fault) on
> > opening a .sch Eagle file (I tried 2 files found on the Web).
> > (The corresponding board files can be opened)
> >
> > Otherwise, the selection of .sch file format (Kicad/Eagle) is made in
> the open sch file dialog.
> >
> > I am not sure this is a good ides because:
> > - In a similar case we already have issues on OSX for Pcbnew:
> > the file format selection did not work when the files have the same
> extension (.brd files that can
> > be a Eagle file or a old Kicad file).
> > (It was solved only by using 2 separate dialogs)
> > - Users are not aware of this selection, that is not really obvious.
> >
> > So I am thinking a separate menu (like in Pcbnew) one to read kicad
> files and one to import Eagle
> > schematics is more suitable.
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Eagle schematic and project import.

[Russell Oliver]

Hi All,

Below is a link to the patch hosted on Dropbox.

https://www.dropbox.com/s/ig6mp9os0bzyev7/eagle-import.patch?dl=0

Kind Regards
Russell Oliver

On Wed, Sep 13, 2017 at 11:09 PM Kaspar Emanuel <kaspar.eman...@gmail.com>
wrote:

> Hi Russ,
>
> wouldn't mind giving this a go but I don't see any attachments.
>
> Cheers,
>
> Kaspar
>
>
> On 13 September 2017 at 01:48, Russell Oliver <roliver8...@gmail.com>
> wrote:
>
>> Hello Everyone,
>>
>> Please find attached a combined patch set which adds Eagle schematic
>> parsing and a generic project import feature to KiCad.
>>
>> Its been in the pipeline for a long time now and I'm excited to get all
>> your feedback and see it announced to the community.
>>
>> I'm thankful to Alejandro Montoro for the initial plugin layout and Orson
>> for his guidance and code review over the past few months.
>>
>> Kind Regards
>> Russell Oliver
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Eagle schematic and project import.

[Russell Oliver]

Hmm the patch file I sent might be too big for launchpad

You can get it at
https://github.com/rustyoz/kicad/tree/eagle-import?files=1

I'll also directly send it too you.

On 13 Sep 2017 23:09, "Kaspar Emanuel" <kaspar.eman...@gmail.com> wrote:

> Hi Russ,
>
> wouldn't mind giving this a go but I don't see any attachments.
>
> Cheers,
>
> Kaspar
>
>
> On 13 September 2017 at 01:48, Russell Oliver <roliver8...@gmail.com>
> wrote:
>
>> Hello Everyone,
>>
>> Please find attached a combined patch set which adds Eagle schematic
>> parsing and a generic project import feature to KiCad.
>>
>> Its been in the pipeline for a long time now and I'm excited to get all
>> your feedback and see it announced to the community.
>>
>> I'm thankful to Alejandro Montoro for the initial plugin layout and Orson
>> for his guidance and code review over the past few months.
>>
>> Kind Regards
>> Russell Oliver
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Eagle schematic and project import.

[Russell Oliver]

Hello Everyone,

Please find attached a combined patch set which adds Eagle schematic
parsing and a generic project import feature to KiCad.

Its been in the pipeline for a long time now and I'm excited to get all
your feedback and see it announced to the community.

I'm thankful to Alejandro Montoro for the initial plugin layout and Orson
for his guidance and code review over the past few months.

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

Re: [Kicad-developers] [PATCH] Math expression support for pad editor.

[Russell Oliver]

Scratch Pad:
I think this will be easily doable as an additional text box in the dialog,
which is then added to the beginning of the expression for each text box.
The format for the math library is as follows

   (a) Initialise x to zero
   var x;

   (b) Initialise y to three
   var y := 3;

   (c) Initialise z to the expression
   var z := if (max(1,x + y) > 2,w,v);

Global variable support:
I think this is possible but a simpler path might be to use a global
scratch pad, which would be added first to the beginning of the expression
used for the text box.

Currently the expression text ie something like "posx + 1" isn't saved
within the dialog or for the component.

Regards
Russell





On Fri, Sep 1, 2017 at 7:46 AM Michael Geselbracht <mgeselbrac...@gmail.com>
wrote:

> Hi,
>
> I have tested the patch and I really like this feature. This automatic
> variable assignment will sure come in handy.
> How about adding a kind of scratch pad (a single line should do) to the
> footprint editor so that one can add variables (measurements) given in
> datasheets?
> Like "c1=2.9; e=0.635" in the scratch pad and then in PosX field: "-c1/2 "
> and PosY: "-1.5*e" in order to place the first pad.
>
>   - Michael
>
>
> On Thu, Aug 31, 2017 at 3:58 PM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> On 31.08.2017 15:27, Russell Oliver wrote:
>> > Hi All.
>> >
>> > As a follow up to my earlier post, attached is a patch that implement
>> > math expressions in the pad editor as well.
>> >
>> > A nifty feature is that the fields can be referenced from each other.
>> > currently the fields are referenced by the following names.
>> > - posx, posy, sizex, sizey, offsetx, offsetx, drillx, drillx.
>>
>> Hi Russell,
>>
>> Didn't have the time to check your patch yet, but I came up with an
>> idea: add global variable support to the math parser, so that if you
>> place a text anywhere in the design assigning to a variable (e.g.
>> var=10), it will be updated in any of the expressions that reference it.
>>
>> Cheers,
>> Tom
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Proof of concept of mathematical expression input for text fields.

[Russell Oliver]

Thanks everyone for your input.

First off, I too think it will get the most usage in the footprint editor,
specifically when calculating the position and size of a pad from cryptic
datasheet dimensions. I chose the schematic value entry dialog simply
because its a small target. But even having the ability to calculate values
using an expression when designing the schematic I think will be useful.

With regard to exposing the exprtk library to the python interface its
beyond my pay grade.

At this point i'm ambivalent to what library is finally used, but
exprtk was easy to integrate and as Tomasz pointed out comes as a single
header file. It has plenty of features and from my reading of the docs it
might be possible to use it to create a program wide parametric design
system using hierarchical symbol tables. It does compile to a fairly large
object file though ~43 MB.
Since python is already integrated to it might also be suitable parser.

I was actually looking for create a custom wx Control instead of creating
the MathProcesssor class, but couldn't find a suitable example from the
wxWidgets doc.
I think it would be fairly easy to extend the WX_UNIT_BINDER control to
include the parser, and a few find and replaces could spread the
functionality across Kicad.

In regards to using the equals sign to denote an expression, I think this
will only be needed in fields where the the final value is a string. In
combination with using OnTextEnter event, the user expressly denotes if the
input string is to be evaluated or left as is for the odd case where they
want to leave the equals sign in place. Otherwise for numerical inputs it
can always be evaluated in the way Michael has implemented his.

Kind Regards
Russell









On Mon, Aug 28, 2017 at 11:42 PM Michael Geselbracht <
mgeselbrac...@gmail.com> wrote:

> Incidentally I have written a similar calculator last week and included it
> in Pcbnew. I used the lemon parser generator
> but exprtk might be a better choice. That way it should be easy to extend
> the calculator with support for
> variables without re-inventing the wheel.
>
> I wanted to mimick the behaviour of Solidworks or CorelDraw; they do not
> use '=' to introduce a formula.
> The text is always interpreted as expression and constants may have units.
>
> So if I want to move a FP from x:80.442 50mil to the right I write (or
> append) "80.442+50mil".
> A difference is that I use the OnTextFocusLost event to start the
> evaluation and OnTextFocusGet to restore
> the previous text just before the evaluation (ups, should have been
> 25mils).
>
> The next step would be to integrate the evaluator in the footprint editor
> as well. But it does not seem to be wise
> right now ;).
>
>
>  - Michael
>
>
>
> On Mon, Aug 28, 2017 at 2:45 PM, hauptmech  wrote:
>
>> or perhaps the python parser is already used in enough kicad builds that
>> it should be used?
>>
>> On 28/08/17 19:56, Tomasz Wlostowski wrote:
>>
>>> On 27.08.2017 22:28, Marco Ciampa wrote:
>>>
 +1 muparser is already present in many distros:

 apt-cache search muparser
 libmuparser-dev - fast mathematical expressions parse library
 (development)
 libmuparser-doc - fast mathematical expressions parser library
 (documentation)
 libmuparser2v5 - fast mathematical expressions parser library (runtime)

>>> ...And exprtk is a single header file, which compiles on any OS. There
>>> is life outside Linux, too.
>>>
>>> - my 5 cents,
>>> Tom
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] PcbNew Eagle Plugin: Remove layer restriction on some graphic items, fix undrawn items and place values on fabrication layers.

[Russell Oliver]

>
>
> > The second is matching the Eagle tValues and bValues layers with the
> > kicad Fabrication layers instead of the silkscreen layers, to match
> > current standard Kicad practive for component values.
>
> I would think users will expect any object to import to the same layer
> that they are defined in Eagle.  If a module value object is on the
> silkscreen layer in Eagle, then the imported value object should be on
> the silkscreen layer.  Obviously, if there is a layer in Eagle that
> doesn't exist in Pcbnew, then we will have to map it to the most logical
> layer in KiCad.
>
>
I don't know how much you have used Eagle, so I apologise if the
explanation is redundant.
The main problem with matching the layers is that Eagle does have a defined
silkscreen layer as such. When creating the gerber files using the CAM
processor, multiple layers can be included in the same gerber file. By
Eagle convention the *Place layers are used for silkscreen lines and text,
with the *Names layers displaying the component name "R1" etc, which I have
seen included in the final silkscreen on some boards and not in others. By
comparison the *Values layers is not typically included in projects where I
have been able to compare the published eagle files, with photos of the
final pcb.

At this point its just a change to a more sensible default in my opinion.

In the future I think I work on including a dialog to allow the user pick
the destined Kicad layer for each Eagle layer.

Regards
Russell





> >
> > ___
> > Mailing list: https://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

[Kicad-developers] [PATCH] PcbNew Eagle Plugin: Remove layer restriction on some graphic items, fix undrawn items and place values on fabrication layers.

[Russell Oliver]

Hi All,

Attached is a patch that does some minor code changes in the PcbNew Eagle
plugin which solves a few issues I encountered while testing the eagle
schematic plugin and project import feature.

The first was that some footprints such as Wifi trace antennas use graphic
lines to form the footprint, but the plugin restricted the import of lines
and other items to non-copper layers. I think that if you are prepared to
import Eagle boards into Kicad you should be prepared to check all your
footprints for issues and not have the plugin presuppose that lines on
copper layers shouldn't exist.

The second is matching the Eagle tValues and bValues layers with the kicad
Fabrication layers instead of the silkscreen layers, to match current
standard Kicad practive for component values.

The third is that some EDGE_MODULE board items were not being drawn due to
missing calls to EDGE_MODULE::SetDrawCoord().

Kind Regards
Russell


0001-PcbNew-Eagle-Plugin-Remove-layer-restriction-on-some.patch
Description: Binary data
___
Mailing list: https://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] pls merge my pull-request in kicad-i18n

[Russell Oliver]

Hi Liyoubu,

Currently the process for accepting contributions is through patches sent
to the mailing list for review.

More information can be found at
http://kicad-pcb.org/contribute/developers/#_submitting_patches

Kind Regards
Russell

On 13 Aug 2017 11:05, "liyoubdu"  wrote:

> Time has passed for a long time, why not merge my request in github?
> https://github.com/KiCad/kicad-i18n/pull/150
>
> ___
> Mailing list: https://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] teardrops & rounded corners & ???

[Russell Oliver]

Hi Heikki,

Do you know which commit or release that you started developing the
features from? I'll see if i can recreate the necessary git history.

Regards
Russell

On Sat, May 27, 2017 at 4:34 PM Heikki Pulkkinen  wrote:

> And that menu structure is what it is. It is there just testing purposes.
> It can be done more intuitive for all users.
>
> Teardrops and these things is going to change kicad_pcb file making
> additions end of file. And that stitch via thermal word is threre too.
>
> 26.5.2017 23.13 "Kaspar Emanuel"  kirjoitti:
>
>> I managed to compile by copying the missing files over from the main
>> KiCAD repo. Seems to be working fine!
>>
>> Initial feedback:
>>
>>- Thanks very much for working on this!
>>- The menu is very unintuitive but is it useful to give feedback on
>>this? Is it just an intermediate menu for you to continue development or
>>are you planning for the final functionality to be similar to what you 
>> have
>>there?
>>
>> I will continue to experiment with it in the meantime.
>> ​
>>
>> On 25 May 2017 at 22:59, Nick Østergaard  wrote:
>>
>>> Basically described in https://help.github.com/articles/fork-a-repo/
>>>
>>> (there might exist better tutorials)
>>>
>>> 2017-05-25 21:22 GMT+02:00 Nick Østergaard :
>>> >
>>> >
>>> > Den 25/05/2017 19.42 skrev "Kaspar Emanuel" >> >:
>>> >
>>> > Hey Heikki,
>>> >
>>> > I wanted to give this a test with a small board I thought would look
>>> nicer
>>> > with curved traces.
>>> >
>>> > During the cmake step I noticed following error but was still able to
>>> > proceed to the make step.
>>> >
>>> > CMake Error at common/CMakeLists.txt:344 (add_library):
>>> >   Cannot find source file:
>>> >
>>> > build_version.cpp
>>> >
>>> >   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
>>> .hpp
>>> >   .hxx .in .txx
>>> >
>>> > CMake Error at pcbnew/CMakeLists.txt:637 (add_library):
>>> >   Cannot find source file:
>>> >
>>> > build_BOM_from_board.cpp
>>> >
>>> >   Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
>>> .hpp
>>> >   .hxx .in .txx
>>> >
>>> > But the make step exited with a similar error:
>>> >
>>> >
>>> /home/kaspar/projects/kicad/heikkipu-kicad-devel/pcbnew/legacy_plugin.cpp:89:27:
>>> > fatal error: build_version.h: No such file or directory
>>> > compilation terminated.
>>> > common/CMakeFiles/pcbcommon.dir/build.make:1020: recipe for target
>>> > 'common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o' failed
>>> > make[2]: ***
>>> [common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o]
>>> > Error 1
>>> > make[2]: *** Waiting for unfinished jobs
>>> > CMakeFiles/Makefile2:521: recipe for target
>>> > 'common/CMakeFiles/pcbcommon.dir/all' failed
>>> > make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2
>>> > Makefile:149: recipe for target 'all' failed
>>> > make: *** [all] Error 2
>>> >
>>> > Hope this helps, let me know what to do and I can continue trying to
>>> compile
>>> > it.
>>> >
>>> > Cheers,
>>> >
>>> > Kaspar
>>> >
>>> > P.S. How come your Git repository doesn’t have the same history as
>>> KiCAD git
>>> > repository?
>>> >
>>> > Yeah, that is not the way to send patches. You need to commit in a
>>> local
>>> > branch from the upstream kicad master branch anf push that.
>>> >
>>> >
>>> > On 21 May 2017 at 09:41, Heikki Pulkkinen  wrote:
>>> >>
>>> >> Hi Wayne and all
>>> >>
>>> >> Want to test.
>>> >>
>>> >> https://github.com/heikkipu/kicad-devel
>>> >>
>>> >> And yes, it is going to change kicad_pcb file.
>>> >>
>>> >>
>>> >> Regards
>>> >>
>>> >> Heikki
>>> >>
>>> >> ___
>>> >> Mailing list: https://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] [Feature] Position Relative to

[Russell Oliver]

Hi Tomasz,

Attached is an updated patch to align more with the coding policy.

Regards
Russell



Regards
Russell Oliver



On 29 April 2017 at 02:45, Russell Oliver <roliver8...@gmail.com> wrote:

> Hi Tom,
>
> I'll check it against the code style rules to see what I could improve on.
> With regards to the not using wxPoints in the tool code I have used the
> MoveExact action of the edit tool as my template which uses the wxPoint
> quite often, and more broadly it is used throughout the Edit tool. Going
> forward is the use of the VECTOR2I type preferred for coordinates?
>
> Regards
> Russell
>
> On Sat, Apr 29, 2017 at 2:33 AM Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> On 28.04.2017 18:26, Russell Oliver wrote:
>> > Hello All,
>> >
>> > For the purpose of accurately placing components I have developed a
>> > relative positioning tool.
>> > Right clicking > Position Relative to or Control-R on selected items
>> > will bring up a dialog the same as the Move exact tool with a button for
>> > selecting another item, the 'achor'. Upon clicking OK the first
>> > selection is moved to a position relative to the anchor.
>> > The position of anchor item is also displayed.
>> >
>> > Attached is the patch.
>> >
>> > Any comments on the functionality or code quality would be appreciated.
>> >
>>
>> Hi Russell,
>>
>> Thanks for the patch. Few comments:
>> - please follow the coding style rules,
>> - don't use wxPoints/wxSizes in the tool code (if not for the purpose of
>> interfacing with the BOARD_ITEMs).
>>
>> Cheers,
>> Tom
>>
>> > Regards
>> > Russell Oliver
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>


position-relative.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Feature] Position Relative to

[Russell Oliver]

Hi Tom,

I'll check it against the code style rules to see what I could improve on.
With regards to the not using wxPoints in the tool code I have used the
MoveExact action of the edit tool as my template which uses the wxPoint
quite often, and more broadly it is used throughout the Edit tool. Going
forward is the use of the VECTOR2I type preferred for coordinates?

Regards
Russell

On Sat, Apr 29, 2017 at 2:33 AM Tomasz Wlostowski <tomasz.wlostow...@cern.ch>
wrote:

> On 28.04.2017 18:26, Russell Oliver wrote:
> > Hello All,
> >
> > For the purpose of accurately placing components I have developed a
> > relative positioning tool.
> > Right clicking > Position Relative to or Control-R on selected items
> > will bring up a dialog the same as the Move exact tool with a button for
> > selecting another item, the 'achor'. Upon clicking OK the first
> > selection is moved to a position relative to the anchor.
> > The position of anchor item is also displayed.
> >
> > Attached is the patch.
> >
> > Any comments on the functionality or code quality would be appreciated.
> >
>
> Hi Russell,
>
> Thanks for the patch. Few comments:
> - please follow the coding style rules,
> - don't use wxPoints/wxSizes in the tool code (if not for the purpose of
> interfacing with the BOARD_ITEMs).
>
> Cheers,
> Tom
>
> > Regards
> > Russell Oliver
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] S-Expression schematic format specification

[Russell Oliver]

Hi All,

I was looking through the roadmap for Kicad 5 and saw that work is being
done on the new schematic format. I was wondering if the draft
specification is available anywhere and whether I could assist in
developing it.


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

Re: [Kicad-developers] [RFC PATCH] Single-click board update, take 2.

[Russell Oliver]

Hi all,

As a crazy thought related to having the board capture orphan pads under an
parent footprint,  conceptually what about a pcb being represented as a
hierarchy of footprints.

>From what I understand most elements of a board can be included in
footprints except for tracks. If tracks could be included as part of a
"footprint" would it not be possible to export a group of footprints and
tracks as a new reusable section of already laid out  components.

Regards
Russell
On 30 Jan 2016 04:29, "jp charras"  wrote:

> Le 29/01/2016 16:57, Tomasz Wlostowski a écrit :
> > On 29.01.2016 16:49, Chris Pavlina wrote:
> >> Oh, it's definitely a dirty hack - but it's a dirty hack that is
> somewhat
> >> necessary, and used to be possible, and now it's not, so... regression,
> dude!
> >> :)
> >>
> >> Yeah, yeah, I'm a spacebar heater, I know... :D
> >>
> >> https://xkcd.com/1172/
> >>
> > No, you're not :) I perfectly agree with your reasoning and I'll add an
> > option to disable component removal.
> >
> >> I'd argue that while using a footprint as a via is a dirty hack, the
> simple
> >> concept of allowing footprints on the PCB that aren't on the schematic
> is
> >> *not*. Lots of people want to be able to place things like mounting
> holes
> >> without having to put them in the schematic. (Whether or not that's best
> >> practice is beside the point, it's very common.)
> >
> > Most tools I've used require that the components on the schematic fully
> > match the PCB, but they also allow drawing mounting holes as 'free'
> > pads. This is another limitation of pcbnew - in Eagle/Altium you can
> > just draw an arbitrary pad straight on the PCB.
>
>  " In Kicad, it requires a footprint (and so the sch/pcb inconsistency)."
>
> This is not true.
> In Pcbnew, pads can live outside a footprint.
> (They are used in the pad properties editor)
>
> But without a footprint, you cannot manage easily the net of this pad.
> Just because schematic knows only footprints, the net of the orphan pads
> cannot be managed by the schematic.
>
> Therefore users have to manage the net of these orphan pads *by hand*.
> and these pads create sch/pcb inconsistency
> AFAIK, Altium has not solved this issue (sch/pcb inconsistency).
>
> To fix this kind of issue, we need a good idea, not just mimic what is
> made in Eagle/Altium.
> I have already used Altium, and worked with guys who are using Altium,
> but I am not a Altium specialist.
> I have seen some very good and powerful ideas (rooms), and some less
> good ideas (Well, I was not impressed by ERC and net management)
>
> My preferred idea (I am not saying this is a good idea) is to consider
> the board itself as a parent footprint these "orphan" pads.
>
> Power connections could be managed at schematic level by something like
> a few test or connect points ( pins of the board, seen like a footprint)
> connected to the nets (usually GND, VCC ...)  we want to connect to
> these "orphan" pads
> Stitching vias could be some of these "orphan" pads.
> You do not need a footprint by pad: only one footprint is enough.
>
> I am pretty sure this is not a lot of work to code that.
> At least less than trying to manage stitching vias as standard vias.
>
> >
> > Cheers,
> > Tom
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp