There was a recent discussion about putting things on the schematic so they get exported in the BOM but don't get placed on the PCB. A related problem is multi-part components. For example, a jack plug for a header might consist of a receptacle and a number of crimp terminals snapped off from a strip, the receptacle and the strip each having their own part number and ordering information.

Has anyone come up with a slick way to generate multiple parts in the BOM file for a single component on the schematic?

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/\

You give each part a unique ident, then you can export the BOM and feed
the result into an external stock control / parts database system. In
that you can associate the part with whatever source you are using. So if
you have 50 pins that come off a strip, your external system will add up
all the pins of that type, and total up the number of pin strips needed.

It really is far too much hard work to try to get the Kicad BOM to do
things like this, it's simply the wrong tool.

IIRC there was a posting many months ago regarding a shareware stock /
parts system that provided quite a lot of functions and was easy to use.

Maybe someone can remember the name.


Andy




On Mon, 02 Jul 2012 17:41:11 +0100
Robert <birmingham_spider@...> wrote:

There was a recent discussion about putting things on the schematic so
they get exported in the BOM but don't get placed on the PCB. A
related problem is multi-part components. For example, a jack plug for
a header might consist of a receptacle and a number of crimp terminals
snapped off from a strip, the receptacle and the strip each having their
own part number and ordering information.

Has anyone come up with a slick way to generate multiple parts in the
BOM file for a single component on the schematic?

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;


------------------------------------

Please read the Kicad FAQ in the group files section before posting your question.
Please post your bug reports here. They will be picked up by the creator of Kicad.
Please visit for details of how to contribute your symbols/modules to the kicad library.
For building Kicad from source and other development questions visit the kicad-devel group at ! Groups Links

IIRC there was a posting many months ago regarding a shareware stock /
parts system that provided quite a lot of functions and was easy to use.

Maybe someone can remember the name.

Funny you should mention that. I've been working on my own open-source database for kicad (files in the kicad user group, update following soon), and that's what got me thinking about this. I think you have the answer though. I just export the receptacle in the BOM and the database adds the correct crimp terminal strip to the parts list.

Thanks,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;

The database I'm working on uses Firebird as the back end, which is FOS. For the front end I'm using MS Access, but only because Libre/OpenOffice has a known show-stopper of a bug. The front-end database has a few macros, queries and reports that allow it to produce a formatted parts list. It also ensures that the parts list is frozen in a project database, so changes to the the data in the back-end don't get *silently* transferred to the parts list.

Creating the database has certainly proved to be a lot of work, so I have no plans to replace the front end with an application. I could probably do it fairly quickly with MFC/DAO, but that would be Win only. It really needs to be done by someone with serious cross-platform programming experience. I have provided some code to show how to talk to the back-end database using ODBC.

Whilst the parts list generator would be independent of the existing kicad software, my thinking is that EESchema could be linked with the database engine via ODBC, eliminating the need for BOM export and providing a means of selecting components from the database into EESchema, but again I leave that to someone else.

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;

Parts and Vendors... that's the one I was thinking of, my mistake I
thought it was a shareware prog.


Andy




On Mon, 2 Jul 2012 11:14:09 -0700 (PDT)
Jeff Kaskey <jkaskey@...> wrote:

FWIW, that's the way I do it. I am using Parts&Vendors (neither open source nor free, and win-only, but reasonably inexpensive) and I dump my KiCad BOM into it and output my purchase lists, kits, etc. Let each tool do what it does best, do not expect KiCad to become an MRP system.

Would love to see an open-source P&V-type database tool, but it is no small amount of work. Besides the database design itself, the UI is important in making the tool usable at all. You deal with a lot of parts in a BOM, you need a UI that lets you do things quickly.

-j


________________________________
From: Robert <birmingham_spider@...>
To: kicad-users@...
Sent: Monday, July 2, 2012 10:04 AM
Subject: Re: [kicad-users] Multi-Part Components


?

IIRC there was a posting many months ago regarding a shareware stock /
parts system that provided quite a lot of functions and was easy to use.

Maybe someone can remember the name.

Funny you should mention that. I've been working on my own open-source
database for kicad (files in the kicad user group, update following
soon), and that's what got me thinking about this. I think you have
the answer though. I just export the receptacle in the BOM and the
database adds the correct crimp terminal strip to the parts list.

Thanks,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;

On 02-07-12 21:09, Robert wrote:

The database I'm working on uses Firebird as the back end, which is FOS.
For the front end I'm using MS Access, but only because
Libre/OpenOffice has a known show-stopper of a bug. The front-end
database has a few macros, queries and reports that allow it to produce
a formatted parts list. It also ensures that the parts list is frozen
in a project database, so changes to the the data in the back-end don't
get *silently* transferred to the parts list.

Creating the database has certainly proved to be a lot of work, so I
have no plans to replace the front end with an application. I could
probably do it fairly quickly with MFC/DAO, but that would be Win only.
It really needs to be done by someone with serious cross-platform
programming experience. I have provided some code to show how to talk
to the back-end database using ODBC.

