Re: [Kicad-developers] Release 4.0.5 tagged.

[Nick Østergaard]

But this will not help if the user is using them locally. How is that
supposed to be handled?

2016-12-07 0:46 GMT+01:00 Carl Poirier :
> Hi Nick,
>
> I do understand but it is not an issue, Just try it out, go to
> https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty.
>
> Carl
>
> On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard  wrote:
>>
>> Hi Carl
>>
>> I have found an issue with the lib tagging. I think we decided to not
>> remove any libs for the patch releaes. That is for releases where only
>> the third number changes. What I see is:
>>
>> Buttons_Switches_ThroughHole.pretty remaned to Buttons_Switches_THT.pretty
>> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
>> Connect.pretty renamed to Connectors.pretty
>> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
>> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty
>> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty
>> Display.pretty renamed to Displays.pretty
>> Relays_ThroughHole.pretty renamed to Relays_THT.pretty
>> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty
>> Sockets_BNC.pretty removed?
>> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pretty
>>
>> Won't users have to manually update their fp-lib-table?
>>
>> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty  .
>> This looks correct, so that is ok.
>>
>> The fp-lib-table.for-pretty seems to match the repos tagged.
>>
>> Those renamed repos will easily summon errors in the users face. I
>> hope you understand what I mean.
>>
>> 2016-12-03 22:54 GMT+01:00 Carl Poirier :
>> > I will be tagging the libs in 24h.
>> >
>> > Carl
>> >
>> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf
>> > 
>> > wrote:
>> >>
>> >> I'll take a look early this week!
>> >>
>> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh 
>> >> wrote:
>> >>>
>> >>> Better late than never.  I just pushed the 4.0.5 stable release.  Just
>> >>> a
>> >>> note to the package devs, you no longer need to set the version string
>> >>> at config.  You can use KICAD_VERSION_EXTRA to append any package
>> >>> specific information to the "4.0.5" version string.  This will also
>> >>> hold
>> >>> true when building from the source archive when I make the official
>> >>> announcement.  Hopefully it wont take more than a week or two to get
>> >>> get
>> >>> documentation, libraries, and most of the packages ready.  Please let
>> >>> me
>> >>> know so I can plan the release announcement.  Thank you everyone for
>> >>> you
>> >>> efforts.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Wayne
>> >>>
>> >>> ___
>> >>> Mailing list: https://launchpad.net/~kicad-developers
>> >>> Post to : kicad-developers@lists.launchpad.net
>> >>> Unsubscribe : https://launchpad.net/~kicad-developers
>> >>> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >>
>> >> ___
>> >> Mailing list: https://launchpad.net/~kicad-developers
>> >> Post to : kicad-developers@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>
>

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

Re: [Kicad-developers] Release 4.0.5 tagged.

[Carl Poirier]

Hi Nick,

I do understand but it is not an issue, Just try it out, go to
https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty.

Carl

On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard  wrote:

> Hi Carl
>
> I have found an issue with the lib tagging. I think we decided to not
> remove any libs for the patch releaes. That is for releases where only
> the third number changes. What I see is:
>
> Buttons_Switches_ThroughHole.pretty remaned to Buttons_Switches_THT.pretty
> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
> Connect.pretty renamed to Connectors.pretty
> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty
> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty
> Display.pretty renamed to Displays.pretty
> Relays_ThroughHole.pretty renamed to Relays_THT.pretty
> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty
> Sockets_BNC.pretty removed?
> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pretty
>
> Won't users have to manually update their fp-lib-table?
>
> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty  .
> This looks correct, so that is ok.
>
> The fp-lib-table.for-pretty seems to match the repos tagged.
>
> Those renamed repos will easily summon errors in the users face. I
> hope you understand what I mean.
>
> 2016-12-03 22:54 GMT+01:00 Carl Poirier :
> > I will be tagging the libs in 24h.
> >
> > Carl
> >
> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf  >
> > wrote:
> >>
> >> I'll take a look early this week!
> >>
> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh 
> >> wrote:
> >>>
> >>> Better late than never.  I just pushed the 4.0.5 stable release.  Just
> a
> >>> note to the package devs, you no longer need to set the version string
> >>> at config.  You can use KICAD_VERSION_EXTRA to append any package
> >>> specific information to the "4.0.5" version string.  This will also
> hold
> >>> true when building from the source archive when I make the official
> >>> announcement.  Hopefully it wont take more than a week or two to get
> get
> >>> documentation, libraries, and most of the packages ready.  Please let
> me
> >>> know so I can plan the release announcement.  Thank you everyone for
> you
> >>> efforts.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Release 4.0.5 tagged.

