fritzing / fritzing-parts

Electronic components for use in the Fritzing app (aka the parts library)
http://fritzing.org/parts
Other
505 stars 358 forks source link

A full bin of voltage regulators #212

Open dmantione opened 5 years ago

dmantione commented 5 years ago

Hello,

I wanted to post this on the forums, but they seem broken: I have attempted to create accounts with two different e-mail addresses, but none of them receives the activation e-mail.

The news that Fritzing is being developed again has motivated me to work on something that annoyed me for a while: There are no good voltage regulator parts in Fritzing. There is the "voltage regulator" part, which is okay for an LM78xx, but if you want a switching regulator you are lost. Many people have designed custom parts and if you search on the internet you will find some, but the quality is often not optimal and in any case not consistent. Therefore when designing boards with Fritzing I spent way more time than desired on getting the power delivery right.

You need switching regulators IMO quite often: I.e. USB powered Arduino, but you need a higher voltage like 12V on your board. Or the other way around: You power from a 12V adapter, but have an Arduino or any ICs in general on your PCB, using an LM78xx is extremely wasteful.

What about the "Sparkfun Power-IC" bin? Well, it is terrible and has so much flaws that I believe its presence in Fritzing does more harm than good. Take for example the V_REG_LD1117VXX: It says "78xx" in the schematic, has the pinout of an LM78xx rather than a LD1117 and in the PCB view: The silkscreen is a work of art, but it isn't very usable, since the only reason to have a hole in the PCB is if you want to use the PCB as heatsink, but in that case you don't want to mount against the solder mask, but against exposed copper. In general "Sparkfun Power-IC" consists of many parts that are not all that relevant to Fritzing users, and are poorly designed parts.

So what did I create? A bin of voltage regulators:

http://www.freepascal.org/~daniel/Voltage_regulators.fzbz

There exists thousands of different regulators so it is of course a selection: I choose common regulators from the LM25 series, popular regulators from XLSEMI, Microchip and some popular charge pumps. They are present in multiple packages, such as DIP, SOIC, TO220 and TO263. In general I have tried to make a selection of parts that are relevant to Fritzing users. All have meaningful and useful metadata fields, so the dropdown boxes that Fritzing provides are useful to select between regulators.

For now there are buck regulators, boost regulators and charge pumps. There are no linear regulators at the moment, this is not by policy, but because I use mostly switching regulators myself and the popular LM78xx is already covered by the standard "voltage regulator" part. Unlike many custom parts you find, the tabs of TO220 and TO263 parts do work as they should, they have internal connections to the proper pin and you can use copper fills to create nice planes that allow to properly dissipate the heat into the PCB.

All parts have been tested in all design views to see if they behave as they should. There is only one part that I actually produced a PCB and soldered the part on it: The XL6009. Therefore I cannot rule out an unexpected surprise for one of these parts.

Hope you like it!

KjellMorgenstern commented 5 years ago

Opened PR https://github.com/fritzing/fritzing-parts/pull/new/voltage_regulators for this.

dmantione commented 5 years ago

Wow, this is the first time I contribute to a project that my contribution gets committed without any questions asked.

Thanks!

Daniël

KjellMorgenstern commented 5 years ago

Hehe, well, first, thanks a lot for the contribution, but so far it is just a pull request, so there is work left. Probably it is minor, copied over from the automated test: ==> WARN version undefined: /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/monacor_ltr_110_linetransformer.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.aoz3013pi_0671c5779d4831e9bb583672ac1d7afe_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.aoz3018pi_4b4d7335497bbf379c232d88829b4eaf_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.icl7660_44fc8a045bba7b5d59c3f73c1e79ff67_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.icl7660_dip_a69567b07fdd8c38176b0c6f9ef2093f_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.icl7662 (dip)_b0b26f8cea2efc2a43aad86f232f436b_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.icl7662 (soic)_ceb3f31b17d1c702d898c345cb9aa959_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.lm2574_dip_66badd838e8393d3c0dbcb8723600919_5.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.lm2574_soic_139fde836b26224f66fa149e18beb2eb_2.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.mic4574_5ee57349869fd1a1da296bd15e8e1743_1.fzp fritzingVersion undefined Errors @ /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/part.st662_d8b963bc77dd4b623cd15dc5ffd12c1a_6.fzp ==> WARN version undefined: /home/travis/gopath/src/github.com/fritzing/fritzing-parts/core/sparkfun_storage_microsd.fzp

