X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=uTVJLE47Hjk2PKdto3b2/chvz4elFtHHiNr1+k0Ihyk=;
	b=S/lyefLMg7wyiSRSsNzEpTbExBYtT6HnMevDHypMYWqDY4dbMMY1awinFwMHoEDzKj
	55frv4E0L6ygNfa8mnux+B5VjY7hFkhNJZ0+33AcBltLG9v+b9Xeemlf6S9szfRktoe0
	1+QzoZdxLqagvhglAjYMGS8ckz8LKxQfscAjFXnPGSCQOWZyynzb6YIZnfZX9X0+BTxM
	aRJe77x/Hg6OsAEOaFO9XZyRjMcJthfe7NqGShQ84Gs5kZdWKYJMjAwhfouCgbRvPY6z
	6iVP9CLE24OAAYeX3KVxuox77WP4/yIDlnnkBSI1mb8FQEUhSAF2pblVjyRLn5e4L1pm
	1qrg==
MIME-Version:	1.0
X-Received:	by 10.140.106.101 with SMTP id d92mr13701319qgf.70.1430524958861;
	Fri, 01 May 2015 17:02:38 -0700 (PDT)
Date:	Sat, 2 May 2015 05:32:38 +0530
Message-ID:	<CALT8Ef51_5-G-w6W1_1q7-XaOQU0UV1wFME9--xwVx=H3bBUjA@mail.gmail.com>
Subject:	[geda-user] Automation of non-EDA processes around gEDA
From:	Shashank Chintalagiri <shashank DOT chintalagiri AT gmail DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com

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

- Raw text -