Re: [Kicad-developers] GerbView GAL port

[Jon Neal]

This doesn't answer any of your questions, but Mark Roszko did some
refactoring of gerbview that had some really nice changes. I believe he
started the refactoring with the intention of switching gerbview over to
GAL.

https://github.com/marekr/kicad-devel

Jon Neal

On Tue, Feb 14, 2017 at 1:38 PM Jon Evans  wrote:

> Hi all,
>
> I want to get familiar with the GAL codebase, and it occurred to me that
> it might be fun to play with porting GerbView to GAL.  I know it is on the
> 6.x roadmap, but it seemed to me that it would be mostly not dependent on
> any other changes that I see on the roadmap or have seen people talking
> about on the mailing list.
>
> - Is anyone currently working on this?
>
> - Does anyone think it would be a bad idea for me to start working on this
> now?
>
> - If a GAL port is "feature-complete", is there any reason for the app to
> retain the legacy graphics code, or can it just provide OpenGL and Cairo
> backends?  My impression is the only think keeping legacy canvas in pcbnew
> is feature differences between legacy and GAL, but I wanted to check if
> there are other reasons.
>
> - In my first hour of looking at the code for this, it seems like the GAL
> code currently has some interdependence with pcbnew that needs to be
> straightened out before using GAL in other applications.  For example,
> EDA_DRAW_PANEL_GAL depends on PCB_PAINTER, not a generic PAINTER.  Is this
> an open problem for anyone to tackle, or does anyone actively have plans to
> refactor this?
>
> Best,
> Jon
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] BOM Editor

[Thiadmer Riemersma]

Hello Clemens,

Why not have one _database_ in between schematic and layout and
> manufacturing, assembly (and ERP and ...) and the tools just pick what they
> need?


I agree that this is the better option. But it is also an ambitious
project. For example, for machine assembly, the global database must also
hold feeder details (tape/tube/tray, step size, reel size), orientation in
the packaging, component height, best nozzle to use to pick it up, and
probably other parameters that I am forgetting right now.

On Tue, Feb 14, 2017 at 2:52 PM, Clemens Koller  wrote:

> Hi, Thiadmer!
>
> On 2017-02-14 12:21, Thiadmer Riemersma wrote:
> > And as others have already observed: a BOM tools sits in the middle of
> workflow.
>
> I agree here!
>
> > The software to prepare our pick & place machine has a BOM editor.
> > Our ordering/inventory system has a BOM editor too.
> > So what I think is important is flexible export /and/ flexible import.
>
> ... but import/exporting data in between the tools is IMO still not the
> best solution I can imagine.
> I/Os are off course still necessary, but using a lot of spreadsheet glue
> the processes seem more error-prone and are harder to verify for
> correctness when data is kept and needs to be synced in different places.
>
> I wish/tend to centralize all my data in an (open / from different tools
> accessible) database storage as much as possible and keep only the relevant
> data in the different tools.
> This approach seems also the trend in advanced commercial tools, however
> they use their own proprietary databases for customer-lock-in and sell it
> as best way for performance.
>
> > So that changes made to the BOM can be imported into KiCad and
> back-annotated in the schematic.
>
> Why not have one _database_ in between schematic and layout and
> manufacturing, assembly (and ERP and ...) and the tools just pick what they
> need?
>
> Regards,
>
> Clemens
>
> >
> > On Tue, Feb 14, 2017 at 11:47 AM, Clemens Koller > wrote:
> >
> > Hello, Martin!
> >
> > Your work looks very promising.
> > I am running very similar stuff "manually" (by executing .sql
> scripts) around my commercial tool.
> >
> > Is there an ODBC in between your frontend code and the Firebird
> database you use?
> > I am asking because the data here sits in a MariaDB storage.
> >
> > Regards,
> >
> > Clemens
> >
> > On 2017-02-14 08:55, Martin Schreiber wrote:
> > > On Tuesday 14 February 2017 07:20:23 Oliver Walters wrote:
> > >> Hi all,
> > >>
> > >> I have been working on a BOM exporter built into KiCad (in
> addition to the
> > >> external BOM script functionality that already exists).
> > >>
> > >> It's not ready yet to be merged but I am showing the progress
> here to get
> > >> any input and in case anyone else is working on a similar feature.
> > >>
> > > I am working on a standalone tool which extracts component field
> values from
> > > schematics
> > > and looks-up the component, footprints and BOM-values in a
> database:
> > > http://mseide-msegui.sourceforge.net/pics/msekicadbom.png <
> http://mseide-msegui.sourceforge.net/pics/msekicadbom.png>
> > > Component fields can be composed by macros:
> > > http://mseide-msegui.sourceforge.net/pics/component.png <
> http://mseide-msegui.sourceforge.net/pics/component.png>
> > > and be based on a component-kind-template:
> > > http://mseide-msegui.sourceforge.net/pics/componentkind.png <
> http://mseide-msegui.sourceforge.net/pics/componentkind.png>
> > >
> > > MSEkicadBOM can be used to produce the various production and
> documentation
> > > files:
> > > http://mseide-msegui.sourceforge.net/pics/production.png <
> http://mseide-msegui.sourceforge.net/pics/production.png>
> > > http://mseide-msegui.sourceforge.net/pics/docuset.png <
> http://mseide-msegui.sourceforge.net/pics/docuset.png>
> > >
> > > The code is here:
> > > https://gitlab.com/mseide-msegui/mseuniverse/tree/
> master/tools/kicad/bom  master/tools/kicad/bom>
> > >
> > > Martin
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : 

