Re: [Kicad-developers] Component fields use case
On 08/31/2011 05:11 PM, Brian Sidebotham wrote: On 31 August 2011 22:42, Dick Hollenbeck d...@softplc.com wrote: Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg00531.html Brian, where did we ever put your python generic netlist post-processor? I could not find that on the mailing list. Dick Hi Dick, I just had a look on that mailing list archive, but it is messed up. That was the right thread, but that mail archive does not match the mail archive I have on my machine! Anyway, I have re-attached the last python BOM scripts I did, and below is a copy of the email: It should be noted, as I've just looked that these are not Python 3.x compatible due to the print statements. Print in 3.x is now a function. Hi Guys, I have attached a first effort for some python scripts. Still some work to do, but there are some example BOM generators which create list, csv and html versions of a BOM. The code should work with anything above python 2.3 (including 3.x) so we shouldn't have any issues with python versions. The main stumbling block appears to be string formatting. The % method is soon to be deprecated in the 3.x series of python. V2.7 is apparently going to be the last version in the 2.x series. Development will now only concentrate on the 3.x series. The reader I implemented creates a complete netlist tree in RAM, so everything is available to do with what you want. The examples start easy, and get more complex: bom_example1.py - Create a simple list, one component per line, tab delimited (similar to kicad original BOM output) bom_example2.py - As above, but CSV output, suitable for open office or excel, etc. bom_example3.py - As (2), but with components grouped by matching values + library parts bom_example4.py - As (3), but HTML format instead bom_example5.py - Demonstration of a more sophisticated method of output formatting and grouping technique There is definitely some more testing to do, and probably some more tidying up and what not, but attached is where it's currently at. All comments and suggestions welcome as always. I have been using the following plugin command: python /path/to/example/script.py %I example.lst, csv, htm, etc. Best Regards, Brian. Today, I committed these scripts into the source tree under scripts/python I don't see any copyright messages in these scripts Brian. Feel free to fix that. I eventually want to get something into KiCad's installation as well, but I'm thinking currently of these as being in a staging area for refinement before we start installing them. I have yet to use them, and have some rather high expectations on BOM since I have a Java based one that I spent a good deal of time on, but now want to see that functionality duplicated in the python stuff. Once it is, and there is sufficient utility to justify that these get installed as part of the KiCad package, we should then install them. So we should consider this the first step in an evolving process, and any other contributors are welcome to chime in. In fact, we should probably take this BOM discussion to a launchpad blueprint to capture the thread properly. The blueprint thread can also include how to use the current version of these python BOM scripts. Thanks! Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 1 September 2011 14:58, Fred Cooke fred.co...@gmail.com wrote: You can't improve anything without making changes, Dick. An oxymoron there considering you're trying to argue the below: And his point re breaking the API that exists (he's not the only one who has scripts against your text files and prefers kicad for text file storage reasons) is valid. API !? Since when is a file format an API? It isn't. Also, it is a myth formed in this thread that Dick changed the file format anyway. Go and look in the file format specification, the only thing that changed about the format in Jan 2009 was that the number of possible fields increased due to the work on the template fields, which was a very welcome addition to KiCad (Thanks again Dick for completing that work!). The OP's script relied on the field number being consistent, but this couldn't be the case after the template field names improvement. There was no written guarantee in the file format about this number, and it would seem minimally intrusive that after 2 years of this improvement being implemented someone's external script needs a bit of maintenance. This doesn't seem unreasonable. Hopefully the developers will see past the moaning and carry on their excellent work. It is appreciated by some! $0.02 towards all the developers wages right there... Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
libraries from what they are now to key-value pairs in a new file format. And I can deal with that file format not handling null strings. But it's a bit rough on those of us using kicad to pull the rug out from underneath us by jiggering the existing file format. If you aren't releasing the next stable version until after there's a new file format, fine. But otherwise... ouch. The the addition of field templates did not change the current file format AFAIK. What I'm not sure of is if you define a field in library component that it's value is copied into the schematic component field when that field name is already defined in the template list. As for the forthcoming file format, it should be transparent to the user that the file format has even changed. Hmm, I hadn't payed attention to the field template when it was introduced because it's not useful to me. The present stable version has the same behavior: When a template field matches an existing field, and component properties are edited in eeschema, it inserts the existing field at the beginning of the non-reserved ones (id 4) and re-numbers all subsequent fields. Subsequently generating a BOM shows that the components fields are scrambled because the BOM generation uses ID rather than the field name to organize columns. ... Apparently as long as I leave the field templates empty it leaves the component fields in the same order as read which is why we haven't noticed any problems during board production. Now that I know the devil and it's nature, I'm happy to let it lay where it is. Under the specific conditions I use it, it does not damage the libraries, schematics, and production scripts I use, so it's not a problem for me. You guys should consider putting a warning on the field templates form though until the new format comes. Regards, Hauptmech Kicad is not a word processor. We intend to preserve a design as the file format evolves, not what the design looks like on disk. Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. Dick I think the design *is* the file (or files). Kicad and all the other tools manipulating the file are just user interface. This is part of why I use kicad. If the design was the kicad app internal memory, then you would be dumping that to some efficient and easy to maintain binary format in between work sessions. Anyway I'll just log my humble request as an active user that you guys change from one file format to the next in one big version change rather than a lot of little increments. It's not the end of the world if you don't... I just stay with whatever the last working-for-me version there is until the changeover is complete; but it's nice to be able to take advantage of the GUI updates as they happen. hauptmech ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 1 September 2011 06:28, Dick Hollenbeck d...@softplc.com wrote: Proposal: Are you ok with licensing this work under GPL? If so, can we check these into a contrib directory or something, as part of the tree, along with a readme.txt or readme.html file? (Although I think that posting which talks about the %B etc, is close to what might be good enough.) If OK, let us know. You can always change them later, as can anyone. I'm not saying that they'd get installed as part of Kicad, but they should be in the tree for someone to learn from and modify. And then if enough folks want them in the install, that seems easy enough in the future. Any one object? I'd like to see a growing body of work evolve out of the xml based generic netlist export file. I have a Java based BOM generator now, that I would ditch in favor of a python version if it did what I want. So I see perhaps several alternative implementations evolve from yours in here. Dick Hi Dick, Yes this is OK, GPL is absolutely fine. I can do the readme, and perhaps one more scan through and tidy up would be nice too. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 9/1/2011 1:28 AM, Dick Hollenbeck wrote: Proposal: Are you ok with licensing this work under GPL? If so, can we check these into a contrib directory or something, as part of the tree, along with a readme.txt or readme.html file? (Although I think that posting which talks about the %B etc, is close to what might be good enough.) If OK, let us know. You can always change them later, as can anyone. I'm not saying that they'd get installed as part of Kicad, but they should be in the tree for someone to learn from and modify. And then if enough folks want them in the install, that seems easy enough in the future. Any one object? Sounds reasonable to me. Wayne I'd like to see a growing body of work evolve out of the xml based generic netlist export file. I have a Java based BOM generator now, that I would ditch in favor of a python version if it did what I want. So I see perhaps several alternative implementations evolve from yours in here. Dick On 08/31/2011 05:11 PM, Brian Sidebotham wrote: On 31 August 2011 22:42, Dick Hollenbeck d...@softplc.com wrote: Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg00531.html Brian, where did we ever put your python generic netlist post-processor? I could not find that on the mailing list. Dick Hi Dick, I just had a look on that mailing list archive, but it is messed up. That was the right thread, but that mail archive does not match the mail archive I have on my machine! Anyway, I have re-attached the last python BOM scripts I did, and below is a copy of the email: It should be noted, as I've just looked that these are not Python 3.x compatible due to the print statements. Print in 3.x is now a function. Hi Guys, I have attached a first effort for some python scripts. Still some work to do, but there are some example BOM generators which create list, csv and html versions of a BOM. The code should work with anything above python 2.3 (including 3.x) so we shouldn't have any issues with python versions. The main stumbling block appears to be string formatting. The % method is soon to be deprecated in the 3.x series of python. V2.7 is apparently going to be the last version in the 2.x series. Development will now only concentrate on the 3.x series. The reader I implemented creates a complete netlist tree in RAM, so everything is available to do with what you want. The examples start easy, and get more complex: bom_example1.py - Create a simple list, one component per line, tab delimited (similar to kicad original BOM output) bom_example2.py - As above, but CSV output, suitable for open office or excel, etc. bom_example3.py - As (2), but with components grouped by matching values + library parts bom_example4.py - As (3), but HTML format instead bom_example5.py - Demonstration of a more sophisticated method of output formatting and grouping technique There is definitely some more testing to do, and probably some more tidying up and what not, but attached is where it's currently at. All comments and suggestions welcome as always. I have been using the following plugin command: python /path/to/example/script.py %I example.lst, csv, htm, etc. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 09/01/2011 03:33 AM, hauptmech wrote: libraries from what they are now to key-value pairs in a new file format. And I can deal with that file format not handling null strings. But it's a bit rough on those of us using kicad to pull the rug out from underneath us by jiggering the existing file format. If you aren't releasing the next stable version until after there's a new file format, fine. But otherwise... ouch. The the addition of field templates did not change the current file format AFAIK. What I'm not sure of is if you define a field in library component that it's value is copied into the schematic component field when that field name is already defined in the template list. As for the forthcoming file format, it should be transparent to the user that the file format has even changed. Hmm, I hadn't payed attention to the field template when it was introduced because it's not useful to me. The present stable version has the same behavior: When a template field matches an existing field, and component properties are edited in eeschema, it inserts the existing field at the beginning of the non-reserved ones (id 4) and re-numbers all subsequent fields. Subsequently generating a BOM shows that the components fields are scrambled because the BOM generation uses ID rather than the field name to organize columns. ... Apparently as long as I leave the field templates empty it leaves the component fields in the same order as read which is why we haven't noticed any problems during board production. Now that I know the devil and it's nature, I'm happy to let it lay where it is. Under the specific conditions I use it, it does not damage the libraries, schematics, and production scripts I use, so it's not a problem for me. You guys should consider putting a warning on the field templates form though until the new format comes. Regards, Hauptmech Kicad is not a word processor. We intend to preserve a design as the file format evolves, not what the design looks like on disk. Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. Dick I think the design *is* the file (or files). Kicad and all the other tools manipulating the file are just user interface. This is part of why I use kicad. If the design was the kicad app internal memory, then you would be dumping that to some efficient and easy to maintain binary format in between work sessions. Anyway I'll just log my humble request as an active user that you guys change from one file format to the next in one big version change rather than a lot of little increments. No, the pay is too low around here to try and improve the package without implementing changes. It's not the end of the world if you don't... I just stay with whatever the last working-for-me version there is until the changeover is complete; but it's nice to be able to take advantage of the GUI updates as they happen. hauptmech ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
You can't improve anything without making changes, Dick. And his point re breaking the API that exists (he's not the only one who has scripts against your text files and prefers kicad for text file storage reasons) is valid. Why the unpleasant attitude? :-/ On Thu, Sep 1, 2011 at 3:51 PM, Dick Hollenbeck d...@softplc.com wrote: On 09/01/2011 03:33 AM, hauptmech wrote: libraries from what they are now to key-value pairs in a new file format. And I can deal with that file format not handling null strings. But it's a bit rough on those of us using kicad to pull the rug out from underneath us by jiggering the existing file format. If you aren't releasing the next stable version until after there's a new file format, fine. But otherwise... ouch. The the addition of field templates did not change the current file format AFAIK. What I'm not sure of is if you define a field in library component that it's value is copied into the schematic component field when that field name is already defined in the template list. As for the forthcoming file format, it should be transparent to the user that the file format has even changed. Hmm, I hadn't payed attention to the field template when it was introduced because it's not useful to me. The present stable version has the same behavior: When a template field matches an existing field, and component properties are edited in eeschema, it inserts the existing field at the beginning of the non-reserved ones (id 4) and re-numbers all subsequent fields. Subsequently generating a BOM shows that the components fields are scrambled because the BOM generation uses ID rather than the field name to organize columns. ... Apparently as long as I leave the field templates empty it leaves the component fields in the same order as read which is why we haven't noticed any problems during board production. Now that I know the devil and it's nature, I'm happy to let it lay where it is. Under the specific conditions I use it, it does not damage the libraries, schematics, and production scripts I use, so it's not a problem for me. You guys should consider putting a warning on the field templates form though until the new format comes. Regards, Hauptmech Kicad is not a word processor. We intend to preserve a design as the file format evolves, not what the design looks like on disk. Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. Dick I think the design *is* the file (or files). Kicad and all the other tools manipulating the file are just user interface. This is part of why I use kicad. If the design was the kicad app internal memory, then you would be dumping that to some efficient and easy to maintain binary format in between work sessions. Anyway I'll just log my humble request as an active user that you guys change from one file format to the next in one big version change rather than a lot of little increments. No, the pay is too low around here to try and improve the package without implementing changes. It's not the end of the world if you don't... I just stay with whatever the last working-for-me version there is until the changeover is complete; but it's nice to be able to take advantage of the GUI updates as they happen. hauptmech ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 08/31/2011 08:31 AM, hauptmech wrote: From the bzr log message is appears that fields not in the template list will be deleted on exit from the component edit dialog. Or read differently Fields with a null value and not listed in the template list will be deleted (which seems to be the behavior when I play with it...) I store quite a bit of component meta-data here in the fields which either gets dumped to the BOM for automatic purchase order generation, or get's manipulated via python scripts accessing the raw eeschema files. Presently the file format uniquely identifies each field with an id integer. So empty values for field name and field value are technically not a problem. At least this was my assumption and it seems a reasonable conclusion for anyone writing scripts against the .sch file. I happen to use the field name as a key for some things and so they are unique, and non-null in my case. However there are lots of good reasons to stick a null in the field value and automatically stripping fields with a null value string would be undesired. I just noticed that if one of my field names is in the template it get's shuffled in the order. Also template fields get inserted before existing fields, and this order is being propogated to the field ID in the file... This will break things external to eeschema. I don't mind if they get displayed in a different order on screen but changing the ID in the file is very bad so the source of that should be tracked down and fixed. Regarding the fields template: In my opinion this should only be used inside the library component editor. Once a component is in the library; the component is *itself* a template for adding information to the schematic. I don't think we want to be 'automatically' modifing the components, making assumptions about the library creators intentions. I hope this is useful. -hauptmech Two weeks of my time wasted. Sheesh. I really cannot agree with a single thing here. Sorry. Life is too short for this. Use the template fieldnames, put all your fields in there, every last one of them, then if they are blank, they go away. Search for your fields by name. The number is going away, period. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On Wed, 31 Aug 2011, Dick Hollenbeck wrote: Life is too short for this. Use the template fieldnames, put all your fields in there, every last one of them, then if they are blank, they go away. Search for your fields by name. The number is going away, period. Agree 100%... it's more than 30 years that the relational db people agree on the NULL value significance or even acceptance (it isn't here? has a default value? simply it's no significant?) and the instance/attribute/value DB (which the kicad attribute system is a kind of...) only *sometimes* have a default value defined. IMHO if there is no value, the attribute has no reason to stay... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 8/31/2011 12:16 PM, hauptmech wrote: On Wed, 2011-08-31 at 09:23 -0500, Dick Hollenbeck wrote: On 08/31/2011 08:31 AM, hauptmech wrote: From the bzr log message is appears that fields not in the template list will be deleted on exit from the component edit dialog. Or read differently Fields with a null value and not listed in the template list will be deleted (which seems to be the behavior when I play with it...) I store quite a bit of component meta-data here in the fields which either gets dumped to the BOM for automatic purchase order generation, or get's manipulated via python scripts accessing the raw eeschema files. Presently the file format uniquely identifies each field with an id integer. So empty values for field name and field value are technically not a problem. At least this was my assumption and it seems a reasonable conclusion for anyone writing scripts against the .sch file. I happen to use the field name as a key for some things and so they are unique, and non-null in my case. However there are lots of good reasons to stick a null in the field value and automatically stripping fields with a null value string would be undesired. I just noticed that if one of my field names is in the template it get's shuffled in the order. Also template fields get inserted before existing fields, and this order is being propogated to the field ID in the file... This will break things external to eeschema. I don't mind if they get displayed in a different order on screen but changing the ID in the file is very bad so the source of that should be tracked down and fixed. Regarding the fields template: In my opinion this should only be used inside the library component editor. Once a component is in the library; the component is *itself* a template for adding information to the schematic. I don't think we want to be 'automatically' modifing the components, making assumptions about the library creators intentions. I hope this is useful. -hauptmech Two weeks of my time wasted. Sheesh. I really cannot agree with a single thing here. Sorry. Life is too short for this. Use the template fieldnames, put all your fields in there, every last one of them, then if they are blank, they go away. Search for your fields by name. The number is going away, period. Dick I can migrate the metadata in my libraries from what they are now to key-value pairs in a new file format. And I can deal with that file format not handling null strings. But it's a bit rough on those of us using kicad to pull the rug out from underneath us by jiggering the existing file format. If you aren't releasing the next stable version until after there's a new file format, fine. But otherwise... ouch. The the addition of field templates did not change the current file format AFAIK. What I'm not sure of is if you define a field in library component that it's value is copied into the schematic component field when that field name is already defined in the template list. As for the forthcoming file format, it should be transparent to the user that the file format has even changed. Wayne Hauptmech ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 31/08/2011 9:35 p.m., Wayne Stambaugh wrote: On 8/31/2011 12:16 PM, hauptmech wrote: On Wed, 2011-08-31 at 09:23 -0500, Dick Hollenbeck wrote: On 08/31/2011 08:31 AM, hauptmech wrote: From the bzr log message is appears that fields not in the template list will be deleted on exit from the component edit dialog. Or read differently Fields with a null value and not listed in the template list will be deleted (which seems to be the behavior when I play with it...) I store quite a bit of component meta-data here in the fields which either gets dumped to the BOM for automatic purchase order generation, or get's manipulated via python scripts accessing the raw eeschema files. Presently the file format uniquely identifies each field with an id integer. So empty values for field name and field value are technically not a problem. At least this was my assumption and it seems a reasonable conclusion for anyone writing scripts against the .sch file. I happen to use the field name as a key for some things and so they are unique, and non-null in my case. However there are lots of good reasons to stick a null in the field value and automatically stripping fields with a null value string would be undesired. I just noticed that if one of my field names is in the template it get's shuffled in the order. Also template fields get inserted before existing fields, and this order is being propogated to the field ID in the file... This will break things external to eeschema. I don't mind if they get displayed in a different order on screen but changing the ID in the file is very bad so the source of that should be tracked down and fixed. Regarding the fields template: In my opinion this should only be used inside the library component editor. Once a component is in the library; the component is *itself* a template for adding information to the schematic. I don't think we want to be 'automatically' modifing the components, making assumptions about the library creators intentions. I hope this is useful. -hauptmech Two weeks of my time wasted. Sheesh. I really cannot agree with a single thing here. Sorry. Life is too short for this. Use the template fieldnames, put all your fields in there, every last one of them, then if they are blank, they go away. Search for your fields by name. The number is going away, period. Dick I can migrate the metadata in my libraries from what they are now to key-value pairs in a new file format. And I can deal with that file format not handling null strings. But it's a bit rough on those of us using kicad to pull the rug out from underneath us by jiggering the existing file format. If you aren't releasing the next stable version until after there's a new file format, fine. But otherwise... ouch. The the addition of field templates did not change the current file format AFAIK. What I'm not sure of is if you define a field in library component that it's value is copied into the schematic component field when that field name is already defined in the template list. As for the forthcoming file format, it should be transparent to the user that the file format has even changed. Hmm, I hadn't payed attention to the field template when it was introduced because it's not useful to me. The present stable version has the same behavior: When a template field matches an existing field, and component properties are edited in eeschema, it inserts the existing field at the beginning of the non-reserved ones (id 4) and re-numbers all subsequent fields. Subsequently generating a BOM shows that the components fields are scrambled because the BOM generation uses ID rather than the field name to organize columns. ... Apparently as long as I leave the field templates empty it leaves the component fields in the same order as read which is why we haven't noticed any problems during board production. Now that I know the devil and it's nature, I'm happy to let it lay where it is. Under the specific conditions I use it, it does not damage the libraries, schematics, and production scripts I use, so it's not a problem for me. You guys should consider putting a warning on the field templates form though until the new format comes. Regards, Hauptmech Wayne Hauptmech ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to :
Re: [Kicad-developers] Component fields use case
Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg00531.html Brian, where did we ever put your python generic netlist post-processor? I could not find that on the mailing list. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
On 31 August 2011 23:11, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 31 August 2011 22:42, Dick Hollenbeck d...@softplc.com wrote: Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg00531.html Here is a link to the actual message on Launchpad, this details the references and follow-ups: https://lists.launchpad.net/kicad-developers/msg05212.html Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Component fields use case
Proposal: Are you ok with licensing this work under GPL? If so, can we check these into a contrib directory or something, as part of the tree, along with a readme.txt or readme.html file? (Although I think that posting which talks about the %B etc, is close to what might be good enough.) If OK, let us know. You can always change them later, as can anyone. I'm not saying that they'd get installed as part of Kicad, but they should be in the tree for someone to learn from and modify. And then if enough folks want them in the install, that seems easy enough in the future. Any one object? I'd like to see a growing body of work evolve out of the xml based generic netlist export file. I have a Java based BOM generator now, that I would ditch in favor of a python version if it did what I want. So I see perhaps several alternative implementations evolve from yours in here. Dick On 08/31/2011 05:11 PM, Brian Sidebotham wrote: On 31 August 2011 22:42, Dick Hollenbeck d...@softplc.com wrote: Your best bet is to take a look at the generic netlist export, which is in XML. That format we hope to preserve, while the world around it might morph, for good cause. http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg00531.html Brian, where did we ever put your python generic netlist post-processor? I could not find that on the mailing list. Dick Hi Dick, I just had a look on that mailing list archive, but it is messed up. That was the right thread, but that mail archive does not match the mail archive I have on my machine! Anyway, I have re-attached the last python BOM scripts I did, and below is a copy of the email: It should be noted, as I've just looked that these are not Python 3.x compatible due to the print statements. Print in 3.x is now a function. Hi Guys, I have attached a first effort for some python scripts. Still some work to do, but there are some example BOM generators which create list, csv and html versions of a BOM. The code should work with anything above python 2.3 (including 3.x) so we shouldn't have any issues with python versions. The main stumbling block appears to be string formatting. The % method is soon to be deprecated in the 3.x series of python. V2.7 is apparently going to be the last version in the 2.x series. Development will now only concentrate on the 3.x series. The reader I implemented creates a complete netlist tree in RAM, so everything is available to do with what you want. The examples start easy, and get more complex: bom_example1.py - Create a simple list, one component per line, tab delimited (similar to kicad original BOM output) bom_example2.py - As above, but CSV output, suitable for open office or excel, etc. bom_example3.py - As (2), but with components grouped by matching values + library parts bom_example4.py - As (3), but HTML format instead bom_example5.py - Demonstration of a more sophisticated method of output formatting and grouping technique There is definitely some more testing to do, and probably some more tidying up and what not, but attached is where it's currently at. All comments and suggestions welcome as always. I have been using the following plugin command: python /path/to/example/script.py %I example.lst, csv, htm, etc. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
