VNH5019 motor driver.fzpz (982.1 KB)
Always good to have more people creating parts. It can take awhile to learn all of the idiosyncrasies of Fritzing parts and Inkscape. Here is information to help that along.
I ran that part through FritzingCheckPart. Below is a summary of what it reported, but first some general notes from looking at the part.
The part file seems to to match the Pololu VNH5019 Motor Driver Carrier. There is also (at least) a VNH5019 motor driver shield available. The part title and properties should reflect that, to differentiate if someone has a part file for the shield. The part family should not be “Pin Header”. “motor driver” seems to be best to match what is in the current core parts. The above link, or something equivalent, should be included in the part definition file. Properties that do not apply to this part should be removed from the definition. I assume this was created starting from a standard pin header part, but the definition data was not updated to correspond to the new part. The label should be something like “MOD” (for module), not “J” (jack/header)
<version>1</version>
<label>J</label>
<url>https://www.pololu.com/product/1451</url>
<description>Generic female header</description>
<tags>
<tag>carrier</tag>
<tag>VNH5019</tag>
</tags>
The definition file includes an “internal2” bus, but there are no connectors in it. If there are really no connectors, it should be removed.
The id values used for the different bus entries are very generic (“internal” with a number added to the end). This would be better with more descriptive names. Ground, vout, vin, outa, outb
On the schematic view, the connector pins are not aligning to the standard 0.1 inch grid. This could be (partly) due to using “px” for the drawing units, but is also from trying to squeeze multiple copies of repeated pins on the left and bottom of the schematic view of the part. On schematic view, there is no need to have multiple (visible) connectors for duplicated (bused) connectors. The simplest (correct) way to handle them, is to place the bused pins on top of each other, so it looks like a single pin. Since they are connected together internally in the part (bused), a connection to one pin is a connection to all of them.
Visual inspection says that some of the labels could be better lined up with the associated pins. CS_DIS is the most obviously shifted.
The pcb view is the footprint needed to mount the part onto a pcb. Which will be the pads, connection holes, possibly mounting holes, needed to be able to mount and connect the part. From that, likely the interiors connections are not needed. Unless there is actually a pin on the bottom of the carrier at those locations. I believe all of those interior pins are include in one of the bused groups, so, like the schematic, the pin could be moved, resized, hidden, under one of the other pins for that bus. Still need to show the extra pins for buses that have multiple pin connections, but that should be only 2 of 3 from each set at the bottom.
Here is a summary of what FritzingPartCheck had to say.
There are a couple of ‘px’ units on font-size attributes in the breadboard 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.
The connectors have all been set to ‘type=“female”’. Parts that are intended to (be able to) plug into a breadboard should have male pins. As a carrier board, “female” is correct, for any headers that can be plugged into. The standard male header I see in the pololu images makes me think that the outers rows of connectors should be male.
There is an inkscape specific font specification in the breadboard view. Fritzing can not handle that, but the element also has a standard font-family in the style, so it should be fine.
The main schematic drawing units are set to ‘px’. That should be ‘in’ or ‘mm’ (‘in’ probably best for schematic, to make matching to 0.1 inch grid spacing easier)
The copper0 layer should be ‘inside’ the copper1 layer, instead of the other way around.
The breadboard svg image does not have a ‘breadboard’ layer, to match the layerId specified in the definition file. The first (outer) group (‘g’) element in the file needs to have an ‘id=“breadboard”’ attribute. Without that, the part may work when viewed in Fritzing, but messes up if images are exported.
Similar for the schematic svg image. The outer wrapper element needs to have an ‘id=“schematic”’ attribute. In this case, that outer g needs to be added, to group together all of the graphics into a single layer.
The pcb image does have the needed silkscreen, copper1, copper0 layer id tags, but FCP found graphic elements before them in the file. In this case, that is just group (g) elements with not actual content, so it is probably ok. But to fix it in inkscape, select the single outer group that contains every thing, then ungroup. Repeat that (it looks like 5 times), until the copper and silkscreen content become separate blocks. Here the silkscreen is further wrapped by additional g elements. Select and ungroup that block (another 4 times) to get rid of the extra wrappers.
The fzp part definition file includes terminalId attributes for the breadboardView of the connectors, but no matching element exists in the svg file. If they are defined, they need to exist. Normally, the terminalId attributes are not needed for breadboard view. They are used for schematic view. Breadboard view can use them, but only really useful when the visible connector is a line, and want wires to connect to the end.
The fzp part definition file includes terminalId attributes for the schematicView of the connectors, but no matching element exists in the svg file. If they are defined, they need to exist. In this case, elements (typical small rectangles) should existing in the svg. Then need to be position at the outer end of the connection pin lines, so that wires will connect (snap) to the end of the line, instead of the middle.
In the pcb image, connector pins 2 and 12 have been created as path elements. To get the gerber export to specify a hole to be drilled, the pcbView svgId specified in the definition file must be on a circle element. For non-circular pads, an additional (path) element is used (without the svgId) to show the shape of the pad. It looks like you can just add the needed circle element, and move the id attribute to it.