[Nick Østergaard]

Hi Carl

I have found an issue with the lib tagging. I think we decided to not
remove any libs for the patch releaes. That is for releases where only
the third number changes. What I see is:

Buttons_Switches_ThroughHole.pretty remaned to Buttons_Switches_THT.pretty
Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
Connect.pretty renamed to Connectors.pretty
Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty
Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty
Display.pretty renamed to Displays.pretty
Relays_ThroughHole.pretty renamed to Relays_THT.pretty
Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty
Sockets_BNC.pretty removed?
Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pretty

Won't users have to manually update their fp-lib-table?

Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty  .
This looks correct, so that is ok.

The fp-lib-table.for-pretty seems to match the repos tagged.

Those renamed repos will easily summon errors in the users face. I
hope you understand what I mean.

2016-12-03 22:54 GMT+01:00 Carl Poirier :
> I will be tagging the libs in 24h.
>
> Carl
>
> On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf 
> wrote:
>>
>> I'll take a look early this week!
>>
>> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh 
>> wrote:
>>>
>>> Better late than never.  I just pushed the 4.0.5 stable release.  Just a
>>> note to the package devs, you no longer need to set the version string
>>> at config.  You can use KICAD_VERSION_EXTRA to append any package
>>> specific information to the "4.0.5" version string.  This will also hold
>>> true when building from the source archive when I make the official
>>> announcement.  Hopefully it wont take more than a week or two to get get
>>> documentation, libraries, and most of the packages ready.  Please let me
>>> know so I can plan the release announcement.  Thank you everyone for you
>>> efforts.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

[Kicad-developers] Anyone with a "Intel HD Graphics 520"?

[Mário Luzeiro]

Does anyone here has a "Intel HD Graphics 520" on Windows 7 64b (or maybe 
Windows 10)?

There is a bug report that it is crashing the 3D-Viewer just by resizing/maxime 
it:
https://bugs.launchpad.net/kicad/+bug/1627337

If so could you verify if 3Dviewer is working for you ? :)

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

Re: [Kicad-developers] Ideas for a lightweight KiCad PDM

[Kevin Bortis]

On Tue, Dec 6, 2016 at 4:39 PM, Clemens Koller  wrote:
> Hello, Kevin!
>
> I fully support your ideas. In a commercial environment, a proper PDM
including version management and documentation is mandatory to be able to
deliver a product where you can realize a traceability down to the date
code of a component once your design is manufactured.
>
> But since all projects / infrastructures / companies differ, it is
propably not a good idea to hard code some workflow into the design tool
(KiCad) and expect a one fits all approach.
>
> I have sort of a wishlist which would allow me to interface KiCad to my
existing infrastucture and solve some issues which cost me a lot of time:
> - The library as well as all design data should be accessible
(read-writeable) like a database (ideally: while KiCad is running).
> - Everything (even every single connection in the schematics) has a
version and a (modification) timestamp and is sortable by object,
properties, version and timestamp.
> - A copy (reuse) of fractions of a design should optionally include
it's objects properties, constraints, versions and history.
> - A diff and merge of parts or whole designs would improve versioning and
design-reuse a lot.
> * I would love to see forward/rewind buttons for libraries, schematics
and layout similar to browsing through the git history of a software
project 8-).
>
> For performance reasons I believe it is not a good idea to implement
design to library connectivity with links on a file-system level as it is
done by bothy commercial products quite a lot. (One horribly expensive
product seems to hold the whole design in an (optimized) database in memory
and is able to replicate the data in real-time in between several
workstations to feature "concurrent design entry" where several
people/autorouters are able to work on one design at the same time.)
>
> OT:
> I am working a lot with databases (SQL based) and several external tools
(self-written stuff + git) to manage my component library, the library
generators, as well as my local component information / stock data. I am
able to "link" a BOM written by the design tool with my component database
(+ local stock data) and then with the i.e. SAP data (+ remote stock data)
of my manufacturer to transfer my design to the assembly in an automated
way. We implemented something like a closed-loop-verification process where
I am able to read back the SAP data (maybe in the future through some
remote database interface) into my database to verify that the data will
arrive correctly at the machines. Sometimes, I'll need to update my local
data when the assembly needs a change somewhere. Since everything is a
moving target you want to freeze all the information for each manufacturing
lot / product version.
>
> These processes different a lot from one assembly house to the next one.
So, there is a cookbook of scripts tailored to each manufacturers process
with a lot of verification steps built in. There are usually no more .xls
files envolved in the whole process where busy people tend to add typos
manually without getting noticed.
>
> Regards,
>
> Clemens
>

