FreeBOMBS

From DIY contraptions to sophisticated FreeEMS-specific designs! Plus general hardware development!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeBOMBS

Post by Fred »

If the parts are well chosen, then the prices will serve as a rough guide, which is all they were intended to be. Exchange rates fluctuate too, but IMO it's perfectly fine to put them on disk and use them as a guide.

The process is likely to be something like:

1) go through and choose stuff
2) get output BOM
3) upload to supplier
4) look at availability and price
5.1) correct details by hand and order
OR
5.2) fix up source data and run through process again

However, if the API is clean and useful, such a thing would be great! :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Jammi
DIP8 - Involved
Posts: 24
Joined: Mon May 02, 2011 5:07 am

Re: FreeBOMBS

Post by Jammi »

nitrousnrg wrote:Now I see the flaw. It took me a while to realize it doesn't communicate with any internet service, I got kind of upset when I wasn't able to find the segment of code that does something like an http request.
It's an isolated database for a good reason: flexibility. Electronic components are just one mode of operation. An external script to update the components is fine and yaml is an easy format to parse and generate both for humans and software. Any meta-information can be added to both suppliers and components to help an external script update info, if needed.
nitrousnrg wrote:Relying fields like price and availability into an isolated database is no good, prices changes and components goes off of stock very fast.
They are a rough estimate in this case, unless updated manually or by a script periodically.
nitrousnrg wrote:So, I registered at octopart.com, in order to get unlimited access to their search engine API. You don't have to register, unless you are going to do more than a 100 searches per day.

http://octopart.com/api/v2/parts/search?q=1N5364BRLG

will search for the part number 1N5364BRLG (a zener). Click over it to see the http response.

This follows JSON, I have no clue about what it is, but you might find it useful.
It sure is a nice add-on, but not an essential core part. JSON structures are contain equivalent structures/types as YAML. They both are convertable into each other and both are easy to parse and handle. The big difference is that human-readability/writeability of JSON sucks.

It's fine to build an external script to update things like this for electronics components, but the freebombs itself can be used for any kind of parts and much different goals than this first usage scenario.

Including automatic database updating in the selector/viewer app wouldn't make sense, it's easy to re-read the db after updating and it wouldn't even mess up the user's session (much) as long as the ID's and the configuration stay the same.

I could do a separate script, which would reside in the freeems-puma-spin1.bombs repository and would update parts from octopart. It's however nothing I'll include in the main freebombs repository, because a feature like that is entirely optional and would only make the app less generic and more complex.

Even if one wants to replace the source engine from yaml to anything else, it's a fairly easy job, as long as the data structures are similar. There are no hard dependencies on yaml except for the couple of lines that reads its contents and uses the YAML library to convert it into Arrays, Hashes, Strings, Numbers and Booleans.
Jammi
DIP8 - Involved
Posts: 24
Joined: Mon May 02, 2011 5:07 am

Re: FreeBOMBS

Post by Jammi »

Jammi wrote:It's an isolated database for a good reason: flexibility.
Other good reasons are tracking of changes (via repository) as well as reliability (relying on external parties directly makes the system only as reliable as the sum of the external dependencies).
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeBOMBS

Post by Fred »

Jammi wrote:because a feature like that is entirely optional and would only make the app less generic and more complex.
I wish people understood me when I said that! I may have to borrow your words in future!
Jammi wrote:
Jammi wrote:It's an isolated database for a good reason: flexibility.
Other good reasons are tracking of changes (via repository) as well as reliability (relying on external parties directly makes the system only as reliable as the sum of the external dependencies).
+1 to the change management! Git control is EXTREMELY POWERFUL, don't underestimate it, people!
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: FreeBOMBS

Post by nitrousnrg »

Jammi wrote:I could do a separate script, which would reside in the freeems-puma-spin1.bombs repository and would update parts from octopart. It's however nothing I'll include in the main freebombs repository, because a feature like that is entirely optional and would only make the app less generic and more complex.
Oh, don't worry, If its not in your plans, don't do it. I just still don't get the use of writing a complete database for this situation, so I was trying to avoid doing so.

Xess corp has something like a database for they Xula board. Its powered by an user script that has the part numbers and you choose which supplier you wil use. It checks for avaliability as far as I remember. Its for Eagle, though.

Its about time to push something... tried to add a supplier, but it expects that every component will have the part number for both suppliers, so I'll just replace the part or add a replacement.
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeBOMBS

Post by Fred »

nitrousnrg wrote:tried to add a supplier, but it expects that every component will have the part number for both suppliers, so I'll just replace the part or add a replacement.
That sounds like a bug or flaw to me. That will regularly not be the case. Jammi, comments?
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Jammi
DIP8 - Involved
Posts: 24
Joined: Mon May 02, 2011 5:07 am

Re: FreeBOMBS

Post by Jammi »

Fred wrote:
nitrousnrg wrote:tried to add a supplier, but it expects that every component will have the part number for both suppliers, so I'll just replace the part or add a replacement.
That sounds like a bug or flaw to me. That will regularly not be the case. Jammi, comments?
Marcos' assumption is correct, the solution to it too.
Yes, it expects each part to be available from every supplier listed and if not, a replacement supplied.
I'm open to suggestions about how to handle missing parts gracefully, list of supplier preferences, which would build several BOM's? Something like that might make the software pretty complex internally as well as for the user.
Possibility of bugs are likely too, because the multi-supplier mode hasn't been tested yet; there hasn't been any data to test on.
Jammi
DIP8 - Involved
Posts: 24
Joined: Mon May 02, 2011 5:07 am

Re: FreeBOMBS

Post by Jammi »

One temporary work-around would be defining one or several "null" parts, which would satisfy dependencies. It would have each supplier listed with price: 0 or something and defined as a fall-back for components that don't have alternatives within a single vendor's scope.

So, before I do any implementation work further, I'd like the mode of operation discussed throughly to map different alternative approaches of how to implement this stuff.

List of ideas:
  • A sortable list of suppliers in order of preference instead of the Preferences -> Supplier option, where currently is an option to choose a single supplier amongs many, each having all components in stock. One of the supplier options would be "I already have this component or I'll buy it from another vendor"
  • For each component, a similar list, but only the suppliers with the part available would be listed as selection options. Others would be filtered out.
  • Another mode, instead of sorting a list of preferred suppliers manually, would be a simple (from the user's point of view) "Optimize prize" mode instead. It would however need to take into account "shipping and handling" as a virtual component too, which makes it a bit more complex to implement.
Meanwhile, I'll implement usability improvements that are clear:
  • A proper, custom BOM widget instead of the crude ascii table in use currently.
  • Vendor-specific specification syntax for the output.
  • Each of these are individual pieces of software, which can be used zero, once or many times. Just the data fed to them matters (and the code processing the data).
I also added a project management site with a issue tracker and such, it's here: http://rsence.org/projects/freebombs
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeBOMBS

Post by Fred »

This thread has been (rightly) filled with Puma specific talk, I may give it a clear out later and move the non FreeBOMBS specific stuff to another place, but not right now.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Jammi
DIP8 - Involved
Posts: 24
Joined: Mon May 02, 2011 5:07 am

Re: FreeBOMBS

Post by Jammi »

I sign off for now.
Locked