KjellMorgenstern commented 5 years ago

Also when looking at it, one of the parts had a blank icon.

KjellMorgenstern commented 5 years ago

You can see the results from the automated test when going to the details here: https://github.com/fritzing/fritzing-parts/pull/213

dmantione commented 5 years ago

Hi!

I have taken a look, the parts in the repository indeed have a fritzingVersion="x.y.z" in their tag. It is not present in my parts. My parts have been exported by Fritzing itself, so I haven't done any manual editing. Is there a way to make Fritzing add this fritzingVersion="x.y.z" field, or should I edit the parts with a text editor?

I have inspected the .fzbz file for the icons, as I see it, all the icons are there. Which is the part that shows with a blank icon for you?

Daniël

KjellMorgenstern commented 5 years ago

The XL4016 part shows no icon.

image

Also, I got the error message Error reading file /home/kjell/git/fritzing-app/fritzing-0.9.4-debug.linux.AMD64/fritzing-parts/core/part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp: file for XL4016 xl4016_d347983e432b7485814462ea48d5bf18_1 not found.

when trying to add the part to a breadboard. After showing this error message, Fritzing crashed. Of course we could harden Fritzing code against this crash, but I think the problem is also somewhere with the part XL4016.

I the problem showed when directly using the bin from your download as well when using the file as I have deployed it in fritzing-parts.

I also saw artefacts showing instead of the icon.

KjellMorgenstern commented 5 years ago

Interestingly, the file exist: fritzing-parts/core/part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp, so the error message is misleading.

dmantione commented 5 years ago

I'll see if I can find anything wrong on my side.

Daniël

dmantione commented 5 years ago

I can't reproduce it, it works for me and I can delete and re-import the bin. I have made diffs with other parts and see no relevant deviations that might cause the part to fail.

What I do note is that Fritzing writes the date into the part in the language of the user interface:

 <title>XL4016</title>
 <label>VR</label>
 <date>zo aug. 18 2019</date>

I doubt this is desired, as the parts are used in data exchange (like we are doing now). However, all of my parts have it this way, so this cannot explain why specifically the XL4016 fails.

Further I note Fritzing keeps a reference in the part file to the part the part was original created from (i.e. save as new part and modify):

<module referenceFile="xl4015_6b5078816154b8728cafe03e7fce04a5_1.fzp

Again, more parts have this, so again it is no explanation why specifically the XL4016 fails.

vanepp commented 5 years ago

@dmantione : "I wanted to post this on the forums, but they seem broken: I have attempted to create accounts with two different e-mail addresses, but none of them receives the activation e-mail."

Unless something has changed on the forum web site, there isn't a confirmation email I don't think. As long as you enter the reCAPTCHA challenge correctly it creates the account and logs you in as far as I remember (my account is 3 or 4 years old though). That said the forums have been very quiet lately, maybe caused by account creation problems again.

"I have taken a look, the parts in the repository indeed have a fritzingVersion="x.y.z" in their tag. It is not present in my parts. My parts have been exported by Fritzing itself, so I haven't done any manual editing. Is there a way to make Fritzing add this fritzingVersion="x.y.z" field, or should I edit the parts with a text editor?"

I believe that this error is caused by the lack of a fritzing version field in the fzp file. FritzingCheckPart.py issues a similar warning. The cure is to edit the part .fzp file and add the version number field to the second line like this from fritzing-parts/core/part.aoz3013pi_0671c5779d4831e9bb583672ac1d7afe_1.fzp which needs to change from:

< module referenceFile="generic_ic_dip_8_300mil_hs_1.0mm_0.3mm.fzp" moduleId="aoz3013pi_0671c5779d4831e9bb583672ac1d7afe_1" > to < module referenceFile="generic_ic_dip_8_300mil_hs_1.0mm_0.3mm.fzp" moduleId="aoz3013pi_0671c5779d4831e9bb583672ac1d7afe_1" fritzingVersion="0.9.3b">