Re: [Kicad-developers] Stable release 4.0.6

[Marco Ciampa]

On Tue, Feb 14, 2017 at 09:26:21AM -0500, Wayne Stambaugh wrote:
> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release?  If not, I will set the version string and tag that commit as
> 4.0.6.  How much time do our source translators, doc devs, and library
> devs need to have everything ready?

For these minor stable releases, concerning the i18n stuff, I think that
a couple of days will suffice...

--


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

Re: [Kicad-developers] Stable release 4.0.6

[Oliver Walters]

There are no large items outstanding for the libs, can be tagged at any
time.

On 15 Feb 2017 01:30, "Wayne Stambaugh"  wrote:

> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release?  If not, I will set the version string and tag that commit as
> 4.0.6.  How much time do our source translators, doc devs, and library
> devs need to have everything ready?
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] GerbView GAL port

[Jon Evans]

Hi all,

I want to get familiar with the GAL codebase, and it occurred to me that it
might be fun to play with porting GerbView to GAL.  I know it is on the 6.x
roadmap, but it seemed to me that it would be mostly not dependent on any
other changes that I see on the roadmap or have seen people talking about
on the mailing list.

- Is anyone currently working on this?

- Does anyone think it would be a bad idea for me to start working on this
now?

- If a GAL port is "feature-complete", is there any reason for the app to
retain the legacy graphics code, or can it just provide OpenGL and Cairo
backends?  My impression is the only think keeping legacy canvas in pcbnew
is feature differences between legacy and GAL, but I wanted to check if
there are other reasons.

- In my first hour of looking at the code for this, it seems like the GAL
code currently has some interdependence with pcbnew that needs to be
straightened out before using GAL in other applications.  For example,
EDA_DRAW_PANEL_GAL depends on PCB_PAINTER, not a generic PAINTER.  Is this
an open problem for anyone to tackle, or does anyone actively have plans to
refactor this?

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

Re: [Kicad-developers] {PATCH] Icon tweaks

[John Beard]

Hi,

I think Konstantin's icons are a more complete and homegenous set -
I'd rather see those go in first. If there is still any use for my
icons after that, I can rebase on top of that.

He and I have talked about rebasing his branch into a simpler set of
smaller patches (eg. just zoom icons) for easier review, since I think
icons can easily attracts lots of comment, and getting bogged down in
talking about colours of vias when the zoom icons are fine would be
frustrating!

Cheers,

John

On Wed, Feb 15, 2017 at 12:37 AM, Fabrizio Tappero
 wrote:
> Hi Wayne,
> John metion that his changes are on the tip of this branch:
>
> https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons
>
> Also, would you please be so kind to include this icon in attachment. I have
> some problem is generating the patch for it.
>
> thank you
> Fabrizio
>
>
>
> On Tue, Feb 14, 2017 at 3:39 PM, Wayne Stambaugh 
> wrote:
>>
>> Where do we stand on this?  I think these changes should be committed.
>> If there are no objections, please send a patch to the dev list so I can
>> merge it.
>>
>> On 2/10/2017 4:37 PM, John Beard wrote:
>> > Hi,
>> >
>> > I have a few tweaks to some icons in Pcbnew and Eeschema. These are
>> > mostly minor tweaks that are intended to make the icons match a little
>> > better and give a more uniform look and feel:
>> >
>> > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons
>> >
>> > * Pixel align a few icons to make then crisper when displayed
>> > * Redraw all the zoom icons to be crisper and flatter. The zoom to fit
>> > (Home) icon is now a sort of reticle rather than a pair of square
>> > brackets as text.
>> > * Redraw console icon to be flat to match other existing icons.
>> > * Mute some very bright colours, especially the green-legged module
>> > icons - use the zone icons as a guide for the colour brightness.
>> >
>> > Attached are screen shots of pcbnew and eeschema, where you can see
>> > some of the icons.
>> >
>> > I know icons and UI subjects in general are very subjective and
>> > personal, so I'd welcome input!
>> >
>> > Cheers,
>> >
>> > John
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://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] Icon tweaks

[Fabrizio Tappero]

Hi Wayne,
John metion that his changes are on the tip of this branch:

https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons

​Also, would you please be so kind to include this icon in attachment. I
have some problem is generating the patch for it.

