Parts help template

KjellM · February 28, 2024, 5:04pm

Hi!

Since this category is mostly used for requesting Fritzing parts, I added a template for this. The idea is to guide users in providing the information that we usually need for a Fritzing part, and also to encourage preparing some basic research and including previous work.

Below is the first version of the template. Should we add or remove anything?

Name of the part
Name

Previous work, similar parts
In case there are similar Fritzing parts, or you already started work, please link it here.

Top view
This picture shows the part from above, so that is easy to see were connectors should go, and which diameter they have.

Foto or vector graphic, no links here please.

Datasheet
The official documentation of the part manufacture is linked here:

Please add a link to PDF of the manufacturers datasheet

Type
I did not read this
Breakout board, sub assembly, plug in module (A)
Antenna (AE)
Battery (BT)
Capacitor (C)
Diode (D)
Display (DS)
Fuse (F)
Hardware , mounting screws, etc. (H)
Jack, fixed part of a connector pair, header (J)
Relay (K)
Inductor, Coil, Ferrite bead (L)
Loudspeaker, Buzzer (LS)
Motor (M)
Microphone (MK)
Plug, moveable part of a connector pair (P)
Transistor (Q)
Resistor (R)
Thermistor (RT)
Varistor (RV)
Switch (S)
Transformer (T)
Integrated Circuit (IC)
Crystal, Oscillator (Y)
Zender diode (Z)
Other (please specifiy)

Footprint
E.g. SOT23-5 , TO-220.
This usually does not apply to breakout boards.

rcarteraz · February 28, 2024, 8:58pm

I like this. I requested for the first time yesterday and I looked to see if there was a formal process and did not see one so just mimicked other successful requests as best as possible.

UniquePete · February 29, 2024, 12:24am

Maybe this is drifting slightly off the primary intent of this thread, but I’d also be really happy if there were a few more things in there, that are maybe to be ‘completed by the developer’, to help identify a consistent way of choosing appropriate values for things like the label, variant and package for a part. That information would help those who want to have a go themselves, if not those who are simply requesting a part (and may not really care, or be in a position to choose how those parameters are set).

vanepp · February 29, 2024, 1:55am

There is a discussion about that subject over on github going on (very slowly, there hasn’t been an update since last August, I am as guilty as anyone for not poking at this …) among some of us here:

github.com/fritzing/fritzing-parts

Parts policy discussion

opened 08:01PM - 24 Mar 23 UTC

vanepp

This is a continuation (with a better topic name) from #367 . The intent is to m…odify and possibly write new standards for parts. We have the part file format document https://github.com/fritzing/fritzing-app/wiki/2.1-Part-file-format and the graphics standards https://fritzing.org/fritzings-graphic-standards both of which may need updates as part of this discussion, but which provide the basis for this discussion. @KjellMorgenstern @mMerlin @failiz where suggested in #367 as people who need to be involved, but I expect anyone else that is interested should also be welcome to join in. My broad outline is to get a parts policy in place that allows automated checking of parts and consistency of parts (at least those included in core parts) so schematic as one instance looks the same and interoperates well with other parts. The longer term goal is, once a policy is in place, to start a project to update the parts in core parts to meet the new standard. (that is likely to be a lot of work, but requires the policy to be in place to allow it!) That would also allow the automated checking of parts that are submitted to core parts to make sure they meet the standards. However it leaves the user able to create custom parts that don't meet the standards (either due to time constraints or lack of need of some views) for their personal use which has been one objection raised in past discussions on this topic. Another topic is the layout of the repository as discussed in #4018 . Documenting the format of the .fzpz file and its association / conversion to the repository format should be done. I am not aware of any documentation on the format of the .fzpz file existing (pointers to anything I have missed are welcome!) Documentation on each field in the fzp file would be useful. For instance the version field is often set to 4 where I think it should start at 1 for a new part and increase by one for each new version of the part. My update to the obsolete.py script available in #347 addresses that by setting the version field to 1 if there isn't one already or increasing the current version field by 1 if there is one.. Issue #365 to standardize the parts labels (which affects the label field in the fzp file) also enters in to this discussion as I think it is desirable to standardize the label field in parts. File name conventions for fzp and svg files are also an issue that needs to come up. I would prefer that the version number appear in the files so for the first version of the part the fzp and svg files end in _1 such as part.fc-51_1.fzp for the first version of a part. One question would be is there a need to add a guid field (a globally unique identifier) to the file name as parts editor currently does when editing parts? As noted I think we need to update the part file format document to specify all the fields in a fzp file along with their suggested initial value and what they relate to in other files. As an example ``` <breadboardView> <layers image="breadboard/fc-51_breadboard.svg"> <layer layerId="breadboard"/> </layers> </breadboardView> ``` The layerId field here needs to match the group id (in both case and spelling) in the svg file specified in the image file a couple of lines above it. Documenting the special case properties and what they do would be good. An example is all the special formats for a breadboard such as ``` <module moduleId="Breadboard-test-ModuleID" fritzingVersion="0.12.34"> ``` where the trailing ModuleID in the moduleId field suppresses rotation by 45degrees in a breadboard ``` <property name="family">Breadboard</property> <property name="size">full+ test</property> ``` the family needs to be Breadboard with the size property selecting between the possibilities (and that the combination of family and size need to be unique!) ``` <breadboardView> <layers image="breadboard/breadboard2.svg"> <layer layerId="breadboardbreadboard"/> </layers> </breadboardView> ``` and the breadboard layerId "breadboardbreaddboard" trips special code that allows the part to move down to the same level as the breadboards. This is used by the Arduinos for instance (which are otherwise not a breadboard) I think to allow shields to be mounted above them. That will probably do to start this discussion rolling I hope!

which is probably a better place for this particular discussion. It is a complex subject and likely to take a long time to settle out to a place where progress can be made.

Peter