assuming you are using Fritaing 0.9.3b (note that the space after the first < and before the last > need to be removed, github takes this as xml and doesn't display it if the spaces aren't there.) That said there are a number of other errors and I don't think any of these parts will work as they stand. I grabbed the pull request from github via

cd repos/fritzing-parts

git fetch upstream pull/213/head:pr-213

in Fritzing-parts where Kjell created the pull request and then

git checkout pr-213 and git diff --name-only develop gives me the list of files in the pull request:

bins/more/Voltage regulators.fzb core/part.aoz3013pi_0671c5779d4831e9bb583672ac1d7afe_1.fzp core/part.aoz3018pi_4b4d7335497bbf379c232d88829b4eaf_1.fzp core/part.icl7660_44fc8a045bba7b5d59c3f73c1e79ff67_1.fzp core/part.icl7660_dip_a69567b07fdd8c38176b0c6f9ef2093f_1.fzp core/part.icl7662 (dip)_b0b26f8cea2efc2a43aad86f232f436b_1.fzp core/part.icl7662 (soic)_ceb3f31b17d1c702d898c345cb9aa959_1.fzp core/part.lm2574_dip_66badd838e8393d3c0dbcb8723600919_5.fzp core/part.lm2574_soic_139fde836b26224f66fa149e18beb2eb_2.fzp core/part.lm2575_f4990627fb40e38fcd573bd74d3d7e4c_2.fzp core/part.lm2575_to263_5b86049dfb531778c02a1ede4e31e375_1.fzp core/part.lm2576_af865fdbce219b6e1655050c6b30f5cb_10.fzp core/part.lm2576_to220_1dca9729a1f57f4b234b0ac8bb7693a7_3.fzp core/part.lm2577_to220_1585e1a79523015d3bb04fa3c119ed4b_1.fzp core/part.lm2577_to263_8fc1255a99f187de1e702ceedefc2a0b_1.fzp core/part.lm2596_to220_f44cb37d8d6021cdacac7094cee01f17_1.fzp core/part.lm2596_to263_2cc7b20badfc99329be65b67ba7adc35_1.fzp core/part.mic2171_to263_428b5a4f1a2a4e9650fa890d6eadc123_1.fzp core/part.mic4574_5ee57349869fd1a1da296bd15e8e1743_1.fzp core/part.mic4575_to220_606f336f4be80536825ec230d0d79b65_1.fzp core/part.mic4575_to263_e9f75c5adeaad0de490ebb2c6da6e995_1.fzp core/part.mic4576_to220_7ca7aead36ea07c96091208b0122f0cc_1.fzp core/part.mic4576_to263_98ea17460fdaa28f8d6fb0856792dbff_1.fzp core/part.st662_d8b963bc77dd4b623cd15dc5ffd12c1a_6.fzp core/part.xl4005_dd04c65a74197e075712ad6517003651_1.fzp core/part.xl4015_6b5078816154b8728cafe03e7fce04a5_1.fzp core/part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp core/part.xl6009_8044d35aa5770759ef09c66c0795aa37_5.fzp core/part.xl6019_536dee8208b446ab0afc0b18a22594dc_2.fzp svg/core/breadboard/svg.breadboard.aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_breadboard.svg svg/core/breadboard/svg.breadboard.aoz3018pi_007a70b9384772c13aaca27b3fa85f5d_1_breadboard.svg svg/core/breadboard/svg.breadboard.icl7660_a58aad07a41b1d69803eb30ea25b44eb_1_breadboard.svg svg/core/breadboard/svg.breadboard.icl7660_dip_d0473ce814b8d66f016b6259026864eb_1_breadboard.svg svg/core/breadboard/svg.breadboard.icl7662 (dip)_289c9acffd8dbce873172d95f69181e2_1_breadboard.svg svg/core/breadboard/svg.breadboard.icl7662 (soic)_c6a56f0ed37f330d1273b09419e1749e_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2574_dip_56a9867e53c62f26ffbe744f45501ea0_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2574_soic_7b40e44506a08afc013425384b13b56d_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2575_5c970be3265da15c9ac38ff8bd3b24a5_2_breadboard.svg svg/core/breadboard/svg.breadboard.lm2575_to263_52f9caf50d5b82ff5536aba9bbaa1fbe_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2576_3f752a7671beb498c6e8b42ac57f6abc_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2576_to220_907f67c5908b5437c85ae230de4ece6f_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2577_to220_b5435ea0767f6bd421d313e825749e2c_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2577_to263_cf35a2b4aa22119076f3693501fd56b6_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2596_to220_3031c9eb84e0fd397e0edb51634d8fb9_1_breadboard.svg svg/core/breadboard/svg.breadboard.lm2596_to263_8250588393d7ec92fb3f30c13a710e2b_1_breadboard.svg svg/core/breadboard/svg.breadboard.mic2171_to263_0c77fd162597c27c046109dab87d38a6_1_breadboard.svg svg/core/breadboard/svg.breadboard.mic4574_4da78c7798e22b7a20f7174fa3cb0840_1_breadboard.svg svg/core/breadboard/svg.breadboard.mic4575_to220_394d86c776ab2c64096c74e8b8c6b419_1_breadboard.svg svg/core/breadboard/svg.breadboard.mic4575_to263_a3e109c5301a7c4eefe5ad4a5555970a_1_breadboard.svg svg/core/breadboard/svg.breadboard.mic4576_to220_dd3aefdf2fb0efb1bed0a2abbbf1b0d3_1_breadboard.svg svg/core/breadboard/svg.breadboard.mic4576_to263_279e507a38755531b9612d6f86f2741e_1_breadboard.svg svg/core/breadboard/svg.breadboard.st662_d81bd34a8e087fc44299900ed7e2e4a8_1_breadboard.svg svg/core/breadboard/svg.breadboard.xl4005_36ed1593b9e56d2bb896743e6971c561_1_breadboard.svg svg/core/breadboard/svg.breadboard.xl4015_4beeae773b6e592f171f292e2355f11a_1_breadboard.svg svg/core/breadboard/svg.breadboard.xl4016_da39401d3aec6aea0d50ab1b250a8cbe_1_breadboard.svg svg/core/breadboard/svg.breadboard.xl6009_3266e3c669b0d6e3a125904685147d33_1_breadboard.svg svg/core/breadboard/svg.breadboard.xl6019_16255ad2dece8141c9680338ff6d87a7_1_breadboard.svg svg/core/icon/svg.icon.aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_icon.svg svg/core/icon/svg.icon.aoz3018pi_007a70b9384772c13aaca27b3fa85f5d_1_icon.svg svg/core/icon/svg.icon.icl7660_a58aad07a41b1d69803eb30ea25b44eb_1_icon.svg svg/core/icon/svg.icon.icl7660_dip_d0473ce814b8d66f016b6259026864eb_1_icon.svg svg/core/icon/svg.icon.icl7662 (dip)_289c9acffd8dbce873172d95f69181e2_1_icon.svg svg/core/icon/svg.icon.icl7662 (soic)_c6a56f0ed37f330d1273b09419e1749e_1_icon.svg svg/core/icon/svg.icon.lm2574_dip_56a9867e53c62f26ffbe744f45501ea0_1_icon.svg svg/core/icon/svg.icon.lm2574_soic_7b40e44506a08afc013425384b13b56d_1_icon.svg svg/core/icon/svg.icon.lm2575_5c970be3265da15c9ac38ff8bd3b24a5_2_icon.svg svg/core/icon/svg.icon.lm2575_to263_52f9caf50d5b82ff5536aba9bbaa1fbe_1_icon.svg svg/core/icon/svg.icon.lm2576_3f752a7671beb498c6e8b42ac57f6abc_1_icon.svg svg/core/icon/svg.icon.lm2576_to220_907f67c5908b5437c85ae230de4ece6f_1_icon.svg svg/core/icon/svg.icon.lm2577_to220_b5435ea0767f6bd421d313e825749e2c_1_icon.svg svg/core/icon/svg.icon.lm2577_to263_cf35a2b4aa22119076f3693501fd56b6_1_icon.svg svg/core/icon/svg.icon.lm2596_to220_3031c9eb84e0fd397e0edb51634d8fb9_1_icon.svg svg/core/icon/svg.icon.lm2596_to263_8250588393d7ec92fb3f30c13a710e2b_1_icon.svg svg/core/icon/svg.icon.mic2171_to263_0c77fd162597c27c046109dab87d38a6_1_icon.svg svg/core/icon/svg.icon.mic4574_4da78c7798e22b7a20f7174fa3cb0840_1_icon.svg svg/core/icon/svg.icon.mic4575_to220_394d86c776ab2c64096c74e8b8c6b419_1_icon.svg svg/core/icon/svg.icon.mic4575_to263_a3e109c5301a7c4eefe5ad4a5555970a_1_icon.svg svg/core/icon/svg.icon.mic4576_to220_dd3aefdf2fb0efb1bed0a2abbbf1b0d3_1_icon.svg svg/core/icon/svg.icon.mic4576_to263_279e507a38755531b9612d6f86f2741e_1_icon.svg svg/core/icon/svg.icon.st662_d81bd34a8e087fc44299900ed7e2e4a8_1_icon.svg svg/core/icon/svg.icon.xl4005_36ed1593b9e56d2bb896743e6971c561_1_icon.svg svg/core/icon/svg.icon.xl4015_4beeae773b6e592f171f292e2355f11a_1_icon.svg svg/core/icon/svg.icon.xl4016_da39401d3aec6aea0d50ab1b250a8cbe_1_icon.svg svg/core/icon/svg.icon.xl6009_3266e3c669b0d6e3a125904685147d33_1_icon.svg svg/core/icon/svg.icon.xl6019_16255ad2dece8141c9680338ff6d87a7_1_icon.svg svg/core/pcb/svg.pcb.aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_pcb.svg svg/core/pcb/svg.pcb.aoz3018pi_007a70b9384772c13aaca27b3fa85f5d_1_pcb.svg svg/core/pcb/svg.pcb.icl7660_a58aad07a41b1d69803eb30ea25b44eb_1_pcb.svg svg/core/pcb/svg.pcb.icl7660_dip_d0473ce814b8d66f016b6259026864eb_1_pcb.svg svg/core/pcb/svg.pcb.icl7662 (dip)_289c9acffd8dbce873172d95f69181e2_1_pcb.svg svg/core/pcb/svg.pcb.icl7662 (soic)_c6a56f0ed37f330d1273b09419e1749e_1_pcb.svg svg/core/pcb/svg.pcb.lm2574_dip_56a9867e53c62f26ffbe744f45501ea0_1_pcb.svg svg/core/pcb/svg.pcb.lm2574_soic_7b40e44506a08afc013425384b13b56d_1_pcb.svg svg/core/pcb/svg.pcb.lm2575_5c970be3265da15c9ac38ff8bd3b24a5_2_pcb.svg svg/core/pcb/svg.pcb.lm2575_to263_52f9caf50d5b82ff5536aba9bbaa1fbe_1_pcb.svg svg/core/pcb/svg.pcb.lm2576_3f752a7671beb498c6e8b42ac57f6abc_1_pcb.svg svg/core/pcb/svg.pcb.lm2576_to220_907f67c5908b5437c85ae230de4ece6f_1_pcb.svg svg/core/pcb/svg.pcb.lm2577_to220_b5435ea0767f6bd421d313e825749e2c_1_pcb.svg svg/core/pcb/svg.pcb.lm2577_to263_cf35a2b4aa22119076f3693501fd56b6_1_pcb.svg svg/core/pcb/svg.pcb.lm2596_to220_3031c9eb84e0fd397e0edb51634d8fb9_1_pcb.svg svg/core/pcb/svg.pcb.lm2596_to263_8250588393d7ec92fb3f30c13a710e2b_1_pcb.svg svg/core/pcb/svg.pcb.mic2171_to263_0c77fd162597c27c046109dab87d38a6_1_pcb.svg svg/core/pcb/svg.pcb.mic4574_4da78c7798e22b7a20f7174fa3cb0840_1_pcb.svg svg/core/pcb/svg.pcb.mic4575_to220_394d86c776ab2c64096c74e8b8c6b419_1_pcb.svg svg/core/pcb/svg.pcb.mic4575_to263_a3e109c5301a7c4eefe5ad4a5555970a_1_pcb.svg svg/core/pcb/svg.pcb.mic4576_to220_dd3aefdf2fb0efb1bed0a2abbbf1b0d3_1_pcb.svg svg/core/pcb/svg.pcb.mic4576_to263_279e507a38755531b9612d6f86f2741e_1_pcb.svg svg/core/pcb/svg.pcb.st662_d81bd34a8e087fc44299900ed7e2e4a8_1_pcb.svg svg/core/pcb/svg.pcb.xl4005_36ed1593b9e56d2bb896743e6971c561_1_pcb.svg svg/core/pcb/svg.pcb.xl4015_4beeae773b6e592f171f292e2355f11a_1_pcb.svg svg/core/pcb/svg.pcb.xl4016_da39401d3aec6aea0d50ab1b250a8cbe_1_pcb.svg svg/core/pcb/svg.pcb.xl6009_3266e3c669b0d6e3a125904685147d33_1_pcb.svg svg/core/pcb/svg.pcb.xl6019_16255ad2dece8141c9680338ff6d87a7_1_pcb.svg svg/core/schematic/svg.schematic.aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_schematic.svg svg/core/schematic/svg.schematic.aoz3018pi_007a70b9384772c13aaca27b3fa85f5d_1_schematic.svg svg/core/schematic/svg.schematic.icl7660_a58aad07a41b1d69803eb30ea25b44eb_1_schematic.svg svg/core/schematic/svg.schematic.icl7660_dip_d0473ce814b8d66f016b6259026864eb_1_schematic.svg svg/core/schematic/svg.schematic.icl7662 (dip)_289c9acffd8dbce873172d95f69181e2_1_schematic.svg svg/core/schematic/svg.schematic.icl7662 (soic)_c6a56f0ed37f330d1273b09419e1749e_1_schematic.svg svg/core/schematic/svg.schematic.lm2574_dip_56a9867e53c62f26ffbe744f45501ea0_1_schematic.svg svg/core/schematic/svg.schematic.lm2574_soic_7b40e44506a08afc013425384b13b56d_1_schematic.svg svg/core/schematic/svg.schematic.lm2575_5c970be3265da15c9ac38ff8bd3b24a5_2_schematic.svg svg/core/schematic/svg.schematic.lm2575_to263_52f9caf50d5b82ff5536aba9bbaa1fbe_1_schematic.svg svg/core/schematic/svg.schematic.lm2576_3f752a7671beb498c6e8b42ac57f6abc_1_schematic.svg svg/core/schematic/svg.schematic.lm2576_to220_907f67c5908b5437c85ae230de4ece6f_1_schematic.svg svg/core/schematic/svg.schematic.lm2577_to220_b5435ea0767f6bd421d313e825749e2c_1_schematic.svg svg/core/schematic/svg.schematic.lm2577_to263_cf35a2b4aa22119076f3693501fd56b6_1_schematic.svg svg/core/schematic/svg.schematic.lm2596_to220_3031c9eb84e0fd397e0edb51634d8fb9_1_schematic.svg svg/core/schematic/svg.schematic.lm2596_to263_8250588393d7ec92fb3f30c13a710e2b_1_schematic.svg svg/core/schematic/svg.schematic.mic2171_to263_0c77fd162597c27c046109dab87d38a6_1_schematic.svg svg/core/schematic/svg.schematic.mic4574_4da78c7798e22b7a20f7174fa3cb0840_1_schematic.svg svg/core/schematic/svg.schematic.mic4575_to220_394d86c776ab2c64096c74e8b8c6b419_1_schematic.svg svg/core/schematic/svg.schematic.mic4575_to263_a3e109c5301a7c4eefe5ad4a5555970a_1_schematic.svg svg/core/schematic/svg.schematic.mic4576_to220_dd3aefdf2fb0efb1bed0a2abbbf1b0d3_1_schematic.svg svg/core/schematic/svg.schematic.mic4576_to263_279e507a38755531b9612d6f86f2741e_1_schematic.svg svg/core/schematic/svg.schematic.st662_d81bd34a8e087fc44299900ed7e2e4a8_1_schematic.svg svg/core/schematic/svg.schematic.xl4005_36ed1593b9e56d2bb896743e6971c561_1_schematic.svg svg/core/schematic/svg.schematic.xl4015_4beeae773b6e592f171f292e2355f11a_1_schematic.svg svg/core/schematic/svg.schematic.xl4016_da39401d3aec6aea0d50ab1b250a8cbe_1_schematic.svg svg/core/schematic/svg.schematic.xl6009_3266e3c669b0d6e3a125904685147d33_1_schematic.svg svg/core/schematic/svg.schematic.xl6019_16255ad2dece8141c9680338ff6d87a7_1_schematic.svg

