Back To Work

After a long winter break, work on the Penguin Electronics Inventory is finally resuming. We should be finishing the server-side protocol implementations soon, which will allow much faster progress to be made on the clients. Also, this semester I will be demonstrating Penguin's versatility by adapting it to manage physical music inventory (records, CDs, tapes, etc.). This is, of course, in addition to me continuing work on the web client, such completing basic functionality (displaying selections, adding/editing items and their parameters, etc.).

Look for updates soon!

Zach

Web Client Progess

The web client is now almost caught up with the capabilities of the PC client. It can display a collapsible list of Categories and then pass the data for whichever one is clicked on to main window (currently just the name is displayed, no UI).

Next to be implemented will be the UI for editing of Categories and adding of Manufacturers and Vendors. These have been chosen because they have already been implemented on the server. After that, more complete adding/editing/deleting Categories, Manufactures, Suppliers, etc. will be implemented on the web client and server as well as continuing development of the overall UI of the web client.

Parts of this project (i.e. the web client) are being developed within the Rensselaer Center for Open Source Software (RCOS).

The code and wiki for this project can be found at https://code.google.com/p/penguin-electronics-inventory/

We look forward to sharing our development of this project,

Zach

Introduction

History

This project was born (like many other open source projects) out of one person's frustration. After ten years of tinkering with electronics I simply had too many components, gadgets, and tools to keep track of. When designing a project, however, I needed to know what I had in stock to avoid duplicate purchases.

My first attempt at inventory management was a complete failure. It was a PHP+MySQL GUI that had two tables - one for tools and one for parts. There was no parametric search; components simply had a string description like "Resistor - 100 ohm - 0603 - 5%". There were no connections between the same part in different packages - the same microcontroller in breadboardable DIP package or a tiny SSOP package would be considered completely different.

After spending a while tossing ideas around I came up with a new schema and refined it with the help of some of the regulars in ##electronics on Freenode (one of whom has expressed interest in contributing to the project).

The new architecture is a client-server model which will allow any number of front-ends to be developed for the same database. We are currently doing an HTML+AJAX client and a gtkmm-based PC application and plan to explore mobile apps in the future.

Data model

The core concept in Penguin is that of a device. This is associated with a set of properties such as "maximum working voltage", "clock speed", "memory size", etc. A device represents the internals of a component without relation to the packaging.

A device is then associated with a package type to become a physical device. To give a concrete example, "ATmega328" is a device and "ATmega328 in 28-pin DIP" is a physical device. The user of the system can track how many of each physical device they have in stock, as well as optionally storing a "minimum stock amount" for popular parts. When the actual count is less than the minimum the user will be prompted to purchase more.

A physical device may be purchased from one or more distributors. A (physical device, distributor) tuple, plus some other metadata such as the distributor's internal part number, is referred to as a distributor device and may be associated with one or more price quotes, each for a specific volume. Prices change over time so we intend to implement an interface to update quotes via a web-service interface (if provided by the vendor) or scraping of the HTML (if left with no choice)

Devices are described by datasheets. One device may refer to several datasheets (complex CPUs often have dozens of PDF's in their developer manuals) and several devices may refer to the same datasheet (memory devices in the same family with different capacity, for example).

Once the user has designed their project they may create a bill of materials, which specifies how many of each physical device is required to build their project. We intend to include cost-minimization code which, given shipping prices from each distributor, will determine the least expensive way to purchase a given number of copies of that BOM - in other words, how many of what to buy from which distributor. The optimizer may be instructed to not buy extras of parts that are already in stock (though if not enough are available, or the order would deplete stock below the minimum, the necessary number of units will be added to the generated orders).