Thanks for the feedback. I will include your  these in my collection of
things to consider.

>
> On 2016-12-06 08:22, Kevin Bortis wrote:
>> Hi
>>
>> I try to figure out how it would be possible to create a central
>> storage for symbols, footprints and other design data. With central I
>> mean something like a design data server, where it is possible to
>> assign workflows with sign-offs, make proper versioning, assign order
>> numbers and define second sources. (PDM ultra light for KiCad).
>>
>> I currently work on some projects where we need to be sure that each
>> change on current products gets a proper review and documentation.
>> This always starts with a "Change Request", followed by a "Change
>> Order". To make sure everything is right, we currently use a very
>> expensive EDA suite with even more expensive PDM[2] software. Even if
>> this seems overkill for private projects, a little more lighter
>> version of this workflow makes sens for every company and even for
>> some bigger private projects. I helps to grantees some quality and
>> data integrity.
>>
>> After some analysis how KiCad does things I see some little problems.
>> The first of them is described in the following lines:
>>
>> Currently the footprint and soon[1] symbols will be assigned with a
>> "library nickname"/"symbol name" key. This is also true for the 3D
>> model inside the  footprint file. At the moment this is the only
>> reference to the library. If the component in the local file storage
>> changes, the symbol/footprint gets changed immediately in the project
>> and that is exactly what I want to avoid. To make a server based
>> library, each symbol or footprint would need a unique identifier and
>> some way to define the storage location. Say instead of define
>> somelibrary/symbol1 (implicit local storage) define
>> 

Re: [Kicad-developers] Ideas for a lightweight KiCad PDM

[Kevin Bortis]

On Tue, Dec 6, 2016 at 4:56 PM, Wayne Stambaugh  wrote:
> On 12/6/2016 2:22 AM, Kevin Bortis wrote:
>> Hi
>>
>> I try to figure out how it would be possible to create a central
>> storage for symbols, footprints and other design data. With central I
>> mean something like a design data server, where it is possible to
>> assign workflows with sign-offs, make proper versioning, assign order
>> numbers and define second sources. (PDM ultra light for KiCad).
>>
>> I currently work on some projects where we need to be sure that each
>> change on current products gets a proper review and documentation.
>> This always starts with a "Change Request", followed by a "Change
>> Order". To make sure everything is right, we currently use a very
>> expensive EDA suite with even more expensive PDM[2] software. Even if
>> this seems overkill for private projects, a little more lighter
>> version of this workflow makes sens for every company and even for
>> some bigger private projects. I helps to grantees some quality and
>> data integrity.
>
> I'm fine with this but I will resist anything that imposes a work flow
> on users.  Features like this tend to be very personal so I would
> request that it be implemented as a plugin or a python script.  Python
> scripting would require the schematic code to be swigged.  It's on our
> list of things to do but it wont happen until after the new schematic
> and symbol library file formats are completed.
>

Almost all logic would be implemented on server side inclusive
workflow stuff. Even when the topic sounds complex, the client does
not need a lot to support proper integration in such a tool. The
"normal" workflow would not be touched in any case. Implemented as a
plugin or not I see only the following things that would change:

  1. Additional KiCad settings for activating and setting "network
sources" for design data (One or more)

The following points should only be accessible if the settings in 1.
are modified and at least one "network source" is activated.

  2. Additional menu to verify data integrity of local cached data
  3. Additional context menu items for different actions