thank you
Fabrizio



On Tue, Feb 14, 2017 at 3:39 PM, Wayne Stambaugh 
wrote:

> Where do we stand on this?  I think these changes should be committed.
> If there are no objections, please send a patch to the dev list so I can
> merge it.
>
> On 2/10/2017 4:37 PM, John Beard wrote:
> > Hi,
> >
> > I have a few tweaks to some icons in Pcbnew and Eeschema. These are
> > mostly minor tweaks that are intended to make the icons match a little
> > better and give a more uniform look and feel:
> >
> > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons
> >
> > * Pixel align a few icons to make then crisper when displayed
> > * Redraw all the zoom icons to be crisper and flatter. The zoom to fit
> > (Home) icon is now a sort of reticle rather than a pair of square
> > brackets as text.
> > * Redraw console icon to be flat to match other existing icons.
> > * Mute some very bright colours, especially the green-legged module
> > icons - use the zone icons as a guide for the colour brightness.
> >
> > Attached are screen shots of pcbnew and eeschema, where you can see
> > some of the icons.
> >
> > I know icons and UI subjects in general are very subjective and
> > personal, so I'd welcome input!
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://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] OT: Trends in number of on-chip I/Os...

[Jon Evans]

Here are some approaches I know about (some of these available in KiCad
today, some of them not until tomorrow :-)

- Splitting up the part into logical blocks as Mark said

- Depending on user preference / company policy, using component attributes
to map all power and ground pins rather than showing them on the schematic
(i.e. hidden pins)

- Importing symbol pinout from a spreadsheet -- the vendor typically will
provide a spreadsheet (or tool for generating spreadsheet based on how you
choose the alternate functions of pins), and then you import this into your
library tool.

- Some tools can even generate the symbols from a spreadsheet (you just
have a column in the spreadsheet that assigns the pins to a logical block,
and each block gets a symbol generated)

- High-end EDA tools usually have DRC rules for checking that you have
appropriate number of bypass capacitors for the power pins, and that they
are located close enough to the power pins.

- When it comes time to do the layout, with large BGAs, some tools have
nice ways to break them up into zones and apply different fan-out behavior
based on the zone, to maximize the escape pathways (and thereby minimize
the number of layers needed for fan-out):  See page 167 of this somewhat
interesting book:
http://www.aetpcb.com/aet/net_resources/help/BGA_Breakouts_and_Routing.pdf

Food for thought...

-Jon

On Tue, Feb 14, 2017 at 9:20 AM, Mark Roszko  wrote:

> You split up the one part into multiple blocks with common
> functionality grouped the same way you may have a U9A and U9B of a
> logic IC with two gates. You'll just use quite a few pages
>
> ___
> Mailing list: https://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] Correctly filter copyable objects for copy hotkey (Fixes lp:1571316)

[Wayne Stambaugh]

Your patch has been merged into the master branch.  Thank you for you
contribution to KiCad.

Cheers,

Wayne

On 2/11/2017 1:31 PM, Jon Evans wrote:
> Hi,
> 
> Minor patch to eeschema attached to fix reported issue with clarify menu.
> 
> -Jon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Wayne Stambaugh]

Where do we stand on this?  I think these changes should be committed.
If there are no objections, please send a patch to the dev list so I can
merge it.

On 2/10/2017 4:37 PM, John Beard wrote:
> Hi,
> 
> I have a few tweaks to some icons in Pcbnew and Eeschema. These are
> mostly minor tweaks that are intended to make the icons match a little
> better and give a more uniform look and feel:
> 
> https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons
> 
> * Pixel align a few icons to make then crisper when displayed
> * Redraw all the zoom icons to be crisper and flatter. The zoom to fit
> (Home) icon is now a sort of reticle rather than a pair of square
> brackets as text.
> * Redraw console icon to be flat to match other existing icons.
> * Mute some very bright colours, especially the green-legged module
> icons - use the zone icons as a guide for the colour brightness.
> 
> Attached are screen shots of pcbnew and eeschema, where you can see
> some of the icons.
> 
> I know icons and UI subjects in general are very subjective and
> personal, so I'd welcome input!
> 
> Cheers,
> 
> John
> 
> 
> 
> ___
> Mailing list: https://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] Stable release 4.0.6

[Adam Wolf]

OS X will be faster this time, probably 2 days or fewer once
everything is ready from libs and docs.

Adam Wolf
W

On Tue, Feb 14, 2017 at 8:26 AM, Wayne Stambaugh  wrote:
> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release?  If not, I will set the version string and tag that commit as
> 4.0.6.  How much time do our source translators, doc devs, and library
> devs need to have everything ready?
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Stable release 4.0.6

[Wayne Stambaugh]

Are there any outstanding issues to prevent rolling out a 4.0.6 stable
release?  If not, I will set the version string and tag that commit as
4.0.6.  How much time do our source translators, doc devs, and library
devs need to have everything ready?

