search

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

Standardize the part labels #365

Open failiz opened 1 year ago

failiz commented 1 year ago

We should have a document that specifies how a part type should be referenced (label in Fritzing). Right now the parts have different labels depending on who created them. For example, there are integrated circuits with IC and U labels. There are motors with M labels but there are a few parts that also use the M label (e.g., FC-51-IR-Sensor, I guess that there are). I just realized this when in my course I discovered some students confused (they thought that the motor I had in my slides was their IR sensor as they had the same name, "M1" ).

Some useful links: https://en.wikipedia.org/wiki/Reference_designator https://www.eevblog.com/forum/eda/reference-designator-for-components/ Kicad convention: https://klc.kicad.org/symbol/s6/s6.1/

Could we start defining this? I would like to fix the IR sensor, but I want to avoid every person taking their own standard. I would suggest A for assemblies, as discussed in https://forum.fritzing.org/t/suggestions-for-additional-documentation/15135/2 . In fact, my pull request of the H bridge uses A as a label, but it is the only part with that label...

I would recommend starting from Kikad convention and adapting it slightly to minimize the changes in Fritzing. For example, keeping LED as the designator for LEDs.

vanepp commented 1 year ago

"but there are a few parts that also use the M label (e.g., FC-51-IR-Sensor, I guess that there are). "

That is my fault, I started using Mod and then M for module for parts and someone added the fc-51 to core parts. These days I'm using A (for assembly) from the first reference above. The only good thing is that not many of my parts have made core due to my difficulties with github. I agree that the Kicad values would be a good start with some changes. I'm not sure how (or if we need!) to get consensus on the changes, as the referenced discussion in the forums has attracted very little interest. Once we get (or decide we don't need) consensus, I expect an update to the part file format should be made preferably with many more fields (such as version for instance) with suggested values added. There may soon be another part with the A in the label (there are also a bunch in core with no label field with default to part which is quite annoying!) as I lately submitted (mostly because it is a new part and thus I didn't have to try and change anything after submitting the pull request on github!) the replacement for the Dual_VNH2SP30_Motor_Driver which is no longer made As you know that update is made but isn't currently submitted to core because github defeated me yet again and I'm not inclined to try further.

KjellMorgenstern commented 1 year ago

I think we should add a RefDes tag, in addition to the label tag. The RefDes would then use the KiCad conventions. I think Fritzing won't complain if you just add RefDes tags to parts.

How this Reference Designator would then be used is the bigger question.

  1. In certain more technical contexts, like netlist export or ipc-d-356 export, naming subnets, or connectors, the RefDes tag would always get preference. If I am correct, in IPC-D-356, we only have two characters for the designator, so Fritzing labels can not really be used there anyway.

  2. Fritzing could complain, even with link to a help section that explains the RefDes, if a part without RefDes is added.

  3. Can the RefDes be edited? Fritzing automatically sets and numbers labels, but the user can edit them freely. Should the same be possible for reference designators ? Should users be able to edit it freely, or maybe just limited to unused numbers (e.g. you can change R1 to R3, but not to 'RES1')

  4. Will Fritzing labels be used by default? Or should there be a setting in the preferences to determine which are displayed by default.

  5. Another option: Always use the RefDes if it exists, with Fritzing exceptions, that are more friendly for beginners.

    • LED instead of D for LEDs
    • MIC instead of MK
    • IC instead of U
    • SPKR instead of LS
    • XTAL instead of Y
    • ...

  6. Other variant: Fritzing still uses label by default, with fallback for RefDes. We could then add RefDes to all parts. For some, like LED we keep the label. For others, where the label is not that helpful, we can just remove it from the part, so the more standardized RefDes would be used. This would allow for some kind of fluent migration, we don't need to implement much. And still allow every part designer to set a proper RefDes, even if they feel the part needs a more telling label.

failiz commented 1 year ago

I would prefer not to add a new property to the file format as I do not see any advantage on doing that. The label is just being used as a reference designator, the only problem is that different people used different standards for it. I would prefer to just keep the label property as a designator by fixing the parts in the core. It is a quick change as we do not need to obsolete the parts. The only thing would be to agree on some rules so we all use the same standard and create a test to check parts that are added to the repository (they should use our standard). People would still be able to create their own parts with their preferred designators if they wish, but the ones in the core should use a homogeneous standard.

I agree that we should also have something friendly (e.g., LED instead of D). If this is not valid in IPC-D-356, we can simply replace "LED" with "D" when exporting to a IPC-D-356 netlist. This works if all parts in the core are homogenous. If there are user parts that are not valid, we could generate a message and inform the user (or ask for another designator to replace each invalid designator).

That is my fault, I started using Mod and then M for module for parts and someone added the fc-51 to core parts. No problem at all. Easy to fix if we agree on a standard. It is better to have a part in Fritzing with a small mistake that do not have it.