In my day job, I've heard concern about a transistor passing to much current. On multiple occasions I was required to design machine(s) in an explosive environment(s) where the energy dissipated by a spark has to be low enough that it can not create ignition. I've also seen size concern for SCCR ratings. Both don't apply here. We're not concerned with arc flash, or preventing the system from storing residual power. So eh as far as I'm concerned, Fred being Fred. The injector or load should be the current limiting device as far as I'm concerned. The fusing should be there to prevent fire. The transistor should be as large and fast as reasonably possible, and should be talked about in the injector driver threads.
About he BOM thing. Jammi, did you know about the .lst file? I populated the schematic symbols with properties, I seem to recall most parts either have (or can have) properties for SMT vendors, and DFH allows for 2 sources of SMT and Thru hole vendors. Then when KICAD generates the .lst file, it can produce the vendor and MFG of a component as well as it's ref designator. Sounds like you are probably good with parsing text files, so that file would likely help you generate an orderBOM.
FreeBOMBS
Re: FreeBOMBS
And in reality, on DIYefi.org, it's gerber -> manufacturer, (PCB + BOM + position) -> user, order sheet -> supplier, parts -> user. There isn't much DIY about having something manufactured. You just become a designer for the benefit of others at no benefit to yourself. The idea of this site is to facilitate many people to build their own stuff. That's the whole point.nitrousnrg wrote:In my mind, it is (gerber+BOM+position) -> manufacturer -> user.
Great, looks easily parse-able too!Something FYI, you may find it interesting. A kicad's schematic is a text file. <snip>
https://github.com/nitrousnrg/puma/blob ... 9924_1.sch
We know that, but 35 people are relying on you for this information, and for it to be correct. Thousands of others are relying on the testing that those 35 will provide if they get their Pumas running. I need that testing, as do you. You can't sell Pumas for money if there isn't a mature software solution wrapped around them, and right now, it's still a bit beta. It NEEDS testing, hence we ALL need people building and running these, the more the merrier.The problem here, is that I don't want to do all this stuff from kicad for spin1, since its a dead branch, and that information can't be merged into the spin2 schematic.
The trick, then, is to do things only once, somehow. Whether that is to parse from YAML and output .sch text or vice versa or to keep the schem stuff minimal and put the rest of the info in the BOM database, or whatever, isn't relevant, BUT, the online stuff, with the configurability, just like Jared's cool spreadsheet, is really quite important to the DIY crowd. As I see it, this is a significant step up from the spreadsheet, and manageable properly, with git, which is good for everyone. The spreadsheet was a big step up from a kicad output file too.I'm not sure if this is the right way to go. I like the online documentation, but I don't like having the BOM in such a distant and non-mergeable database. Its doing things twice. Of course, I can be wrong and missing important pieces of the picture.
BINGO, exactly the right attitude! :-)so I could start thinking about how to get this info directly from eeschema. That could make you popular in the kicad mailing list.
I'll do another thread on this topic, and link it here.And about the VPN, its the first time I hear a complain about a transistor flowing too much current.
You're not a naturally negative person, Marcos. Find a way out of the rut that you're in, it's not healthy.PS: 45' for such a crappy and unuseful post. I hate myself.
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!
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!
Re: FreeBOMBS
I saw that yes, the thing is, the parts still need to be verified against availability. The electrical specs in the yaml are entirely optional (at least for now), but these are mandatory:jharvey wrote:About he BOM thing. Jammi, did you know about the .lst file? I populated the schematic symbols with properties, I seem to recall most parts either have (or can have) properties for SMT vendors, and DFH allows for 2 sources of SMT and Thru hole vendors. Then when KICAD generates the .lst file, it can produce the vendor and MFG of a component as well as it's ref designator. Sounds like you are probably good with parsing text files, so that file would likely help you generate an orderBOM.
- title (human-readable)
- description (human-readable, detailed, says what the component's role is)
- data sheet url (actually an alternative to description, but both are suggested). needed for reference purposes, so that if a part becomes obsolete, there is some clues what's required for the replacement.
- suppliers: info about supplier-specific price and part number
Some items aren't found at all suppliers, so an alternative needs to be filled in for those. Its relationship is defined using the 'replacement' attribute of the primarily suggested component.
FreeBOMBS currently works in cli mode (not all detailed editors implemented, but it calculates correctly). I'm currently working on the web UI, which will feature a full set of the functionality already implemented.
Re: FreeBOMBS
I tried it the other day, very cool! I can't wait to see the web interface! :-) You're a hero!Jammi wrote:FreeBOMBS currently works in cli mode (not all detailed editors implemented, but it calculates correctly). I'm currently working on the web UI, which will feature a full set of the functionality already implemented.
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!
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!
Re: FreeBOMBS
The first alpha-quality release is now online as a preview: http://sorsacode.com:8001/
There are several things to be done, but the biggest are related to the database, as mentioned earlier.
There are at least the following to do still before declaring beta:
1) Adding titles, descriptions and data sheets to the component listings.
2) Testing with a database populated with components for several suppliers (only digikey data is present now). The feature is theoretically there, but it has not been tested and I'm sure there are some bugs related to that. That's why I asked people to help with the component database well in advance so I could have more data to test with.
2.1) If the Puma BOM is as impossible to define as it seems, I'll consider other products to test the software with.
3) Making a pretty bill of materials instead of the ASCII placeholder recycled from the CLI version (depends partially on 2).
4) Fixing some minor ui glitches when found
5) Implementing vendor-specific BOM exports and maybe online forms too. However, this feature needs to be generic, so there is some work-around to do regarding that. (depends on 2)
So, functionality-wise we are basically stuck on development for the most part, until we have more data to test on. I'm considering option 2.1 for now, as I can't proceed on the Puma BOM alone. I'll implement the test database to something obvious and simple, like implementing a LEGO kit BOM and using individual LEGO blocks as components and sourcing various suppliers and possible replacement parts for those.
There are several things to be done, but the biggest are related to the database, as mentioned earlier.
There are at least the following to do still before declaring beta:
1) Adding titles, descriptions and data sheets to the component listings.
2) Testing with a database populated with components for several suppliers (only digikey data is present now). The feature is theoretically there, but it has not been tested and I'm sure there are some bugs related to that. That's why I asked people to help with the component database well in advance so I could have more data to test with.
2.1) If the Puma BOM is as impossible to define as it seems, I'll consider other products to test the software with.
3) Making a pretty bill of materials instead of the ASCII placeholder recycled from the CLI version (depends partially on 2).
4) Fixing some minor ui glitches when found
5) Implementing vendor-specific BOM exports and maybe online forms too. However, this feature needs to be generic, so there is some work-around to do regarding that. (depends on 2)
So, functionality-wise we are basically stuck on development for the most part, until we have more data to test on. I'm considering option 2.1 for now, as I can't proceed on the Puma BOM alone. I'll implement the test database to something obvious and simple, like implementing a LEGO kit BOM and using individual LEGO blocks as components and sourcing various suppliers and possible replacement parts for those.
Re: FreeBOMBS
Oh, and regarding Microsoft Internet Explorer: yes, it's a very broken browser. I'm not considering working around its various bugs for a hobby project at this stage. Do the internet a favor and get a real browser, like Chrome or Firefox instead.
Re: FreeBOMBS
Marcos, you believe that the BOM that should be used should be what you ordered originally, can you at least check that the stuff in this database matches that? From there we can add stuff for hacks and remove stuff unrequired.
We still need an ignition circuit, and I can't experiment. I would love to ask someone with test equipment to try some stuff... we'll see.
Fred.
We still need an ignition circuit, and I can't experiment. I would love to ask someone with test equipment to try some stuff... we'll see.
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!
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!
Re: FreeBOMBS
Oh, and regarding setup of the web ui of FreeBOMBS:
1) Install Ruby (and RubyGems), Ruby 1.9.2 is a lot quicker than 1.8.7. Use RVM if the version of your distribution is outdated.
2) Once you have a gem command available, do this:
3) Get a copy of FreeBOMBS git clone git://github.com/jammi/FreeBOMBS.git freebombs
4) Get a copy of the Puma Spin 1 database:
6) Run the web app: rsence-pre run -af
1) Install Ruby (and RubyGems), Ruby 1.9.2 is a lot quicker than 1.8.7. Use RVM if the version of your distribution is outdated.
2) Once you have a gem command available, do this:
- sudo gem install bluecloth
- sudo gem install sqlite3 (You also need to have libsqlite3 installed as a system-level dependency. It's optional but recommended: it's used as the default persistent session database storage engine.)
- sudo gem install rsence-pre
3) Get a copy of FreeBOMBS git clone git://github.com/jammi/FreeBOMBS.git freebombs
4) Get a copy of the Puma Spin 1 database:
- cd freebombs/dbs
- git clone git@github.com:jammi/freeems-puma-spin1.bombs.git freeems-puma-spin1
- cd ..
- Edit conf/config.yaml -- Change db_name near the bottom of the config file from test to freeems-puma-spin1
6) Run the web app: rsence-pre run -af
- You use it in deamon mode by using common daemon management commands start, stop, restart and status instead of run.
- When running it as a daemon, suppress the -f switch, because you'll not want the logs to appear in the log files instead of your terminal's stdout and stderr
- The -a switch enables automatic updates, so once you've edited and checked the db for errors, you can just touch plugins/freebombs-web/freebombs-web.rb to have it reload the changes without restarting the rsence web server.
- Point your browser to http://localhost:8001/ to use freebombs-web.
- nitrousnrg
- LQFP144 - On Top Of The Game
- Posts: 468
- Joined: Tue Jun 24, 2008 5:31 pm
Re: FreeBOMBS
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.Jammi wrote:I saw that yes, the thing is, the parts still need to be verified against availability. The electrical specs in the yaml are entirely optional (at least for now).jharvey wrote:About he BOM thing. Jammi, did you know about the .lst file? I populated the schematic symbols with properties, I seem to recall most parts either have (or can have) properties for SMT vendors, and DFH allows for 2 sources of SMT and Thru hole vendors. Then when KICAD generates the .lst file, it can produce the vendor and MFG of a component as well as it's ref designator. Sounds like you are probably good with parsing text files, so that file would likely help you generate an orderBOM.
Relying fields like price and availability into an isolated database is no good, prices changes and components goes off of stock very fast.
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/documentation
quick example:
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.
Highlights:
{"text": "Diode; Zener Voltage Typ, Vz:33V; Power Dissipation, Pd:5W; Termination Type:Axial Leaded; Operating Temperature Range:-65\u00b0C to +200\u00b0C; Package/Case:Case 017; Leaded Process Compatible:Yes; Peak Reflow Compatible (260 C):Yes ;RoHS Compliant: Yes", "credit_domain": "newark.com", "credit_url": "http://www.newark.com/jsp/search/produc ... CMP=AFC-OP"}
"supplier": {"homepage_url": "http://www.digikey.com", "displayname": "Digi-Key", "__class__": "Brand", "id": 459}, "is_authorized": true, "is_brokered": false, "buynow_url": "http://octopart.com/click/vptrack?ak=68 ... id=1413226"}, {"sku": "863-1N5364BRLG", "avail": 4357, "sendrfq_url": null, "prices": [[1, 0.39000000000000001, "USD"]]
"supplier": {"homepage_url": "http://www.mouser.com", "displayname": "Mouser", "__class__": "Brand", "id": 2401}, "is_authorized": true, "is_brokered": false, "buynow_url": "http://octopart.com/click/vptrack?ak=68 ... d=37651780"}, {"sku": "1705484", "avail": 4833, "sendrfq_url": null, "prices": [[1, 0.20000000000000001, "USD"]]
And so on
This follows JSON, I have no clue about what it is, but you might find it useful.
What Iḿ interested into, is in a tool to display information, knowing only part number and quantity. Everything else can be found online.
Right now, we have a digikey# (only useful at digikey), part# (useful everywhere, in theory, octopart-searchable), and quantity, from those strings everything should be parsed, and Kicad files will have at least these last two fields for every compnente :-)
Have to go, I'm running late, more this night. I still owe some pictures in other threads.
Marcos
- nitrousnrg
- LQFP144 - On Top Of The Game
- Posts: 468
- Joined: Tue Jun 24, 2008 5:31 pm
Re: FreeBOMBS
And if FreeBOMBS already does this kind of online search, sorry, didn't see it :-/
Marcos