Thanks,

Wayne

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

Re: [Kicad-developers] OT: Trends in number of on-chip I/Os...

[Mark Roszko]

You split up the one part into multiple blocks with common
functionality grouped the same way you may have a U9A and U9B of a
logic IC with two gates. You'll just use quite a few pages

___
Mailing list: https://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] OT: Trends in number of on-chip I/Os...

[Clemens Koller]

Hi,

just for fun/information from the (german) news:
http://www.elektroniknet.de/markt-technik/halbleiter/details-zu-power9-138554.html

The Power9 Processor Family has internally 2359 Signals, 7370 Power (10 
different voltages) and 9909 Ground-Pins.

This is of course (not yet) on board level, but how do they visualize this 
bunch in an schematic?

Regards,

Clemens

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

Re: [Kicad-developers] [RFC] BOM Editor

[Clemens Koller]

Hi, Thiadmer!

On 2017-02-14 12:21, Thiadmer Riemersma wrote:
> And as others have already observed: a BOM tools sits in the middle of 
> workflow.

I agree here!

> The software to prepare our pick & place machine has a BOM editor.
> Our ordering/inventory system has a BOM editor too.
> So what I think is important is flexible export /and/ flexible import.

... but import/exporting data in between the tools is IMO still not the best 
solution I can imagine.
I/Os are off course still necessary, but using a lot of spreadsheet glue the 
processes seem more error-prone and are harder to verify for correctness when 
data is kept and needs to be synced in different places.

I wish/tend to centralize all my data in an (open / from different tools 
accessible) database storage as much as possible and keep only the relevant 
data in the different tools.
This approach seems also the trend in advanced commercial tools, however they 
use their own proprietary databases for customer-lock-in and sell it as best 
way for performance.

> So that changes made to the BOM can be imported into KiCad and back-annotated 
> in the schematic.

Why not have one _database_ in between schematic and layout and manufacturing, 
assembly (and ERP and ...) and the tools just pick what they need?

Regards,

Clemens

> 
> On Tue, Feb 14, 2017 at 11:47 AM, Clemens Koller  > wrote:
> 
> Hello, Martin!
> 
> Your work looks very promising.
> I am running very similar stuff "manually" (by executing .sql scripts) 
> around my commercial tool.
> 
> Is there an ODBC in between your frontend code and the Firebird database 
> you use?
> I am asking because the data here sits in a MariaDB storage.
> 
> Regards,
> 
> Clemens
> 
> On 2017-02-14 08:55, Martin Schreiber wrote:
> > On Tuesday 14 February 2017 07:20:23 Oliver Walters wrote:
> >> Hi all,
> >>
> >> I have been working on a BOM exporter built into KiCad (in addition to 
> the
> >> external BOM script functionality that already exists).
> >>
> >> It's not ready yet to be merged but I am showing the progress here to 
> get
> >> any input and in case anyone else is working on a similar feature.
> >>
> > I am working on a standalone tool which extracts component field values 
> from
> > schematics
> > and looks-up the component, footprints and BOM-values in a database:
> > http://mseide-msegui.sourceforge.net/pics/msekicadbom.png 
> 
> > Component fields can be composed by macros:
> > http://mseide-msegui.sourceforge.net/pics/component.png 
> 
> > and be based on a component-kind-template:
> > http://mseide-msegui.sourceforge.net/pics/componentkind.png 
> 
> >
> > MSEkicadBOM can be used to produce the various production and 
> documentation
> > files:
> > http://mseide-msegui.sourceforge.net/pics/production.png 
> 
> > http://mseide-msegui.sourceforge.net/pics/docuset.png 
> 
> >
> > The code is here:
> > 
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/tools/kicad/bom 
> 
> >
> > Martin
> >
> > ___
> > Mailing list: https://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   : 

Re: [Kicad-developers] [RFC] BOM Editor

[Martin Schreiber]

On Tuesday 14 February 2017 11:47:52 Clemens Koller wrote:
> Hello, Martin!
>
> Your work looks very promising.
> I am running very similar stuff "manually" (by executing .sql scripts)
> around my commercial tool.
>
> Is there an ODBC in between your frontend code and the Firebird database
> you use? I am asking because the data here sits in a MariaDB storage.
>
No, MSEkicadBOM uses the Firebird 3 connection component of MSEgui. MSEgui 
currently also has DB connectors for SQlite3, ODBC, Postgres and MySQL so 
porting to MariaDB should be possible.

Martin

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

Re: [Kicad-developers] .SWEET file suggestion

[Simon Richter]

Hi,

On 14.02.2017 10:54, Strontium wrote:

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

Yes, that's one of the end goals of the pin table, but with work
consuming most of my day, I didn't get around to that yet.

> Schematic DRC would then have an Error/Warning for pins not used.

This is why the pin table has a summary, where it tries to create ranges
from the defined pins. A 144 pin component is completely defined when
the summary says "1-144", and a 324 pin BGA component is complete when
the summary says "A1-S19".

   Simon



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

