MIME-Version: 1.0
In-Reply-To: <CALT8Ef51_5-G-w6W1_1q7-XaOQU0UV1wFME9--xwVx=H3bBUjA@mail.gmail.com>
References: <CALT8Ef51_5-G-w6W1_1q7-XaOQU0UV1wFME9--xwVx=H3bBUjA AT mail DOT gmail DOT com>
Date: Fri, 1 May 2015 21:48:21 -0400
Message-ID: <CAOFvGD5grmj5Hy415HWisHKa2YKuF04Vf=JdUado48qMnzwMow@mail.gmail.com>
Subject: Re: [geda-user] Automation of non-EDA processes around gEDA
From: Jason White <whitewaterssoftwareinfo AT gmail DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

That is interesting,

Item number 5 on the list (automaticly generate gerbers, schematic,
bom configurations, and documentation) is of most interest to me. All
of the component sourcing features, while necessary in every design,
are a much more complicated to use.

I look forward to seeing what some of your scripts can do.

On Fri, May 1, 2015 at 8:02 PM, Shashank Chintalagiri
<shashank DOT chintalagiri AT gmail DOT com> wrote:
> Hello,
>
> I'm working on a tool (presently called Koala) which I'm hoping to use
> to streamline the various non-EDA processes involved with maintaining
> gEDA projects, helping with manufacturing, planning, etc. It's
> presently just reaching some form of critical mass where I'm fairly
> confident it'll serve the purposes I had in mind for it originally.
> It's essentially in the form of a rickety collection of python
> scripts. At best, some of these are at alpha quality. At worst, some
> elements are downright ugly hacks.
>
> At this point in the development, I'd like to gauge the interest in
> the community for having such a tool available. Releasing the code
> will mean having to scrub all company specific information from the
> core, and have ways to inject that information separately on a
> per-instance basis. It'll also mean having to revisit the many
> instances where I've had to diverge from gEDA standards and norms.
> While I will probably have some convincing to do to develop a revenue
> model to justify the time and effort of maintaining a 'public' version
> at my workplace, I think I may be able to eventually release a
> significant portion of the core functionality with a GPL/AGPL or
> similar license - if there is enough interest in using it within the
> community. I would also like to hear about the approaches typically
> used by people to deal with the annoyances I'm trying to rid myself
> of. Much thanks for your time.
>
> The following is the broad outline of the functionality and approach I
> was looking to implement when I started working on Koala :
>
>  * The Fundamental Information sources are various gEDA (and
> eventually other, such as FreeCAD) projects. As far as possible, the
> source files should follow the formats and norms we were using before,
> i.e., standard gEDA files. Additional functionality is introduced by
> an external scaffold erected around the standard projects. The gEDA
> binaries are untouched.
>
>  * The information content of the gEDA schematics I was using
> previously was insufficient. The closest analogue to the dilemma and
> the solution that I found to be the subjectively 'cleanest' way is a
> wild tangent to the standard heavy-vs-light standards argument.
>
>  * I work at a company where we build instrumentation in low volume.
> BOMs are constantly in flux, even when the base PCB doesn't change.
> Additionally, we have a few PCBs which can be populated in a wide
> variety of ways by a combination of DNP/DNI and component value
> changes. Manually maintaining these BOMs off-schematic was getting too
> cumbersome.
>
>  * The idea is to encode as much of this information within the
> schematic as possible, and use this new tool to generate a variety of
> BOMs from a single gEDA project. This has been done by adding extra
> attributes to affected components in the gschem files.
>
>  * The low volume production we do also means that our input costs can
> be significantly affected by optimising upstream orders and exploting
> cross-PCB and even cross-Product Line overlaps in BOMs to increase our
> order quantities and reduce order cost. A way to collate various BOMs
> together was necessary.
>
>  * Much of this work was and is still done by hand - by myself and
> other people at my company - resulting in significant wastage of
> skilled resources and delays in procurement and production.
>
>  * Koala was supposed to collapse the many steps requiring human
> intervention in the (Schematic Capture -> BOM -> Order Planning ->
> Order Execution -> Production Control -> Product Pricing) chain into
> the following main steps :
>        - Encoding relevant information directly into gschem files
>        - Adding a human editable config file alongside the gEDA
> project file which contains the appropriate rules for transforming the
> BOM (and hopefully schematic, eventually) as per the requirements.
>
> * Executing the scripts koala provides are used to produce one or more
> of the following sets of information or documentation :
>      1. Cost of the PCB, fully soldered, for each configuration at a
> specified volume.
>      2. Shortages in Inventory that need to be fulfilled to complete a
> specified production cycle.
>      3. Select sources for each of the components necessary and
> minimize order cost (at present supporting only the vendors we use
> most commonly, possibly only Digikey being relevant to anyone on this
> list)
>      4. Estimate financial outlay for a specified production cycle.
>      5. Generate various documentation, including schematic PDFs,
> reference BOMs per configuration, Assembly Manifests, Purchase Orders,
> Gerber Zips, etc.
>
> * The cost of using Koala, though, is that the rules for supported
> schematic become much more rigid than gEDA standards. These
> restrictive naming conventions can be irritating and time consuming to
> move to. In essence, I would imagine every Koala implementation could
> eventually have it's own naming conventions. Additional features need
> extra attributes to be added to gEDA schematics. I've never gotten the
> hang of hierarchial schematics, so those aren't in any way supported.
> (Perhaps they provide this sort of functionality by themselves?).
> SPICE and friends won't like the way names are transformed, and so at
> present will not work. Eventually an exporter for SPICE-friendly
> schematics could be implemented in principle.
>
>
>
>
> --
>
> Chintalagiri Shashank


-- 
Jason White