As you see, a normal user would in any case not be affected.
Disclaimer: The following statements are made from someone that has
just started to analyse the KiCad file formats and design decisions.
At some points I could be totally wrong or write just nonsense.

This sounds promising. I think you refer to the SWEET data format. [4]
I saw some commits and mailing list entries from 2011. Are there any
newer specifications or discussions that I have overseen? The drawing
in [3] does suggest, that there is even planned to add some remote
http library stuff. When I read the SWEET spec, there is a NAME_HINT
parameter specified that can be in different formats depending on the
context from which the SWEET part came from. To be exact, the file
format for all parts stored in a schematic and layout file need the
following features:

  * Object-ID that is the same in schematic and layout file. This must
be different to the designator and unique. It helps to quickly find
the same part in schematic and layout and allows neat features like
simultaneous highlighting, back and fort annotation and other great
stuff. This could be used to get around file based net list generation
and import to.
  * Definition of the origin or "where is the original stored". It
will be used to check the remote location if the part has a new
version or if the local cached version is unmodified. (Just hash and
compare S-expression blocks?)

Based on [4], i would then ask for two additional and optional
parameters: "objectid" and "origin". The "objectid" would be assigned
on the fly for every part placed on a schematic sheet. It will stay
the same, even if a property like the designator changes. The
parameter gets passed to the layout the same way other properties get
passed through. It would change however if the part gets copied. The
"origin" parameter would then be something like:
remote1/16fd2706-8baf-433b-82eb-8c7fada847da . If not htere the part
is not considered as versioned. The same two parameters are needed not
only for parts, but for schematics, footprints to. These two
properties get assigned during placement and do not preexist in the
library.

I see only one single glitch where it gets a little weird. The file
format for the footprint as descibed in [5] does directly specfiy the
3D-model whithin the footprint module itself. For network based
libraries, the 3D-model would be saved as a separate model (same level
like schematic symbol, footprint or a datasheet) in the database. This
means that after the footprint is created and 3D-model is placed, the
user would then first commit the 3D-model get an ID back for it (if
not already there) and then store only the reference to this object
along the at, scale and rotate position. I have not found that the
"model" property allows parameters like

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hello,

I played around a bit and settled on a quick solution. For running 
the tests on windows binding to the shared libs is a problem with our 
default build, because we have separate output directories per target. 
Only after an install operation are they in one directory for proper 
library lookup. So I added an option to the kicad cmake script to output 
all targets to a single shared directory, this option is implicitly 
activated when unit tests are enabled on windows. It then also adds the 
boost.test dependency.
Everything else is just like I described in the last message: CTest can 
be used to run all the test executables, if you want boost.test 
verbosity, you can always run the tests from the command prompt.


Problem left would then be, how we set up the test targets. My initial 
thought would be to have one target per lib/executable. All tests 
related to the common library would then be combined to the 
"common-test" target for example.


Here's a screenshot for the targets, RUN_TESTS (CTest) output, 
boost.test output and the shared stage dir: 
https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png


Am I making any sense? I might not be aware of all the things you expect 
from this.


Michael


___
Mailing list: https://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] Ideas for a lightweight KiCad PDM

[Wayne Stambaugh]

On 12/6/2016 2:22 AM, Kevin Bortis wrote:
> Hi
> 
> I try to figure out how it would be possible to create a central
> storage for symbols, footprints and other design data. With central I
> mean something like a design data server, where it is possible to
> assign workflows with sign-offs, make proper versioning, assign order
> numbers and define second sources. (PDM ultra light for KiCad).
> 
> I currently work on some projects where we need to be sure that each
> change on current products gets a proper review and documentation.
> This always starts with a "Change Request", followed by a "Change
> Order". To make sure everything is right, we currently use a very
> expensive EDA suite with even more expensive PDM[2] software. Even if
> this seems overkill for private projects, a little more lighter
> version of this workflow makes sens for every company and even for
> some bigger private projects. I helps to grantees some quality and
> data integrity.

I'm fine with this but I will resist anything that imposes a work flow
on users.  Features like this tend to be very personal so I would
request that it be implemented as a plugin or a python script.  Python
scripting would require the schematic code to be swigged.  It's on our
list of things to do but it wont happen until after the new schematic
and symbol library file formats are completed.