Re: [Kicad-developers] .SWEET file suggestion

[Nick Østergaard]

I think it would be nice if the symbols were actyally dynamic, in the sense
the the pin funtion is selectable interactively in eeschema, instead of
syncing it with an extetnal db. The external db if implemented coukd ocf
still be used to generate this dynamic symbol, in theory.

Den 14/02/2017 11.41 skrev "Clemens Koller" :

> Hello, Stromtium!
>
> Thank you for your heads-up!
> I fully agree here and can't resist to "think big" and motivate when we
> are planning to support some future design entry methodologies in the long
> term.
>
> Today, we already have:
>   400++ configurable Pins of a FPGA
> + 300++ muxable Pins of a CPU
> + 300+ Pins I/O Connector
> + RAM
> + lots of other stuff
> --
> = Ridiculous to draw and manage single pins in schematic symbols spread
> over 30 pages.
>
> Solution:
> - Table based entry with import/export functionality. I mean SQL here and
> _not_ (only) spreadsheets. There will be demand for a *Synchronize*-button
> at some point in time.
>
> - "Schematic symbols" are generated dynamically. (Similar to these Pin Mux
> Tools which are generating C-code for CPU initialization / device trees).
> These symbols might look completely different than rectangular boxes with
> feathers on the sides, placed on a page.
>
> - Grouping +folding/unfolding and zooming/scaling of symbols could come in
> handy.
>
> The I/Os and their properties of a component might get grouped by i.e.
> POWER, USB, ETH, DDR2, SPI, ...
> Then they can be dynamically arranged / ordered by group,pinno or
> group,pinname, ...
> Putting this table/view in a frame to place it on a schematic sheet is
> then a nice goodie, but not even necessary.
> Search & replace capability and the import/export functionality is a must.
>
> This might affect the file formats of library components as well as the
> schematics.
>
> Regards,
>
> Clemens
>
> On 2017-02-14 10:54, Strontium wrote:
> > Can I make the suggestion, for CPU/MCU/FPGA type parts that have lots of
> configurable pins, drawing an actual component is tedious and somewhat
> pointless as its just a box (or multiple boxes, one for each subunit) with
> pins.
> >
> > Some CPU's have so many functional units and pins that fitting it all on
> one giant box is also pointless as it may not even fit on a a3 page, so you
> end up with multiple parts in a component for various functional divisions
> and then multiple versions of the same component to account for different
> GPIO multiplexing arrangements, which change and evolve as the design
> evolves.  It quickly becomes a maintenance problem.
> >
> > For example, you decide GPIO 7 is good for a LED, but later, oh no GPIO
> 7 is the last SPI chip select, oh ok, swap it with GPIO 184, but no, its
> not that easy now you have to edit the component to reflect it, and now
> every design you have that uses the same CPU ends up with a unique version
> of the component to match its GPIO muxing.
> >
> > I believe it would be far preferable for these types of components
> simply to define the functions of each pin in a table, and then when
> placing the part, its just an empty box (like a nested sheet).  You then
> right click on the part select "Add pin" and then select from the list of
> unplaced pins the one you want, and its function.  You then drop the pin on
> one of the 4 sides of the box.
> >
> > Basically like the nested sheet/sheet pin in concept, except you can
> select which pin to import from the list of pins not yet utilised.
> >
> > This way one only need to define a single component, and editing it is
> just a matter of editing a table of pins, which is very easy compared to
> drawing a component with 100's of pins.  You then "draw" the part uniquely
> for your design on your schematic, as you use each pin, but you only ever
> have one part defined in your library.
> >
> > Schematic DRC would then have an Error/Warning for pins not used.  This
> would make it much easier with complex parts, for example, you have a USB
> page, you only need the pins from the cpu chip for USB sub unit, and if you
> decide to change the OTG ID pin to a different GPIO, you don't need to
> redraw your part, or have multiple "versions" of your part, you just delete
> the old ID GPIO pin, and add the new one.
> >
> > This would be in addition to the current graphical parts, which are
> preferable for basic components and standard building blocks.
> >
> > Steven
> >
> > On 13/02/17 18:32, Oliver Walters wrote:
> >> Here is a good example of where such a feature would be very well
> received: https://forum.kicad.info/t/component-occupies-entire-
> page-newbie/5272/22
> >>
> >> On Thu, Jan 5, 2017 at 12:10 AM, Chris Pavlina  > wrote:
> >>
> >> I second this suggestion. Numerous people have been proposing this
> for
> >> quite a long time in IRC, it's a popular idea. A large number of
> parts
> >> are configurable, and forcing the pins to be 

Re: [Kicad-developers] [RFC] BOM Editor

[Thiadmer Riemersma]

Hello Oliver,

One option that I would like is to have a column with package names, rather
than (or in addition to) footprint names. So that
Capacitor_SMD:0805_Handsoldering becomes simply 0805. That is easier for
the stock management and ordering process.