Whilst the parts list generator would be independent of the existing
kicad software, my thinking is that EESchema could be linked with the
database engine via ODBC, eliminating the need for BOM export and
providing a means of selecting components from the database into
EESchema, but again I leave that to someone else.

Regards,

Robert.

Hi Robert,

To make you application you could use Lazarus. That's a "write once, compile everywere" RAD environment. It's more or less a clone of Delphi, but very cross-platform. It has native drivers to access Firebird (and other DB's) so ODBC is not needed, since ODBC is mostly Windows.
Just my 2 cents.

Regards,

Koenraad.

To make you application you could use Lazarus. That's a "write once,
compile everywere" RAD environment. It's more or less a clone of Delphi,
but very cross-platform. It has native drivers to access Firebird (and
other DB's) so ODBC is not needed, since ODBC is mostly Windows.
Just my 2 cents.

Thanks, that's certainly worth knowing should I suddenly find myself with the time to write the front end app :). Is the Lazarus driver a proper client-server interface, that would allow the front end to talk to a Firebird server on a remote machine? Firebird can be run "embedded" using a driver, but that would limit kicad to being used by only one engineer at a location, acting as a barrier to it being used professionally.

I did look into ODBC and although originally a Microsoft technology it is supported by Linux. The Firebird ODBC driver for Linux is here:



I've not checked to see if there are any snags, but the Firebird community is very active and I'm sure they would not tolerate something buggy.

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;

On 03-07-12 09:57, Robert wrote:

Thanks, that's certainly worth knowing should I suddenly find myself
with the time to write the front end app :). Is the Lazarus driver a
proper client-server interface, that would allow the front end to talk
to a Firebird server on a remote machine? Firebird can be run
"embedded" using a driver, but that would limit kicad to being used by
only one engineer at a location, acting as a barrier to it being used
professionally.

Yes, they are full client-server "drivers". Actually they are an interface to the installed db-drivers. There is no odbc-layer.

I've not checked to see if there are any snags, but the Firebird
community is very active and I'm sure they would not tolerate something
buggy.

Firebird is my favorite database server ;-) .

Regards,

Koenraad Lelong

On 03/07/2012 15:07, Koenraad Lelong wrote:

On 03-07-12 09:57, Robert wrote:

Thanks, that's certainly worth knowing should I suddenly find myself
with the time to write the front end app :). Is the Lazarus driver a
proper client-server interface, that would allow the front end to talk
to a Firebird server on a remote machine? Firebird can be run
"embedded" using a driver, but that would limit kicad to being used by
only one engineer at a location, acting as a barrier to it being used
professionally.

Yes, they are full client-server "drivers". Actually they are an
interface to the installed db-drivers. There is no odbc-layer.

Thanks, that is well worth knowing.

There is one sort-of advantage to ODBC which I have exploited in the past. I have written an app that used Firebird with ODBC, expecting the response "yes, that's very nice but I want to use MySQL/SQL Server, not Firebird even if it is better". I did indeed get that response, and I was able to say that my app would also work with MySQL and Postgres, but I had had to give up on SQL Server because the installer ran out of disk space after about forty minutes of installing all the dark matter in the universe. Using ODBC in this way does require code that adapts to the SQL dialect, and IIRC the sample ODBC code I included with my database includes the self-adapting code.

But if someone wrote the code using the Lazarus drivers I wouldn't object.

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;

开云体育

?

> To make you application you could use Lazarus. That's a "write once,
> compile everywere" RAD environment. It's more or less a clone of Delphi,
> but very cross-platform. It has native drivers to access Firebird (and
> other DB's) so ODBC is not needed, since ODBC is mostly Windows.
> Just my 2 cents.

No sure what this discussion has to do with Multi-Part Components!?
(see previous discussion wrt BOM management)

How about accessing an existing database?
I would recommend checking out:
where either a manual or API search of the site is provided. Part
searches provide description, pdf spec, multi-distributor, cost, inventory,etc
-Frank

Thanks, that's certainly worth knowing should I suddenly find myself
with the time to write the front end app :). Is the Lazarus driver a
proper client-server interface, that would allow the front end to talk
to a Firebird server on a remote machine? Firebird can be run
"embedded" using a driver, but that would limit kicad to being used by
only one engineer at a location, acting as a barrier to it being used
professionally.

I did look into ODBC and although originally a Microsoft technology it
is supported by Linux. The Firebird ODBC driver for Linux is here:



I've not checked to see if there are any snags, but the Firebird
community is very active and I'm sure they would not tolerate something
buggy.

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/\

开云体育

I think it's more the case that (understandably) many kicad users have no
experience of large and complex products and the construction and
production of such things. The PCB is just a small part of the whole.

Before the days of databases and CAD type programs, you would have a
drawing set, which would show the PCB layout, components and so on. You
would also have an assembly drawing that would show the PCB in outline
form, and specify all the mounting hardware, AND the assembly order.
It was very common to have a dozen or more assembly drawings in order to
build up a product. I can still vividly remember the smell of freshly
printed dyeline drawings - ammonia was used in the developing process
and the paper held that smell for days :-)


