WeMos D1 Mini Lite Manufacturer Website / Spec
Fritzing Part:
WeMos_D1_Mini_Lite_v1.fzpz (22.4 KB)
SVG:
WeMos-D1-mini-Lite_breadboard_v2.svg
WeMos-D1-mini_Lite_pcb.svg
WeMos-D1-mini_Lite_pcb.svg
I ran that part through FritzingCheckPart, did a quick manual inspection of the part, and a ‘smoke test’ in Fritzing. Here is a summary of what I found.
There are ‘px’ units on font-size attributes in the schematic view svg file that Fritzing is known to not handle well. The text size can change from what was intended. Fritzing wants just numbers, without units.
Normally the connector id attribute values in the fzp file are “connector” + a number (starting a “0”), with the view specific svgId and terminalId attribute values being “connector” + same number + “pin”, “pad”, or “terminal”. The connector id values here are matching the textual name values instead.
The “breadboard” and “schematic” layerIds specified in the fzp part definition do not exist in the matching svg images. This will “appear” to work in Fritzing, but exporting a sketch to an svg image will not include the part. The “breadboard” and “schematic” ids should be added to the first/outer wrapper group element.
The label for the part should be something short like ‘Mod’. It should not be a duplicate of the title. This is used by Fritzing as the default prefix, with a number appended, to create a unique identifier in sketches. To tell part instances apart where there are multiple copies in the same document.
The pins in schematic view should be 0.1 inch long, not 0.2 inch.
I ran the new version of the part through FritzingCheckPart. Here is a summary of what it reported, plus what manual inspection and testing noticed.
It should not be an ‘error’, but the convention is for the id attribute of connector elements in the fzp (part definition) file to have values of “connector” + number. With the number starting a zero and increasing. The associated elements in the svg files normally use that id as a prefix, and append one of “pin”, “pad”, “terminal”, depending on the context and developer preference. The svg files here contain elements that match that pattern, but the connector id attributes in the fzp file have values that match the connector name and description. That is not what the id attribute is for. Because of that, FCP complains that the svgID and terminalId values for every connector, for every view, do not match the id of the connector it is included it. Using the convention allows FCP to check for some simple typos, where the wrong graphic element was being referenced for a connector. It is fairly easy to get one wrong, cause of copy and paste operations when adding connectors.
I believe (not confirmed) that Fritzing also uses the number from that to display a pin number in the hover information. With those ids, Fritzing is getting odd and some duplicate pin numbers.
In the schematic view, the connector pin graphics should be 0.1 inch long. They used to be 0.2 inch long, now they seem to be about 0.05 inch long. The “total” pin graphics are 0.1 inch long, but the portion that highlights, and that is clickable to connect a wire to, is only about half that.
The fzp file references “connector4terminal” for the “d6” connector, but it does not exist in the schematic svg file. The effect of that, is that wires connected to the D6 pin snap to the middle, not the end.
The label for the part is still the long (copy of) the part title. It should be something generic and very short, like “Mod”, since Fritzing is automatically going to append a number, and use the whole result as the label in all of the views.
The name of the fzp file needs to start with “part.”, but the fzpz complete part file does not.
I shortened the label and started to rename the connectors to avoid the error messages of the script. But when i renamed the connectors i noticed, that Fritzing shows only the first part of the name and it is impossible to make the column wider -see the picture:
I don’t like that and it is probably the reason why mcauser renamed them in the template i used to create the light version of the D1 Mini https://github.com/mcauser/Fritzing-Part-WeMos-D1-Mini
I could not find the problem with d6 (connector4terminal) you described. I used the part in Fritzing 0.9.3 and 0.9.4 without problems.
WeMos_D1_Mini_Lite_v3.fzpz (22.9 KB)
I was looking at, and describing, the content of the (generated) .fzp file. A little exploration in Parts Editor using your part, plus another normal part finds that there is no way (in Parts Editor) to change the connector ids. So the original adjustment must have been done outside of Parts Editor, by editing the .fzp file. Possibly from before the Parts Editor existed, when part editing HAD to be done manually.
Here is a copy of your part with the connector ids back in the normal pattern. I also removed the empty nested wrapper group elements in the svg files, fixed a font size issue in the pcb svg, and renamed the internal files to remove the “part_” prefix everywhere but the one place it was needed.
The latest version you provided did not have any problem with the d6 connector, but it did still have the short connector graphics. I was going to just fix that, but when I got in, found it easier to just recreate the schematic from scratch. It is now a bit smaller as well.
WeMos_D1_Mini_Lite_v4.fzpz (13.3 KB)
I have added the WeMos D1 Mini parts from the core parts library to the list for some cleanup. They have most of the same Issues. This “lite” part could probably be added to the core at the same time that gets done.
Thank you microMerlin!
I looked into the SVG files and understand now how it should be done. For instance i learned howto define the connection points in the schematic SVG file.
I re-arranged the elements in the schematic SVG file a little bit with a text editor to put the pins in the background. So that the round, lighter colored ends are below the frame. I think that looks a little bit better.
WeMos_D1_Mini_Lite_v5.fzpz (13.3 KB)