And as others have already observed: a BOM tools sits in the middle of
workflow. The software to prepare our pick & place machine has a BOM
editor. Our ordering/inventory system has a BOM editor too. So what I think
is important is flexible export *and* flexible import. So that changes made
to the BOM can be imported into KiCad and back-annotated in the schematic.

Regards,
Thiadmer

On Tue, Feb 14, 2017 at 11:47 AM, Clemens Koller  wrote:

> Hello, Martin!
>
> Your work looks very promising.
> I am running very similar stuff "manually" (by executing .sql scripts)
> around my commercial tool.
>
> Is there an ODBC in between your frontend code and the Firebird database
> you use?
> I am asking because the data here sits in a MariaDB storage.
>
> Regards,
>
> Clemens
>
> On 2017-02-14 08:55, Martin Schreiber wrote:
> > On Tuesday 14 February 2017 07:20:23 Oliver Walters wrote:
> >> Hi all,
> >>
> >> I have been working on a BOM exporter built into KiCad (in addition to
> the
> >> external BOM script functionality that already exists).
> >>
> >> It's not ready yet to be merged but I am showing the progress here to
> get
> >> any input and in case anyone else is working on a similar feature.
> >>
> > I am working on a standalone tool which extracts component field values
> from
> > schematics
> > and looks-up the component, footprints and BOM-values in a database:
> > http://mseide-msegui.sourceforge.net/pics/msekicadbom.png
> > Component fields can be composed by macros:
> > http://mseide-msegui.sourceforge.net/pics/component.png
> > and be based on a component-kind-template:
> > http://mseide-msegui.sourceforge.net/pics/componentkind.png
> >
> > MSEkicadBOM can be used to produce the various production and
> documentation
> > files:
> > http://mseide-msegui.sourceforge.net/pics/production.png
> > http://mseide-msegui.sourceforge.net/pics/docuset.png
> >
> > The code is here:
> > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/tools/kicad/bom
> >
> > Martin
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] BOM Editor

[Clemens Koller]

Hello, Martin!

Your work looks very promising.
I am running very similar stuff "manually" (by executing .sql scripts) around 
my commercial tool.

Is there an ODBC in between your frontend code and the Firebird database you 
use?
I am asking because the data here sits in a MariaDB storage.

Regards,

Clemens

On 2017-02-14 08:55, Martin Schreiber wrote:
> On Tuesday 14 February 2017 07:20:23 Oliver Walters wrote:
>> Hi all,
>>
>> I have been working on a BOM exporter built into KiCad (in addition to the
>> external BOM script functionality that already exists).
>>
>> It's not ready yet to be merged but I am showing the progress here to get
>> any input and in case anyone else is working on a similar feature.
>>
> I am working on a standalone tool which extracts component field values from 
> schematics 
> and looks-up the component, footprints and BOM-values in a database:
> http://mseide-msegui.sourceforge.net/pics/msekicadbom.png
> Component fields can be composed by macros:
> http://mseide-msegui.sourceforge.net/pics/component.png
> and be based on a component-kind-template:
> http://mseide-msegui.sourceforge.net/pics/componentkind.png
> 
> MSEkicadBOM can be used to produce the various production and documentation 
> files:
> http://mseide-msegui.sourceforge.net/pics/production.png
> http://mseide-msegui.sourceforge.net/pics/docuset.png
> 
> The code is here:
> https://gitlab.com/mseide-msegui/mseuniverse/tree/master/tools/kicad/bom
> 
> Martin
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] .SWEET file suggestion

[Clemens Koller]

Hello, Stromtium!

Thank you for your heads-up!
I fully agree here and can't resist to "think big" and motivate when we are 
planning to support some future design entry methodologies in the long term.

Today, we already have:
  400++ configurable Pins of a FPGA
+ 300++ muxable Pins of a CPU
+ 300+ Pins I/O Connector
+ RAM
+ lots of other stuff
--
= Ridiculous to draw and manage single pins in schematic symbols spread over 30 
pages.

Solution: 
- Table based entry with import/export functionality. I mean SQL here and _not_ 
(only) spreadsheets. There will be demand for a *Synchronize*-button at some 
point in time.

- "Schematic symbols" are generated dynamically. (Similar to these Pin Mux 
Tools which are generating C-code for CPU initialization / device trees). These 
symbols might look completely different than rectangular boxes with feathers on 
the sides, placed on a page.

- Grouping +folding/unfolding and zooming/scaling of symbols could come in 
handy.

The I/Os and their properties of a component might get grouped by i.e. POWER, 
USB, ETH, DDR2, SPI, ...
Then they can be dynamically arranged / ordered by group,pinno or 
group,pinname, ...
Putting this table/view in a frame to place it on a schematic sheet is then a 
nice goodie, but not even necessary.
Search & replace capability and the import/export functionality is a must.

