Hello, I’m new to this community and as a little “getting-to-know-you” present I posted this simple part I’ve made for a project of mine. It’s a 74HC237 demultiplexer. I hope it’ll be useful for other people too. 
74HC237.fzpz (7.1 KB)
1 Like
Welcome,
I ran the contents of that part file through FritzingCheckPart. Here is a summary of what it reported, and what I noticed doing a manual inspection and smoke test in Fritzing.
The new convention is to use black graphics for pcb silkscreen, instead of white. Fritzing automatically converts (and so does the FritzingPartsCheck tool), but for future reference, black is preferred for the silkscreen of pcb svg files.
The fzp part definition file does not have a “fritzingVersion” attribute for the module element. The handling of some part details has changed over time (older versions of Fritzing), and the value of the version is used to choose which way certain things are interpreted. A value of “0.9.4b” should tell Fritzing to use the (currently) latest rules. Fritzing Parts Editor automatically fills in the full version number. When manually creating parts files, a shorten version is good enough.
All of the schematic view connector terminal elements have a zero width, which means they are not selectable in Inkscape. They should have a small width and height (usually a square) that is centered around the connector snap point.
The generic IC part is using the older convention or 0.2 inch long connector pin lines in the schematic. The new convention is to use 0.1 inch connector pin lines.
The schematic graphic matches the physical chip pin layout, which is all the the generic chip generation code can do. It does not have any other information. Since schematic is a logical view, matching closer to the functional diagram in the datasheet might be better. Including the internal latch and decoder blocks would make the graphic larger than needed, but the layout of the connection pins is a good place to start. Just add VCC and GND at the top and bottom. I would also move the ‘Not LE’ pin from the top to the left side.
Since this is a standard (discrete) chip, the usual convention is for the label to be “U”, instead of “IC”.
Wires to the schematic view connectors are snapping to the middle of the pin lines, instead of the ends. That is usually because terminalID elements are missing from the svg file, or not defined in the fzp file. However both of those look correct, as far as I can see. As noted above, the terminal elements have zero widths, which causes problems with Inkscape when trying to edit the file. Previous information was that Fritzing would still use it with zero width, but some testing with this file shows that the terminal ‘rect’ elements are being ignored. Changing the width="0" to width="1" got it working.
Another unusual (at least not needed) item, is the connector pin elements are being created as invisible (no stroke, no fill) rect elements on top of a visible line element. The rect element is not needed. Moving the id="connector«number»pin" attribute from the rect to the line element does the same thing.
<line stroke-width="9.7222" y1="100" y2="100" x1="4.8611" x2="200" stroke="#787878" stroke-linecap="round" fill="none" stroke-linejoin="round" id="connector0pin" />
instead of
<line stroke-width="9.7222" y1="100" y2="100" x1="4.8611" x2="200" stroke="#787878" stroke-linecap="round" fill="none" stroke-linejoin="round" />
<rect connectorName="A0" stroke-width="0" id="connector0pin" gorn="0.2.3" width="200" fill="none" x="0" y="95.1389" height="9.7222"/>
For accurate pin labeling, the datasheet shows that it should be “not” LE and “not” E1. Those are negated (active low) inputs. The ‘NOT’ bar could be added as a separate line or string.
The existing pin name labels seem to be offset up a little, instead of being centered on the connector pin lines.
@vanepp It SEEMS that the zero width terminal graphics are more of a problem than just not being able to select in Inkscape.
What else does it break? Inkscape is the only thing I’m aware of … Since parts factory uses creates it, it seems the original developers weren’t aware of a problem either (or were aware and hadn’t gotten to fixing it yet, nor documenting the issue!)
Peter
In the example part from the OP, the wires are snapping to the middle of the schematic pins, instead of to where the connector«»terminal points. As far as I can tell, all of the pieces exist, and the definition uses them, but it is not working. To get it to work, the ONLY thing I changed, was width=“0” to width=“1” on (for testing) the connector0terminal element.
So it appears that Fritzing does not like the zero width rect terminalId either. The symptom is that it acts the same as if the terminal element does not exist.
In my particular environment of course: Fedora and Fritzing 0.9.4b
Huh! Appears to work correctly on 0.9.5 on Windows 10 (and I don’t think there are any changes in 0.9.5 that would affect this):
I’ll have to try it on Linux, I don’t think I have ever done so.
Peter
For this particular test, I was using the flatpak release of Fritzing, and I ran it using a script that includes an environment override flag to prevent (apparently) wayland related problems. I’ll add to my list to do some tests with other combinations I have available.
flatpak run \
--env=QT_QPA_PLATFORM=xcb \
org.fritzing.Fritzing \
--parts "$HOME/Documents/data_files/fritzing-parts" "$@" &
% flatpak info org.fritzing.Fritzing
Fritzing - Electronic Design Tool
ID: org.fritzing.Fritzing
Ref: app/org.fritzing.Fritzing/x86_64/stable
Arch: x86_64
Branch: stable
Version: 0.9.4b
License: GPL-3.0+
Origin: flathub
Collection: org.flathub.Stable
Installation: user
Installed: 185.7 MB
Runtime: org.kde.Platform/x86_64/5.15
Sdk: org.kde.Sdk/x86_64/5.15
Commit: 39be337644be79e834ccd085325bf491d6a715d9135634af251346a019410ebf
Parent: c595162a1d06f01eab9b66092c7ca68518974b9887295cd59950c439bfba3a72
Subject: Replace screenshots with valid links (84342f15)
Date: 2020-11-18 20:57:37 +0000
For me it also works on Ubuntu 18.04 (but with Fritzing 0.9.3b since I don’t have 0.9.4 on that machine yet!)
Peter