Creating New Part: Parallax 2-Axis Joystick But SVG Error

I could not find a Fritzing part for the popular Parallax 2-Axis Joystick so I decided to try and make my own. However, when I attempt to load it into the Fritzing part editor, I get an error:

Error reading file c:/users/jonfr/AppData/Local/Temp/fritzing_pe_29854bf22d543b4095afd871ef5525e/prefix0000_29854bf22d543b0956871ef5525e_2.fzp: unable to create renderer for svg c:\users/jonfr/Documents/Fritizing/parts/svg/user/breadboard/prefix0000_29854bf22d543b0956871ef5525e_2_breadboard.svg.

The SVG export is attached:

You can also see the original .ai file and some other SVG export attempts here:

I’ve read forum posts but can’t seem to resolve the issue. Anyone know what’s up?

You did not supply the part file you were trying to load this svg image into, so I can not test directly. But. Examining the svg file shows that it does not have any physical world dimension information. Line 2 of the svg file.

<svg xmlns="" id="_2-Axis_Joystick" data-name="2-Axis Joystick" viewBox="0 0 79.2 100.8">

Something like this should work

<svg xmlns="" id="_2-Axis_Joystick" data-name="2-Axis Joystick" width="0.792in" height="1.008in" viewBox="0 0 79.2 100.8">

Because Fritzing uses the svg file in a CAD or drafting context, it REQUIRES physical dimensions, to be able to scale the graphics to match the dimension of other parts used in a sketch.

Those missing unit attributes are probably also why you had no problem uploading the svg to the forum. Without them, the forum software seems to have used the viewbox information, assuming pixel units. After adding the dimensions, Attempting to upload the file here fails. The load says it could not determine the size and suggests the file is corrupt. From previous experience, it is trying to use the width and height, but ignores the “in” units, trying to treat it as .7 by 1 pixel.

1 Like

Woohoo, that worked! Thank you so much!

I’ll post an update once I finish the full part.

Is there an open-source repo to upload this fzpz once I’m done?

The most general place to publish a part, is the “Parts Submit” category here on the forum. Various people have created parts repositories, but none I know of can have parts directly uploaded to them.

If you want to do the work to restructure the part into a “core” part, a PR to the fritzing-parts github repository could get it add. The requirements for that are a bit more stringent than just posting a fzpz file. Even here, you are likely to get feedback from more experienced part file creators about actual or potential problems with the part. There are a lot of ways to have a “broken” part that seem to work, or work, but only for some use cases. I’ll start by pointing to the FritzingCheckPart semi official part validation tool. It will point out some possible problems. A newer version is being developed, but is not ready yet.

FritzingCheckPart will make changes to files during the check, so until you are ready to let it have is own way, run the check on a copy of the part files. It does backup the originals before modifying, but I find it easier to just make a copy of the folder of files, instead of renaming files afterward, if I do not like what it does.

Great, thanks!

I finished a draft of the part. Hope it’s useful to others!

Attached here: Parallax 2-Axis Joystick.fzpz (16.7 KB)

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"/>


     <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 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.

  <p svgId="connector3" layer="copper0"/>
  <p svgId="connector3" layer="copper1"/>

The svg is easy to fix. Just replace

<g  gorn="0.1" id="copper0">


<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.

Thank you for all of this advice. Lots of work to do!