This might affect the file formats of library components as well as the 
schematics.

Regards,

Clemens

On 2017-02-14 10:54, Strontium wrote:
> Can I make the suggestion, for CPU/MCU/FPGA type parts that have lots of 
> configurable pins, drawing an actual component is tedious and somewhat 
> pointless as its just a box (or multiple boxes, one for each subunit) with 
> pins. 
> 
> Some CPU's have so many functional units and pins that fitting it all on one 
> giant box is also pointless as it may not even fit on a a3 page, so you end 
> up with multiple parts in a component for various functional divisions and 
> then multiple versions of the same component to account for different GPIO 
> multiplexing arrangements, which change and evolve as the design evolves.  It 
> quickly becomes a maintenance problem. 
> 
> For example, you decide GPIO 7 is good for a LED, but later, oh no GPIO 7 is 
> the last SPI chip select, oh ok, swap it with GPIO 184, but no, its not that 
> easy now you have to edit the component to reflect it, and now every design 
> you have that uses the same CPU ends up with a unique version of the 
> component to match its GPIO muxing.
> 
> I believe it would be far preferable for these types of components simply to 
> define the functions of each pin in a table, and then when placing the part, 
> its just an empty box (like a nested sheet).  You then right click on the 
> part select "Add pin" and then select from the list of unplaced pins the one 
> you want, and its function.  You then drop the pin on one of the 4 sides of 
> the box.
> 
> Basically like the nested sheet/sheet pin in concept, except you can select 
> which pin to import from the list of pins not yet utilised.
> 
> This way one only need to define a single component, and editing it is just a 
> matter of editing a table of pins, which is very easy compared to drawing a 
> component with 100's of pins.  You then "draw" the part uniquely for your 
> design on your schematic, as you use each pin, but you only ever have one 
> part defined in your library.
> 
> Schematic DRC would then have an Error/Warning for pins not used.  This would 
> make it much easier with complex parts, for example, you have a USB page, you 
> only need the pins from the cpu chip for USB sub unit, and if you decide to 
> change the OTG ID pin to a different GPIO, you don't need to redraw your 
> part, or have multiple "versions" of your part, you just delete the old ID 
> GPIO pin, and add the new one.
> 
> This would be in addition to the current graphical parts, which are 
> preferable for basic components and standard building blocks.
> 
> Steven
> 
> On 13/02/17 18:32, Oliver Walters wrote:
>> Here is a good example of where such a feature would be very well received: 
>> https://forum.kicad.info/t/component-occupies-entire-page-newbie/5272/22
>>
>> On Thu, Jan 5, 2017 at 12:10 AM, Chris Pavlina > > wrote:
>>
>> I second this suggestion. Numerous people have been proposing this for
>> quite a long time in IRC, it's a popular idea. A large number of parts
>> are configurable, and forcing the pins to be non-configurable makes ERC
>> pretty weak.
>>
>> On Wed, Jan 04, 2017 at 07:22:37PM +1100, Oliver Walters wrote:
>> > As far as I am aware, this (
>> > https://lists.launchpad.net/kicad-developers/msg23302.html 
>> ) is the latest
>> > proposal for the new symbol format.
>> >
>> > Is this the case?
>> >
>> > Reading through this I have an 

Re: [Kicad-developers] [RFC] BOM Editor

[Strontium]

Oliver,

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


Steven

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

Steven,

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


This may turn into more than just a BOM tool.

On Tue, Feb 14, 2017 at 9:00 PM, Strontium > wrote:


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

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

Steven


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

Hi all,

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

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

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

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

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

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

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

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

Regards,
Oliver


___
Mailing list:https://launchpad.net/~kicad-developers

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

[Kristoffer Ödmark]

I actually like this idea and can relate to the problem. Basically 
having "optional" pins, still retaining the alternate pin function though.


These are some hefty changes to the current implementation, but having 
the .sweet file system consider this might be an idea, so that this may 
be implemented in the future.


-Kristoffer

On 02/14/2017 10:54 AM, Strontium wrote:

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

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

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

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

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

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

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

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

Steven

On 13/02/17 18:32, Oliver Walters wrote:

Here is a good example of where such a feature would be very well
received: 
https://forum.kicad.info/t/component-occupies-entire-page-newbie/5272/22

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

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

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




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





___
Mailing list: 

Re: [Kicad-developers] [RFC] BOM Editor

[Oliver Walters]

Steven,

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

This may turn into more than just a BOM tool.

On Tue, Feb 14, 2017 at 9:00 PM, Strontium  wrote:

> This looks really nice, this would be awesome if it allowed you to edit
> the BOM as well, for example, your line 3, change 0.1uf to 1uf and C1, C7,
> C8, C9, C10 and C16 all change their value in the schematic to match.
> Obviously there are things you wouldnt be able to edit, such as Reference
> and Qty, but everything else should be editable.
>
> It would make keeping component annotations orderly very simple and bulk
> edits very very simple.
>
> Steven
>
>
> On 14/02/17 14:20, Oliver Walters wrote:
>
> Hi all,
>
> I have been working on a BOM exporter built into KiCad (in addition to the
> external BOM script functionality that already exists).
>
> It's not ready yet to be merged but I am showing the progress here to get
> any input and in case anyone else is working on a similar feature.
>
> Here's a screenshot of the current tool (launched from eeschema)
>
> http://i.imgur.com/nb3mqqx.png
>
> Features that are implemented thus far:
> - Extract all component fields
> - Group components based on user-selectable fields
> - Show conflicts when groups cannot be merged
> - Show/hide various columns
> - Sort part references in natural fashion, e.g. C99 < C100
> - CSV export
> - TSV export
> - HTML export
>
> Features still to be implemented:
> - Sort by column (ascending, descending)
> - Save BOM preferences to project file
> - Add filters to each column to include/exclude groups by wildcard or regex
> - Back-annotate component data (bulk update all components in a group)
>
> So, thoughts? I feel that a proper BOM tool has been sorely missing from
> Kicad thus far.
>
> If I continue to work on this is it something that is likely to be merged?
>
> Regards,
> Oliver
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] BOM Editor

[Strontium]

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


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


Steven

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

Hi all,

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


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


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

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

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

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

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

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


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

Regards,
Oliver


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



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

Re: [Kicad-developers] .SWEET file suggestion

[Strontium]

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


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


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


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


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


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


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


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


Steven

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


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


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

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




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



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

Re: [Kicad-developers] [PATCH] Prevent segfault when aOutline has no vertices.

[Nick Østergaard]

No, we don't really use sign-off's, but you added it to your patch.

2017-02-14 10:35 GMT+01:00 Clemens Koller :
> Thanks!
>
> Do we actually collect "Sign-offs" of the devs/authors for KiCAD?
>
> And - I forgot: There are similar locations in the code with could run into 
> the same issues.
> I didn't / couldn't check these.
>
> Regards,
>
> Clemens
>
>
>
> On 2017-02-13 23:33, Chris Pavlina wrote:
>> Thank you both. I pushed the fixed patch, crediting hauptmech as the
>> original author and leaving Clemens' signoff.
>>
>> On Mon, Feb 13, 2017 at 10:07:56PM +0100, Clemens Koller wrote:
>>> Well...
>>>
>>> I had a look at this for my very own training pleasure and updated the 
>>> patch from Hauptmechto to suit the coding style AFAICT.
>>> (attached)
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>> On 2017-02-13 21:09, hauptmech wrote:
 Thanks for the heads up Chris.

 Respectfully to the developers, I don't have time. If this does not
 match your coding style then consider it bug report.

 -Hauptmech

 On 14/02/17 04:00, Chris Pavlina wrote:
> Thank you for your contribution.
>
> We're generally pretty strict about the coding style for new code; it
> can be found at Documentation/development/coding-style-policy.md in the
> source tree. If you don't see what the problem is, pay particular
> attention to spacing around parentheses, and to the placement of braces
> {}. I'd normally just fix this myself on such a small patch, but since
> Wayne has taken this thread I'll let him wait for you to submit a fixed
> patch. Just thought I'd explain in a bit more detail.
>
> -- Chris



 ___
 Mailing list: https://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] Prevent segfault when aOutline has no vertices.

[Clemens Koller]

Thanks!

Do we actually collect "Sign-offs" of the devs/authors for KiCAD?

And - I forgot: There are similar locations in the code with could run into the 
same issues.
I didn't / couldn't check these.

Regards,

Clemens



On 2017-02-13 23:33, Chris Pavlina wrote:
> Thank you both. I pushed the fixed patch, crediting hauptmech as the
> original author and leaving Clemens' signoff.
> 
> On Mon, Feb 13, 2017 at 10:07:56PM +0100, Clemens Koller wrote:
>> Well...
>>
>> I had a look at this for my very own training pleasure and updated the patch 
>> from Hauptmechto to suit the coding style AFAICT.
>> (attached)
>>
>> Regards,
>>
>> Clemens
>>
>> On 2017-02-13 21:09, hauptmech wrote:
>>> Thanks for the heads up Chris.
>>>
>>> Respectfully to the developers, I don't have time. If this does not 
>>> match your coding style then consider it bug report.
>>>
>>> -Hauptmech
>>>
>>> On 14/02/17 04:00, Chris Pavlina wrote:
 Thank you for your contribution.

 We're generally pretty strict about the coding style for new code; it
 can be found at Documentation/development/coding-style-policy.md in the
 source tree. If you don't see what the problem is, pay particular
 attention to spacing around parentheses, and to the placement of braces
 {}. I'd normally just fix this myself on such a small patch, but since
 Wayne has taken this thread I'll let him wait for you to submit a fixed
 patch. Just thought I'd explain in a bit more detail.

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