> 
> After some analysis how KiCad does things I see some little problems.
> The first of them is described in the following lines:
> 
> Currently the footprint and soon[1] symbols will be assigned with a
> "library nickname"/"symbol name" key. This is also true for the 3D
> model inside the  footprint file. At the moment this is the only
> reference to the library. If the component in the local file storage
> changes, the symbol/footprint gets changed immediately in the project
> and that is exactly what I want to avoid. To make a server based
> library, each symbol or footprint would need a unique identifier and
> some way to define the storage location. Say instead of define
> somelibrary/symbol1 (implicit local storage) define
> srv://remote1/16fd2706-8baf-433b-82eb-8c7fada847da (explicit remote
> storage) where remote1 is a configured remote storage location in the
> app. The fully qualified address of the symbol would then be something
> like https://myserver.local/lib/uuid/16fd2706-8baf-433b-82eb-8c7fada847da
> 
> A second possibility would be to introduce a new file (symbol.origin)
> in the project folder to keep track of every remote stored file.
> 
> symbol.orign:
> somelibrary/symbol1=remote1/16fd2706-8baf-433b-82eb-8c7fada847da
> somelibrary/footprint2=remote1/23fd2706-3baf-223b-82eb-ef7fada847ac

This issue will be pretty much be solved when the new schematic file
format is introduced because symbols will be embedded in the schematic
(unless you specifically externally link them which will be an option at
some point) so they will not change when the library symbol changes.  Of
course this introduces a new problem where the user will have to update
the symbols manually at least initially.  At some point in the future we
will provide a feature for comparing symbols in the schematic against
the symbol linked to the library and inform the user of any changes.

> 
> After retrival from the central storage, I would save the symbol as
> libs/somelibrary/symbol1 locally in the project tree. This would have
> almost no impact on the KiCad code I think. A command can be
> implemented to verifiy data integrity by getting file hashes of each
> component from the central server and checking if everything is in
> sync. A second command to check if a newer version of the symbol is
> available with the option to update it. To make this work, KiCad would
> need to track the origin of every 3D model, symbol, footprint...
> 
> I would appreciate if some one has some input on this topic.
> 
>   [1] https://lists.launchpad.net/kicad-developers/msg26901.html
>   [2] https://en.wikipedia.org/wiki/Product_data_management
> 
> Regards
> Kevin
> 
> ___
> Mailing list: https://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] Ideas for a lightweight KiCad PDM

[Clemens Koller]

Hello, Kevin!

I fully support your ideas. In a commercial environment, a proper PDM including 
version management and documentation is mandatory to be able to deliver a 
product where you can realize a traceability down to the date code of a 
component once your design is manufactured.

But since all projects / infrastructures / companies differ, it is propably not 
a good idea to hard code some workflow into the design tool (KiCad) and expect 
a one fits all approach.

I have sort of a wishlist which would allow me to interface KiCad to my 
existing infrastucture and solve some issues which cost me a lot of time:
- The library as well as all design data should be accessible (read-writeable) 
like a database (ideally: while KiCad is running).
- Everything (even every single connection in the schematics) has a version and 
a (modification) timestamp and is sortable by object, properties, version and 
timestamp.
- A copy (reuse) of fractions of a design should optionally include it's 
objects properties, constraints, versions and history.
- A diff and merge of parts or whole designs would improve versioning and 
design-reuse a lot.
* I would love to see forward/rewind buttons for libraries, schematics and 
layout similar to browsing through the git history of a software project 8-).

For performance reasons I believe it is not a good idea to implement design to 
library connectivity with links on a file-system level as it is done by bothy 
commercial products quite a lot. (One horribly expensive product seems to hold 
the whole design in an (optimized) database in memory and is able to replicate 
the data in real-time in between several workstations to feature "concurrent 
design entry" where several people/autorouters are able to work on one design 
at the same time.)

OT:
I am working a lot with databases (SQL based) and several external tools 
(self-written stuff + git) to manage my component library, the library 
generators, as well as my local component information / stock data. I am able 
to "link" a BOM written by the design tool with my component database (+ local 
stock data) and then with the i.e. SAP data (+ remote stock data) of my 
manufacturer to transfer my design to the assembly in an automated way. We 
implemented something like a closed-loop-verification process where I am able 
to read back the SAP data (maybe in the future through some remote database 
interface) into my database to verify that the data will arrive correctly at 
the machines. Sometimes, I'll need to update my local data when the assembly 
needs a change somewhere. Since everything is a moving target you want to 
freeze all the information for each manufacturing lot / product version.

