I ran that part through FritzingCheckPart as well as manual inspection of files and in Fritzing. There are a lot of problems. I must recommend not using this part in its current form.
The first thing FritzingCheckPart complained about is an invalid character in the meta data (fzp file). Line 25 has a nul (binary zero) character after âSpecs:â. I Deleted that and restarted. Here is a summary of what it reported, and what I noticed doing a manual inspection and smoke test in Fritzing (after recreating without the nul).
There are âpxâ units on font-size attributes in the schematic view svg files that Fritzing is known to not handle well. The text size can change from what was intended. Fritzing wants just numbers, without units. Using âpxâ units is valid for the svg format specification, but Fritzing does not handle it.
Connector2 had a terminalId attribute for breadboardView in the meta data. Typically, terminalId is not needed for breadboard view. Only for schematic. The specified terminalId does not actually exist in the breadboard svg. If it is defined, it should exist. Here, just remove that attribute from the meta data.
<p svgId="connector2" layer="breadboard" terminalId="connector2terminal"/>
to
<p svgId="connector2" layer="breadboard"/>
Typically, the id attribute for connectors is âconnectorâ plus a sequence number. You have that. However, the svgId attributes for the view entries is typically the connector id with a suffix of pin or pad (for smb pcb view). ie connector3pin. The id on the svg element needs to match. What you have works, but is unusual, and could cause confusion when mixed with terminalId attributes (see below).
The connector meta data does not include terminalId attributes for the schematic view. These are needed so that Fritzing correctly connects (snaps) wires to the ends of the connector lines. Without the terminalId (and matching svg element), Fritzing will connect to the center point of the svgId element. The terminalId is typically the connector id plus âterminalâ. ie connector3terminal.
The "Parallax 2-Axis " text in the schematic view has a font-family of âDroidDroidSansâ instead of âDroidSansâ. Side note: that string has a space at the end.
The meta data can (and typically should) include a <url></url> element. Something like https://www.parallax.com/product/2-axis-joystick/ seems good.
This part, both the meta data and pcb svg, have been created for an smd. This actually connects using tht pins. All of the connectors should also have a copper1 layerId for the pcb view entries.
<pcbView>
<p svgId="connector3" layer="copper0"/>
<p svgId="connector3" layer="copper1"/>
</pcbView>
The svg is easy to fix. Just replace
<g gorn="0.1" id="copper0">
with
<g id="copper1"><g id="copper0">
and the matching </g> with </g></g>. The gorn attribute is created by the svg editor, and is not needed. With how clean the structure of the rest of that svg looks, I assume it has been cleaned up. Either manually or using an optimization tool. Although I wonder why the coordinates are 14 decimal places. Conversion from inches to millimeters? If so, using âinâ instead of âmmâ as the units will simplify that a lot. I assume that the spacing will be exact multiples of 0.1 in, so width, height, and viewBox similar to the breadboard svg should work. After rescaling all of the coordinates to match.
The pcb view svg includes an embedded bitmap image. Is that really needed?
Your connectors are numbered from 2 through 9. That should be 0 though 7. Which affects the meta data and all svg files (except icon).
The part image from the url (above) shows that the mounting holes are plated through. Are they electrically connected to the ground pins? If so, they should be connectors as well.
The parts includes 2 explicit gnd pins. Those are very likely electrically connected together. If so, the part meta data should have a <buses></buses> entry showing which connectors are tied together. The same for the Vcc pins, if they are connected. With the description on the web page, about voltage versus resistive outputs, that is not quite as likely. This also applies to the the doubled L/R and U/D output pins. If wired together, there should be a <bus></bus> entry for them.
The breadboard svg does not include an id to match the breadboard layer specified in the meta data. Only content in that layer in the svg file will be exported by Fritzing. It should be a group that wraps around all of the graphical content. The breadboard svg does not look as cleaned up as the pcb. Lots of class, transform, and empty wrapper group attributes and elements. Symptoms seen using (at least) Inkscape editor.
There are multiple elements in the pcb svg with an id matching the svgId from the fzp meta data. Id elements should be unique. There are also elements in the pcb files with an id ending in âterminalâ. TermininalId is not normally used for pcb view, and the fzp file does not define any. Both of those may have been cause by copy/paste from an existing svg drawing, then duplicating elements. The id got copied and duplicated along with the graphics.
The pcb svg file and meta data do not include any silkscreen layer. Is that what the embedded image is supposed to be? For Fritzing to use it properly, it needs to be wrapped in a âsilkscreenâ layer, and outsided of the copper layers. That âunknownâ layerId in the pcbView image meta should probably be âsilkscreenâ, and with above information, should include a âcopper1â layer as well.
The schematic image is too big. The pins should be 0.1 inch long, pins in a group should be 0.1 inch appart, and all pins should be even multiples of 0.1 in from every other connector pin. The 0.1" and 1.0" labels and dimension bars do not belong in schematic view. That view is for a logical view of the part. It does not need any physical dimension labeling, and does not need to match the physical size in the breadboard and pcb view. The part and pin text should be much smaller, and the part shrunk around it. With the bus entries already mentioned, this (can use but) does not need duplicate entries for those pins. In its simplest form, (if the Vcc pins are tied together) this could show only 4 pins. Gnd, Vcc, L/R, U/D.
Including âParallax 2-Axis Joystickâ in the part makes it more specific than is really needed. The âpart #â property could be set to that (when desired, by the user), and shown as part of the label when that detail is needed. While allowing it to be easily used for other joysticks with similar features. Search for âjoystickâ in the parts window for examples. Not all of those are âgoodâ examples. Some are not following all of the conventions either.
The existing meta data does not include a <label></label> entry. Because of that, Friting inspector (and part label) show this as âPart1â (Part2 for a second copy). Supplying a label allows that to be more descriptive, and will keep the labelling separate from any other parts that (either explicitly or by default) use a âPartâ label. âJâ is not good, since it is used for jumpers. Several of the existing joysticks use âUâ, which is actually a generic label for ICs.
The pins on the pcb view do not seem to line up with spacing shown by the dimension information on the schematic view. The pairs of pins are over 0.2 inch from each other. One of the pins is visibly not lined up with its pair. Some of the pins show as circles, some as squares or rectangles. To get Fritzing to create a drill hole for through hole pins, the svgId element must be a circle. Additional graphics can be added around (overlapping, but not covering) that to create oblong, rectangular or square pads. There are visual differences between the graphics for the pads. It looks like maybe paths were used to create the pad outline, but it was not filled in. Fritzing has specific rules it uses to determine what is copper. This does not seem to follow those rules.
