The source files are on GitHub .
Part preview
Download
AMS1777_5V_regulator_module.fzpz (17.5 KB)
Welcome to the Forum. I feed the files for that part through FritzingCheckPart and did a quick test with it. From that, here are some things to improve.
Fritzing does not handle units on font sizes. The “px” needs to be removed from the attributes in the breadboard svg (4 places), schematic svg (10 places).
White still works, but the new convention is for the pcb silk screen content to use black stroke and fill.
The copper0 group (layer) should be inside of the copper1 layer, not the other way around.
There should be a version entry in the part definition.
terminalId attributes are defined for breadboard and schematic views of each of the connectors, but the corresponding elements do not exist in the svg files. The breadboard view does not need terminalId attributes. See below for schematic.
The connection points (pin) in the svg view are rect (rectangle) graphic elements. That is what should have the terminalId values for the id. The svgId values defined in the fzp should be on line elements (0.1 inch long) instead, that have one end at the rectangle. That allows starting or ending a wire anywhere on that line, and having it automatically snap to the rectangle. The rectangle can be invisible (stroke and fill = none).
I also noticed that you have linearGradient entries defined in each of the svg files. The “Tiny” version Svg that Fritzing uses does not support that, so it will be ignored.
Fritzing “prefers” to use attribute values for the svg element properties. There are places where using the css style does not work.
You left a white space border on 2 sides of the schematic svg image. That is not needed. When parts are close, that can make it difficult to select the one you want.
I “expect” that the input and output ground pins are connected together internally in the board. If so, the part should have a bus entry showing that, so that Fritzing knows that a wire connected to one is really (electrically) connected to both.
EDIT:
I see that there “is” a version element in the definition. I’ll have to look closer to see why FritzingCheckPart said there wasn’t.
EDIT2:
Ah! The complaint was about a missing “Fritzing” version, not the “Part” version.
Here is a version of the part with reported issues cleaned up. I also changed the label to just “V”, since this is electrically a voltage source. I adjusted the properties family to “Voltage Regulator”, so it is included in the drop down with other voltage regulators, and adjusted other properties to be more consistent with them. I ran the individual svg files through a process to clean up unneeded (for Fritzing) elements and attributes. The schematic view I did a bit more manual editing, to get rid of extra transforms, and adjust the svgId and terminalID tags. Visually it should work the same as before, with the addition of the ground bus, so click/hold on one of the gnd connections (any view) will highlight the other (in yellow).
AMS1777_5V_regulator_module.fzpz (9.2 KB)
If I had been creating this from scratch, I would not have created the custom schematic view. This works like a standard 3 pin voltage regulator, so the same 3 terminal representation could be used for the schematic. The schematic does not need the extra pin or text. Setting and turning on the part number in the label would be enough.
Looking at the images, I am not sure that the PCB pin layout is correct. The part/module has male pins coming out of the top. With the current pcb layout, that will only line up if the part is mounted on the bottom of the pcb. Unless the header pins extend through bottom enough to solder onto the pcb. If the board is mounted on a pcb, but the connections are made using jumpers to the header pins, then the pcb pads would not be used, and do not belong on the pcb view for the part.
Thanks for the advice and the a cleaned version.
Based on the mechanism of Inkscape, it makes some issues of the exported SVG.
Fritzing does not handle units on font sizes. The “px” needs to be removed from the attributes in the breadboard svg (4 places), schematic svg (10 places).
Inkscape handles text by the <text> and <tspan> elements. It always puts text inside a <tspan>, and auto coverts the value of font size to “px”.
The copper0 group (layer) should be inside of the copper1 layer, not the other way around.
In the " Fritzing’s Graphic Templates", I see that the copper0 group wraps the copper1 group, maybe it is wrong?
Fritzing “prefers” to use attribute values for the svg element properties. There are places where using the css style does not work.
There is an export option “Optimized SVG” that can cleaup some uselss content and convert some css styles into attributes, but some css styles are still left in the style attribute.
I “ expect ” that the input and output ground pins are connected together internally in the board. If so, the part should have a bus entry showing that, so that Fritzing knows that a wire connected to one is really (electrically) connected to both.
You are right, ground pins are connected together.
Looking at the images, I am not sure that the PCB pin layout is correct. The part/module has male pins coming out of the top. With the current pcb layout, that will only line up if the part is mounted on the bottom of the pcb. Unless the header pins extend through bottom enough to solder onto the pcb. If the board is mounted on a pcb, but the connections are made using jumpers to the header pins, then the pcb pads would not be used, and do not belong on the pcb view for the part.
It intended for simulate on breadboards and schematics, so a complete PCB view is not currently used.
Origianl picture of the module
It looks like creating a Fritzing part view with Inkscape requires some manual (?) post-processing.
Is there a more recommended SVG editing software?
Yes. I do not like what the default setup of Inkscape does to the files.
I don’t THINK that is true, if all that is done is open a file (that does not have the px units) and save as optimized svg. I think the px only gets added if the text element/object is manipulated in some way in Inkscape. See my steps below.
I have not looked that close at the template files. There is a good chance that it is wrong there.
That is what I based my own cleanup on, with a bit of manual editing to catch a few more things. SVG files are just a form of XML, which is text. If you understand the structure, they can be edited with a text editor. Especially one that is xml aware.
The output from Inkscape will typically work, but it does tend to be not quit compatbile with Fritinzing. Which is partly the Fritzing code’s fault. Friting use the “Tiny” subset of the svg specification, and (I strongly suspect) does not implement it completely. So there are work-arounds for some things. There is no real recommended image editing alternative. Unless you are techy enough to (like me) create the content with hand built text files. That is slow, but works pretty good for schematic and pcb views. Most breadboard and icon images are too graphical to be done easily that way. Adobe Illustrator is an alternative, but it has its on view on what should be in the svg files, that is not quite what works best with Fritzting. Other editors are possible. The image editor configuration options, and the style of editing can have a large impact on how Fritzing Clean the result is. There is no one/best way that I know of.
The FritzingCheckPart tool, as well as reporting the issues I described, generates reformated and somewhat cleaned up files. It removes the px from the font sizes, and switches silkscreen to black among other things. I do not really like the way it reformats the xml/svg content (fzp is also xml) either though. My typical process for getting a mostly cleaned up, working svg image for Fritzing (from existing svg content), is to run it through Inkscape using the save as optimized svg with a careful selection of options, then run the output of that though FritzingCheckPart, then through Inkscape and optimized svg again. That is in addition to resolving (or deciding not to resolve) things that FritzingCheckPart complains about. I have my own notes about some extra things that I usually clean up with a bulk text edit between one or more of the stages. Effectively a series of search and replace commands that could probably be done with separate script. Or later added to the FritzingCheckPart python code.
Once the pieces of the part are all supposed to be ready, run it through FritzingCheckPart part again (throwing away the copies it reformats), to verify that only expected messages show up after the cleanup. That is, that it stayed clean, and the process did not introduce new issues.
There are some ways to minimize the pcb view, and still keep it useful. One option is to have a simple header for the pcb view, which could be connected to the actual part by a cable. That, or a few variations, would allow Fritzing to maintain the the ground and power connections if the module is used in a project that needs a pcb. A PCB view that is wrong is worse than none at all.