These processes different a lot from one assembly house to the next one. So, 
there is a cookbook of scripts tailored to each manufacturers process with a 
lot of verification steps built in. There are usually no more .xls files 
envolved in the whole process where busy people tend to add typos manually 
without getting noticed.

Regards,

Clemens


On 2016-12-06 08:22, Kevin Bortis wrote:
> Hi
> 
> I try to figure out how it would be possible to create a central
> storage for symbols, footprints and other design data. With central I
> mean something like a design data server, where it is possible to
> assign workflows with sign-offs, make proper versioning, assign order
> numbers and define second sources. (PDM ultra light for KiCad).
> 
> I currently work on some projects where we need to be sure that each
> change on current products gets a proper review and documentation.
> This always starts with a "Change Request", followed by a "Change
> Order". To make sure everything is right, we currently use a very
> expensive EDA suite with even more expensive PDM[2] software. Even if
> this seems overkill for private projects, a little more lighter
> version of this workflow makes sens for every company and even for
> some bigger private projects. I helps to grantees some quality and
> data integrity.
> 
> After some analysis how KiCad does things I see some little problems.
> The first of them is described in the following lines:
> 
> Currently the footprint and soon[1] symbols will be assigned with a
> "library nickname"/"symbol name" key. This is also true for the 3D
> model inside the  footprint file. At the moment this is the only
> reference to the library. If the component in the local file storage
> changes, the symbol/footprint gets changed immediately in the project
> and that is exactly what I want to avoid. To make a server based
> library, each symbol or footprint would need a unique identifier and
> some way to define the storage location. Say instead of define
> somelibrary/symbol1 (implicit local storage) define
> srv://remote1/16fd2706-8baf-433b-82eb-8c7fada847da (explicit remote
> storage) where remote1 is a configured remote storage location in the
> app. The fully qualified address of the symbol would then be something
> 

Re: [Kicad-developers] Symbol library editor UI refactor

[Maciej Sumiński]

On 12/06/2016 09:10 AM, Maciej Sumiński wrote:
> Hi Nick,
> 
> On 12/05/2016 11:46 PM, Nick Østergaard wrote:
[snip]
>> But I wonder if the filter should be able to also consider the library
>> name. Currently it seems to only consider the parts. For example if I
>> write the exact name for my library it will not show up in the tree
>> view. It is quite usefull that you can position the tree view
>> whereever you want. Just an idea, would it make sense that it can be
>> closed, sort of like with the layer manager in pcbnew.
> 
> Two good points, thank you. I think the tree widget should visibility
> should be toggled and surely it should display matching libraries as well.

Both issues should be fixed now.

Regards,
Orson




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] Github plugin not built in Ubuntu PPA

[Carl Poirier]

Hi Orson,

Yes I am talking about the 4.0 branch. Thanks for the explanation.

Carl

On Tue, Dec 6, 2016 at 3:36 AM, Maciej Sumiński 
wrote:

> Hi Carl,
>
> Do you mean PPA for the 4.0 branch? Recently I had troubles building the
> 4.0 branch with Github plugin enabled on Arch as well.
>
> Seemingly the problem is disabled SSLv3 support in Arch's OpenSSL
> package, which might be the case in Ubuntu as well. SSLv3 is used by
> avhttp to connect to Github. In the master branch, avhttp is already
> replaced with curl, which works fine.
>
> The 4.0 branch becomes tough to maintain, I do not know if backporting
> the curl patch is a simple task now.
>
> Regards,
> Orson
>
> On 12/06/2016 03:35 AM, Carl Poirier wrote:
> > Hi folks,
> >
> > I just noticed the Github plugin isn't built in the Ubuntu PPA. Why is
> > that? This is confusing, you can select "Github" as plugin type in the
> > fp-lib-table, but once you ask to browse the libs, an error pops out. I
> had
> > never noticed before because I was compiling from source, but anyway this
> > is definitely something that has to be enabled!
> >
> > Carl
> >
> >
> >
> > ___
> > Mailing list: https://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] Github plugin not built in Ubuntu PPA