The problem here is the svg files (and the fzp files for that matter, but they will probably work) are in the wrong format. These are in the fzpz file format i.e. part.file.fzp and svg.layer.filename.svg. To work in core parts they need to be in the alternate format core/file.fzp (without the part. although that will still work) and svg/core/layerid/svgfilename.svg (not svg.layerId.svgfilename as they are). The part.aoz3013pi... file above for example has as its icon image file name :

layers image="icon/aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_icon.svg"

which is expecting an svg file at core/svg/icon/aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_icon.svg

not

svg/core/icon/svg.icon.aoz3013pi_2f301098dde4e38490ab7f8d0ae0376b_1_icon.svg

(the leading svg. needs to be removed) in the pull request. I expect the same error as the XL4016 part (because it can not find the svgs) will occur for all the parts. FritzingCheckPart.py has this to say about the XL4016 part (the first one I tried):

FritzingCheckPartw.py part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp

File 'part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp.bak'

This is a smd part as only the copper1 view is present. If you wanted a through hole part add the copper0 definition before line 53

Warning 6: File 'part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp.bak' At line 2

ReferenceFile name

'xl4015_6b5078816154b8728cafe03e7fce04a5_1.fzp'

Doesn't match fzp filename

'xl4016_d347983e432b7485814462ea48d5bf18_1.fzp'

