2 of the 7805 voltage regulators in core parts have the wrong pinout.

[vanepp]

It looks like 2 of the 7805 voltage regulators in core parts have the 7905 pinout rather than the 7805 pinout.

Here is a parts search for 7805 with the various versions marked as correct or incorrect (so you can identify the incorrect parts!) Here I labeled the pins as what the pin description in Fritzing shows (I for Input, G for ground and O for output) The first one has the incorrect 7905 pin order (and bit someone in the forums which is how I found this!)

I will run obsolete.py against to two broken parts (and clean them up to current parts standards since I'm updating them) and submit a pull request. I'm surprised this hasn't been caught before but I don't see any issues on the subject open or closed.

[KjellMorgenstern]

This might also solve #273

[vanepp]

Yes it looks like the to92 has the same issue. I'll add that to the pull request too.

edit:

This looks to be a complicated project. A quick scan indicates the breadboard svg needs changes, but a grep for the svg label in core turns up a whole bunch of parts that use the same svg. In addition the breadboard svg is set for bendable legs, but at least some of the parts that use it are not using bendable legs. This sort of works with some oddness, as the part gets truncated at the viewbox without the bendable leg code being invoked and the terminalId isn't present so the wire connects in the middle of the pin. The easy way out is to make minimal changes (although even that will require testing of all the affected parts I expect.) The way I would prefer to go is decide on a parts policy framework and then slowly change all of core parts to match. I started such a discussion some time ago in the forums but there hasn't been a lot of interest shown and I expect a few of us making decisions may be a poor idea. A wider selection of people considering the issue is almost certainly better. I for instance would be in favor of not sharing svgs as it makes testing changes much easier as only the current part is affected by a change. However in many places (the resistors and pots are a good example) a common svg is very desirable as then all parts with that characteristic have the same look. Any suggestions on how (and where, here the forums?) to start a discussion on a policy for parts and do you think such a policy is needed (I do because it should make automated policy enforcement easier, but that is only me)?

owner@owner-PC /cygdrive/d/repos/fritzing-parts $ grep voltage_regulator_vreg.svg core/* core/SMD_Vreg_7805.fzp: core/sparkfun-poweric-v_reg_317-sink.fzp: core/sparkfun-poweric-v_reg_317-sink.fzp: core/sparkfun-poweric-v_reg_78xx--to-220.fzp: core/sparkfun-poweric-v_reg_78xx--to-220.fzp: core/sparkfun-poweric-v_reg_78xx-sink.fzp: core/sparkfun-poweric-v_reg_78xx-sink.fzp: core/voltage_regulator_7805.fzp: core/voltage_regulator_7833.fzp: core/voltage_regulator_lm317.fzp:

[failiz]

"The way I would prefer to go is decide on a parts policy framework and then slowly change all of core parts to match. I started such a discussion some time ago in the forums but there hasn't been a lot of interest shown and I expect a few of us making decisions may be a poor idea. A wider selection of people considering the issue is almost certainly better." I think the usual collaborator and developers (basically @KjellMorgenstern , @vanepp , @mMerlin and me) should take a decision. Most of the users do not have the knowledge. And I agree that our decision should be published and enforced in core parts.

"I for instance would be in favor of not sharing svgs as it makes testing changes much easier as only the current part is affected by a change. However in many places (the resistors and pots are a good example) a common svg is very desirable as then all parts with that characteristic have the same look." I think we should reuse SVGs when it makes sense: footprint packages, standard breadboard packages (ICs, TO-92, etc.), and sch symbols (resistors, pots, capacitors, etc.). This will keep the same design and will also make easier to fix/update one file if necessary (only editing one file instead of modifying several of them). The scripts to obsolete parts should check if a change in a svg file will affect several parts and warn the user/developer to confirm that this was intended or provide an action where the post will start to use a different svg file rather than sharing a common one.

However, in this concrete case, i think we could have 2 SVGs files: one with bendable legs and one without it.

Regarding the place to keep this discussion, I prefer GitHub rather than the forum.

[KjellMorgenstern]

As a rule of thumb, if you modify the SVG of an existing part, and the SVG is shared

1. check if the modification is a fix that should be applied to all parts
2. if not, just clone the SVG and apply the fix with that new SVG.

I have suggested an automated check #368 The obsoletion script already copies the files and uses new names for the replacement svg. I'd rather add a check in a separate script "check that all parts have the required svgs", and avoid adding more complexity to the obsolete.py

These kinds of checks are usually easy to implement and deploy as github action. Please open new issues in fritzing-parts. And of course we consider similar checks to be integrated in fritzing-app.

[KjellMorgenstern]

I have also opened https://github.com/fritzing/fritzing-app/issues/4018 for a similar matter.

[mMerlin]

With my background, I prefer to share the svg files where possible. Two main reasons. Any fixes applied will fix all of the parts using the svg, and reducing the storage needed. Sharing does create a bit of extra complexity for testing (because the 'api' for the file often changes as part of the fix), but it also means that it is less likely that a part will get missed when a shared fix is applied. That covers most of the 'when it makes sense' cases. A few more sch cases are the various sensors with SPI or I2C interfaces, batteries, motors. The schematic can be the same for most of those. Should be the same for consistency.

For bendable legs, "should" there really be 2 different cases? If the rest of the graphic is the same, why should there be 2 cases? It sounds like the parts should be fixed instead, to properly use the bendable legs. For 'practical' reasons, a separate svg could be an interm solution, that gets obsoleted when the parts get caught up. Unless the bendable leg fixes are complex, that should not be needed. The parts would need touching anyway, to reference the alternate svg, so just fix it instead.

[vanepp]

"For bendable legs, "should" there really be 2 different cases? If the rest of the graphic is the same, why should there be 2 cases? It sounds like the parts should be fixed instead, to properly use the bendable legs."

First let me say I'm not a fan of bendable legs, but yes there do need to be two cases I think. A bendable legs svg has the leg outside the viewbox (with a special format of the three drawing elements, one a line one a rect and one a path I think, required.) When used shared as in these cases the graphic is truncated. As an example these two parts with the same svg but the one on the left is a correctly defined bendable leg part and the one on the right is a bendable leg svg without the legId in the fzp file (making it a none bendable leg part.) Thus the rendered svg is truncated at the viewbox and the terminalId (as the legId defiintion is out of the viewbox and thus truncated) defaults to the center of the pin which is mostly ok in this case but won't always be. If the pin definition is higher in y (which it can be without problem in the bendable leg part) the wire will connect in the middle of the body of the regulator rather than at almost the end of the pin as it does here. I think this is undesirable because it won't be obvious (unless you are familiar with parts creation and how bendable legs work) why there is a difference. In the case of shared svgs this will potentially cause problems in another part which is a maintenance headache I expect.

fixing the parts to use bendable legs is certainly an option and perhaps the best option as then all the regulators would react the same. However I would also (even though it increases the number of parts) like to have a regulator (and resistor for that matter!) part that didn't have bendable legs so the user has the choice of a bendable leg or non bendable leg part. For the resistor that gets complicated because of the special case code for dealing with the color bands, but I would find it desirable. I tend to find the bendable leg parts annoying when trying to move them around in breadboard and would prefer to have the option of an equivalent non bendable leg part. Probably a topic for the parts policy discussion!

From @failiz 's comment above

"I think the usual collaborator and developers (basically @KjellMorgenstern , @vanepp , @mMerlin and me) should take a decision. Most of the users do not have the knowledge. And I agree that our decision should be published and enforced in core parts." ... "Regarding the place to keep this discussion, I prefer GitHub rather than the forum." I think I will open a new issue to continue the discussion of

I think I will open a new issue for the discussion of parts policy. This one needs to remain open, as these parts need to be fixed once we have a policy in place and figure out how to fix them!

edit

I opened #369 to continue this discussion in its own issue. Feel free to add cross references to other discussions that have interest in this same issue.