[Maciej Sumiński]

Hi Carl,

Do you mean PPA for the 4.0 branch? Recently I had troubles building the
4.0 branch with Github plugin enabled on Arch as well.

Seemingly the problem is disabled SSLv3 support in Arch's OpenSSL
package, which might be the case in Ubuntu as well. SSLv3 is used by
avhttp to connect to Github. In the master branch, avhttp is already
replaced with curl, which works fine.

The 4.0 branch becomes tough to maintain, I do not know if backporting
the curl patch is a simple task now.

Regards,
Orson

On 12/06/2016 03:35 AM, Carl Poirier wrote:
> Hi folks,
> 
> I just noticed the Github plugin isn't built in the Ubuntu PPA. Why is
> that? This is confusing, you can select "Github" as plugin type in the
> fp-lib-table, but once you ask to browse the libs, an error pops out. I had
> never noticed before because I was compiling from source, but anyway this
> is definitely something that has to be enabled!
> 
> Carl
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] Symbol library editor UI refactor

[Maciej Sumiński]

Hi Nick,

On 12/05/2016 11:46 PM, Nick Østergaard wrote:
> Hi Maciej,
> 
> It looks quite good. It looks way more user friendly and the fact that
> it updates instantly. I have not tested how it behaves if there are
> parts with the same name.

Currently the old rules apply, so if you have two components with the
same in different libraries, the library that is higher on the list
takes precedence. The editor should not let you create two components
with the same name within a single library.

> But I noticed that the toolbar form the left just seems to have been
> moved on the right and filling 50%, I guess that is just an
> intermediate commit.

Actually, I have not noticed that previously, so this might have been
modified by Michelle who has taken part in the development process. The
purpose of this call for testing is to discuss whether we want such
changes or not.
Personally, I prefer the current layout, but I realize it might not look
fine on smaller displays, so I am not going to be stubborn here.

> But I wonder if the filter should be able to also consider the library
> name. Currently it seems to only consider the parts. For example if I
> write the exact name for my library it will not show up in the tree
> view. It is quite usefull that you can position the tree view
> whereever you want. Just an idea, would it make sense that it can be
> closed, sort of like with the layer manager in pcbnew.

Two good points, thank you. I think the tree widget should visibility
should be toggled and surely it should display matching libraries as well.

Regards,
Orson

> Nick
> 
> 2016-12-05 17:52 GMT+01:00 Maciej Sumiński :
>> Since some time we have been working on eeschema library editor with the
>> goal of simplifying the user interface. Now it is available for
>> beta testing [1] and I would appreciate some feedback.
>>
>> Changes:
>> - symbol tree widget (thanks to Michele Castellana)
>> - opening multiple components at the same time
>> - creating a new library adds it to the project libraries
>> - cut/copy/paste symbols between libraries
>> - most of the actions are available in the top menu now
>>
>> I have modified a few icons too (import/export/save part), though they
>> need pixel-accurate scaling to look fine, so for now they are just an
>> idea to be discussed.
>>
>> I invite you to build the code and take it for a test drive, but if all
>> you want is a quick overview of the changes, then there is a short
>> screencast too [2].
>>
>> Regards,
>> Orson
>>
>> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/libedit
>> 2. https://vimeo.com/194371466
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>




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

Re: [Kicad-developers] Symbol library editor UI refactor

[Simon Richter]

Hi,

On 06.12.2016 09:03, Maciej Sumiński wrote:

> Thank you Simon! Does it mean you have Windows binaries available for
> testing?

Yes:

http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-396-54c5f6b-x86_64.exe

   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] Symbol library editor UI refactor

[Maciej Sumiński]

Thank you Simon! Does it mean you have Windows binaries available for
testing?

Regards,
Orson

On 12/05/2016 11:33 PM, Simon Richter wrote:
> Hi,
> 
> On 05.12.2016 17:52, Maciej Sumiński wrote:
> 
>> Since some time we have been working on eeschema library editor with the
>> goal of simplifying the user interface. Now it is available for
>> beta testing [1] and I would appreciate some feedback.
> 
> Building for Windows at
> 
> http://ci.kicad-pcb.org/job/windows-kicad-msys2-patch/396/
> 
>Simon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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