Warning 11: File 'part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp.bak' At line 128

Type pad is not male (it usually should be)

Warning 35: File 'part.xl4016_d347983e432b7485814462ea48d5bf18_1.fzp.bak'

Connector5 doesn't exist when it must to stay in sequence

Error 15: Can not rename

'svg.icon.xl4016_a9e75dcaefc8bacd8ee095a696df6c91_1_icon.svg'

to

'svg.icon.xl4016_a9e75dcaefc8bacd8ee095a696df6c91_1_icon.svg.bak'

'svg.icon.xl4016_a9e75dcaefc8bacd8ee095a696df6c91_1_icon.svg'

No such file or directory (2)

Error 20: File 'svg.icon.xl4016_a9e75dcaefc8bacd8ee095a696df6c91_1_icon.svg'

During processing svgs from fzp, svg file doesn't exist ...

In addition the image file name in the fzp file:

icon/xl4016_a9e75dcaefc8bacd8ee095a696df6c91_1_icon.svg

does not match the file name in the repository even with the leading svg.icon removed:

svg/core/icon/svg.icon.xl4016_da39401d3aec6aea0d50ab1b250a8cbe_1_icon.svg

(and it must for the part to work) which will cause the same error as the svg isn't found. As well for core parts it has been the practice in the past to remove the _da39401d3aec6aea0d50ab1b250a8cbe portion of the file name leaving only xl4016_1_icon.svg, although some parts in core still have the unique id field. @KjellMorgenstern : which Fritzing version did you test the xl4016 part on? On my copy of 0.9.4 on Windows the part indeed complains about each of the svgs being not found (although it is calling them the fzp which is incorrect), but my seg fault fix that is in 0.9.4 causes it not to crash (you do have to hit cr, a mouse click on the dialog box doesn't work, which is also a bug). I expect 0.9.3b will segfault and corrupt the parts database as it used to though I expect (I would have to switch machines to get a copy of 0.9.3b which I haven't yet done.)

Peter

KjellMorgenstern commented 5 years ago

I have created ticket #3522 about the signup issue with the forum.

I didn't know that there is a different naming scheme for fzpz files and fzb files. Isn't fzpz just a zipped archive of a fritzing bin (fzb) and and the corresponding fzp and svg files? The file prefix should not matter, but maybe I missed some documentation about this?

.fzp.bak looks like you were working on that file with a window editor. Those editors create .bak files as backup. They should not be part of the repository. Maybe that caused some confusion?
dmantione commented 5 years ago

That is a lot of information :)