M6 Pan head bolt, Crinkle Washer, plain washer, PCB, plain washer,
spacer, mounting plate, start washer, nut - then a note to specify
locking compound, torque and so on as needed.

Long winded to type, but it's just a slightly exploded item on a
drawing. You got used to reading them.

Loads of ancillary drawings detailing things like cable form assembly,
front panel layout and engraving, etc. etc.

Then there is the part list, EVERY item is identified and listed.
The drawing does not list things as M4 bolt, but by part number.
That is then cross references with the parts list which can be
dozens of pages long.

Walk into the purchasing department and there would the stock cards
that detailed what every part was, where it was to be purchased
from, alternate sources and so on.

Everything is a lot easier now with databases and PC's doing a lot
of the grunt work, especially keeping track of inventory, but the
process is basically the same.

While it is nice to have extra features there is a danger as you
say that it could grow like topsy and quickly get out of hand.

All you actually need is a list of part numbers used. Now that
could be formatted as part number + quantity or it could be as
simple as the part number only repeated as many times as that
part is used. It's no big deal for a database to count up the
duplicated part numbers to get a total.

One of the paradigms of linux is that a tool should do one job well, not
a bad way to do things. So far Kicad tends to follow that method. I hope
it continues to do so.


Andy






On Wed, 4 Jul 2012 22:56:37 +0100
"JorgeF_Tech" <jorgef.tech@...> wrote:

Hi



I second Andy position.



Kicad is a PCB design tool, not a full project manager and doesn't seem to
be intended to replace the whole project team.

If we start enlarging the scope of the tool, one of this days someone will
be asking for a full library of nuts, bolts, washers, enclosures, power
cords,... and whatever else we need to put a finished product on the
shelves.



This kind of complex components, as the connectors made of separate pins and
plastic frame, are normally addressed by some kind of database tool that has
records with the composition details for a specific internal product code,
alongside with approved vendors, costs and so on.



Its like when you take your car/dishwasher/. to be serviced. They only fill
the replaced/tuned parts and man work hours get added by the system.



Just my 2 cents.





Best regards

Jorge















De: kicad-users@... [mailto:kicad-users@...] Em nome
de Andy Eskelson
Enviada: segunda-feira, 2 de Julho de 2012 17:57
Para: kicad-users@...
Assunto: Re: [kicad-users] Multi-Part Components





You give each part a unique ident, then you can export the BOM and feed
the result into an external stock control / parts database system. In
that you can associate the part with whatever source you are using. So if
you have 50 pins that come off a strip, your external system will add up
all the pins of that type, and total up the number of pin strips needed.

It really is far too much hard work to try to get the Kicad BOM to do
things like this, it's simply the wrong tool.

IIRC there was a posting many months ago regarding a shareware stock /
parts system that provided quite a lot of functions and was easy to use.

Maybe someone can remember the name.

Andy

On Mon, 02 Jul 2012 17:41:11 +0100
Robert <birmingham_spider@... <mailto:birmingham_spider%40gmx.net> >
wrote:

There was a recent discussion about putting things on the schematic so
they get exported in the BOM but don't get placed on the PCB. A
related problem is multi-part components. For example, a jack plug for
a header might consist of a receptacle and a number of crimp terminals
snapped off from a strip, the receptacle and the strip each having their
own part number and ordering information.

Has anyone come up with a slick way to generate multiple parts in the
BOM file for a single component on the schematic?

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;


------------------------------------

Please read the Kicad FAQ in the group files section before posting your

question.

Please post your bug reports here. They will be picked up by the creator

of Kicad.

Please visit for details of how to contribute your

symbols/modules to the kicad library.

For building Kicad from source and other development questions visit the

kicad-devel group at ! Groups
Links

I've already modified the database I'm working on to deal with multi-part components following Andy's post. When it receives a "parent" component in the BOM, it adds the correct number of "child" components. At the moment it doesn't know about components that come in strips (or bags, for that matter) of 100 (I can't do everything at once), so it just says a single two slot receptacle needs two crimp terminals and adds a quantity of two and the strip part number to the parts list. That's clearly not as it should be, but it sure beats tracking down the correct crimp terminals on the supplier's website every time one selects a receptacle.

The database is not conceived of as part of EESchema, so I'm not sure where that came from. It's an independent system that *could* be hooked into kicad via a standard interface (eg ODBC). In the inward direction EESchema could have a dialog that generates SQL to search the database and (once the component has been selected) fill in the EESchema fields as required. The BOM would go in the outward direction. This isn't essential, it's just some niceties that someone could add if they want to. Those functions are currently achieved using a standalone UI (FlameRobin, Access, or any other SQL tool). The creation of a nicely formatted parts list is performed by a standalone application (currently Access) that also talks to the database server (using ODBC); I'm not suggesting that gets integrated into EESchema.

Regards,

Robert.

--
() Plain text email - safe, readable, inclusive.
/&#92;