The forum indeed says it will send a confirmation e-mail after account creation, and I did a double check trying to simply login, but this is rejected. Trying the "lost password" function also does not result in an e-mail.

Regarding the technical comments:

vanepp commented 5 years ago

@KjellMorgenstern "Isn't fzpz just a zipped archive of a fritzing bin (fzb) and and the corresponding fzp and svg files? The file prefix should not matter, but maybe I missed some documentation about this?"

For the fzb files I think that is correct, but not for fzpz files. While I'm not aware of any documentation on the subject (the parts file format doc doesn't mention it for instance), the format is different. In an fzpz file the files are of the form:

part.filename.fzp svg.layerId.filename.svg

all in the same directory which makes it easier to work on and zip. The loader translates this to:

prefixdir/filename.fzp svg/prefixdir/layerid/filename.svg

to match the directory structure in core (with prefixdir above usually being "core", although "contrib" and "user" are also possible.) The "layerid/filename.svg" above is what is stored in the image portion of the fzp file for each layer, and thus if the svg is still in fzpz format (as it is in these parts) it won't match as it is looking for svg/prefixdir/layerid/filename.svg and finds svg/prefixdir/layerid/svg.layerid.filename.svg and you will get the file not found error. Changing the fzp files so the image file is svg.layerid.filename.svg would work, but is non standard, as parts editor generates the image names to match core.

@dmantione "That is a lot of information :)"

Yes, parts creation, especially with lots of parts gets complex and the parts check script tends to create lots of output which assumes you know the xml format of the files because I can't see any other way to present the data usefully. It is a problem because it takes a while to learn the format of the various files and the error output is likely mostly not useful if you aren't familiar with the file formats.

"The forum indeed says it will send a confirmation e-mail after account creation,"

It may have when I originally joined, and I just don't remember. In any case Kjell is now aware that there may be a problem, and he can fix it where I can't :-) so all should be well.

I'll only comment on those items where I can add something ...

"SMD part/copper1/copper0 is something I need to check and I will do this first"

Then this info message worked as designed. The intent is to tell you which type of part you have so if you weren't intending SMD you know you have forgotten copper0. It will toss an Error if you have only copper0 as that would be SMD on the bottom of the board and thus not correct (you can move a correctly configured part to the bottom of the board in Inspector if you need to.)

"Pads are intentionally not male, because making them male causes them to grab breadboard pins, this is not desired."

In that case the type should be "female" which does what you want, I don't think pad is a valid value, only male and female. As with many things, it isn't deadly, as I believe (without having actually read the source) that anything except "male" is taken as female. There are other parts in core with "pad" and they work fine. However for the check script, it should (but doesn't right now) error on anything but male or female, and still issue a warning for female types because they are not the norm (but not an error either). The intent is to alert you that you have an unusual configuration in case it is an error. That said, the usual reason for doing this is because there are orthogonal pins (such as the iscp pins on the arduino) that will short on a vertical row of the breadboard if you plug the arduino in to it. There is an oddness in connectivity only found lately, where you can't connect wire to wire if the part is mounted on the breadboard. Most of the time you want to be able to add a part to the breadboard and I don't see a reason why you wouldn't with these (although there may be one).

"Removing the unique ID: I can do this with a text editor if this is desired, no problem, but any edit of the part in Fritzing automatically adds the ID again, so this must be the final step when everything is finished then."

I have to admit I usually edit the underlying files directly and don't use parts editor, but that is just me. In the past the parts maintainer tended to do this (there is a script on github that will do it), as part of final QA on a part. You also need to check (or better yet, the test script should check) that the file names are unique in the current parts directory, also something the parts maintainer did as part of QA. The long term desire is to automate this as much as possible to reduce the workload on the parts maintainer. It is also laziness on my part as when the parts checker is finished, someone (probably me!) is going to need to clean up all the non compliant parts in core, so the more we can get put in correct the better.

"ReferenceFile: Fritzing does this by itself. I'm not sure what the desired situation is or what the ReferenceFile fields purpose is at all"

As far as I know it is only for user documentation, and should be the same as the input file name. I am not aware of anything inFritzing that cares what the reference files are. As with so much, there isn't any documentation that I know of, and no one of the original team left to ask. The check script (if it is in fix mode) will change them (both the fzp and svg files) to match the file name. We certainly could look at removing the fields as it would reduce the size of the files by a slight amount, after checking that nothing in the source is using for something we aren't aware of (which I doubt.)

Peter