We have now done all the svg files in the last two howtos:
refernece to part 2 of the howtos
and now we move on the the fzp file (the xml file that ties all this together). For the fzp file we need a text editor rather than Inkscape (as it is not an svg). This is the original fzp file for the part:
part.S4A EDU_295a638d2eff112f7b0707b26a2df99f_12-orig.fzp (38.4 KB)
copy this in to the new file
part.S4A_EDU_1-mine.fzp
So you have a copy of your modified fzp file to test with after we have tested with file part.S4A_EDU_1-errors.fzp which has some known errors in it (ones I actually made while modifying the original file!) to demonstrate how testing works in part 4 of this howto.
Things of note in a fzp file. First and foremost is the moduleId (on the second line). The moduleId must be globally unique in Fritzing. This one moduleId=“S4A EDU_295a638d2eff112f7b0707b26a2df99f_12” looks to have been created by parts manager, which generates at least partly based on time to guarantee uniqueness. In some of the old parts, version information which triggers processing for backward compatibility with new versions are encoded. Unfortunately we have to read the source code to identify these, because as far as I know they are not documented anywhere (that needs to be done when there is time.) The Fritizng version should likely be 0.9.3b not “0.5.2b.02.18.4756” (this was likely cloned from an old part and Fritzing will sometimes react based on the Version (or possibly only on the moduleId, I’m not real sure) which may have bad results sometimes. The reference file is also incorrect, it should be the name of the fzp file “S4A EDU_295a638d2eff112f7b0707b26a2df99f_12.fzp” in this case. Nothing I know of worries about the fritzng version or reference filenames, but I prefer to correct both for neatness and to comply with the parts file format document.
<module moduleId="S4A EDU_295a638d2eff112f7b0707b26a2df99f_12" fritzingVersion="0.5.2b.02.18.4756"referenceFile="jlpcb-089.fzp">
In this case I am changing the moduleId and file names to make this a new part that will load along with the original one, so the above line becomes:
<module moduleId="S4A EDU_1" fritzingVersion="0.9.3b" referenceFile="S4A EDU_1.fzp">
Since I want this new part to be able to load along side the original part in Fritzing, I need to do some more things. The moduleId (done above), variant, possibly the family if the pins in this part are not identical to the original (which here they are not) and all the file names for the svg files must be different than the original to allow it to load in to Fritzing. If I leave the family the same in the two files but with a different variant field, Fritzing will put up a select box in Inspector which will allow me to select which part I want and substitute one for the other (which means the pins need to be the same which isn’t the case here, because I renumbered the pins, so I didn’t do this.) Instead I chose to make this a new part by changing the fzp filename (to match my new moduleId) to part.S4A_EDU_1-mine.fzp which we did above. Note that I replaced the blank in the file name with a - (because underscore _ requires the shift key to type) so I don’t have to quote the file name because of the embedded blank, laziness at work again. I also changed the _12 to _1 and will change all the svg file names by removing the _295a638d2eff112f7b0707b26a2df99f from them. The trailing _number should be the same for the fzp file and all the svg files and identical to the version number to tell different versions of a part apart. The version number in the next line of the xml file should also match the _number, so in this case the version number changes from 4 to 2 like this, from:
<version>4</version>
to
<version>1</version>
As far as I know, nothing (including Parts Editor) changes this field, so you will often see it set to 4 as here. I assume this should be the version number of the the part, the parts format file doesn’t say, only that the obsoleting mechanism puts special values in this field.) The date and author fields are self evident, if you are modifying an existing part and did not clone it via parts editor, you should update the Date field to be the current date. It is good practice to add your name to the author field, something like this:
<author>Leonel Núñez Campos.RCF.Fundación Omar Dengo. modified by vanepp Oct 2019</author>
to tell people this has been changed from the original part and by who and when.
the description field can be html (probably generated by the Parts Editor when this part was edited), or can be straight text like this (if you are doing an fzp from scratch without Parts Editor)
<description>A description field can also be plain text like this as long as the start and end tags are valid xml and Fritzing will convert it to html when rendered (I think).</description>
In this case. leave the original html in this field in the fzp file, as it is meaningful to the part’s original author and I have no reason to change it. The above note just tells you what you can do if you want to while making a part. On to:
<title>Tarjeta S4A EDU</title>
The title of the part. I think parts editor may use this field as the name of the fzpz file.
<label>Mod</label>
This field sets the prefix of the part label (i.e. R1, R2 for resistors). I think it truncates at 4 characters and appends the number after that. If the field is missing, the default value is “Part” so you normally want to set it to something. Here (and for most modules) I used Mod to indicate it is a module. The url field can contain the url of the data sheet for the part. Currently it doesn’t have a url the
<url/>
field indicates a blank url. I replaced it with a pointer to the data sheet I made the part from (usually a good practice, so someone using the part later can see which version this part refers to if there are multiple versions of a part or module with the same name but different pins and functions which is common with ebay modules)
<url>https://www.gotronic.fr/pj2-34440-1407.pdf</url>
The tags fields are for search tags for the parts bin. Put useful search terms that some one could enter in the parts search tool to find your part.
<tags>
<tag>S4A EDU</tag>
<tag>Edu</tag>
<tag>S4</tag>
<tag>S4a Edu</tag>
<tag>Tarjeta</tag>
</tags>
I left these as is. The properties fields provide information for use by Inspector in Fritzing. The most important two are the family and the variant. The family contains (or should contain, it isn’t currently checked to enforce the requirements except manually) a family of identical parts that can be substituted for one another. They must have the same number of pins so that if you select s different variant you will get a different version of the part (which may act differently but has the same pins). As noted as far as I know this isn’t automatically enforced so you can get problems where changing to another variant of a part breaks your sketch because the number of pins are different and you will see the red square indicating unassigned pins in on or more view. Within a family, the variants must be unigue. Two parts with the same family and variant number will cause the second part to be rejected when you try and load it with a “this part already exists in Fritzing” type error message. I chose to change those two fields from:
<property name="family">Spark Fun</property>
<property name="variant">variant 1</property>
to
<property name="family">S4A Edu</property>
<property name="variant">variant 1</property>
because this is not a Sparkfun part, and it may conflict with another Sparkfun part (although it does not currently seem to do so.) The rest of the fields do various things in Inspector. To figure out what, you would have to read the source code because as far as I know there is no documentation except the source code for what they do. I usually delete anything that I don’t think applies to the part I’m making. One exception to that is the chip label field. If you have a property called chip label like this:
<property name="chip label">PM6078-004</property>
and a text field in breadboard or schematic (and possibly pcb) with the id label, then Fritzing will substitute the text from the chip label property for the text in the label field in the svg. If you use this make sure you have sufficient room to accommodate the amount of text you enter in the chip label field in the svg file. Note in these svgs I changed the label field to label1 so that this substitution will not occur. Next up are the view fields. These are used to describe what svg files (and the names of those svg files) are being used by this part. The format in use in this file is for the parts repository (where all the Fritzing parts, core and ones you added) live. The format of the repository is a series of directories, on the windows machine I am writing this on the Fritzng files are in
C:\fritzing\fritzing-ef8bbb7052ecc875e86441f15fdd1c2da15440c8-debug-continuous-288.64.pc
we are interested in
C:\fritzing\fritzing-ef8bbb7052ecc875e86441f15fdd1c2da15440c8-debug-continuous-288.64.pc\fritzing-parts
which is the parts repository. The fzp files for core parts are in (stripping off the C:\fritzing\fritzing-ef8bbb7052ecc875e86441f15fdd1c2da15440c8-debug-continuous-288.64.pc part of the path to leave only the fritzing directory)
fritizng-parts/core/
with the svg files in a parallel directors
fritizng-parts/svg/core/
where the associated svg files are in
fritizng-parts/svg/core/breadboard/ (breadboard svg files)
fritizng-parts/svg/core/icon (icon svg files)
fritizng-parts/svg/core/pcb (pcb svg files)
fritizng-parts/svg/core/schematic (schematic svg files)
this is important because in the fzpz file such as this part, the above files are all in the same directory with odd filenames that tell the Fritzing loader where to put the files. As you will note when you unzip the fzpz file for the original part you get the following 5 files:
part.S4A_EDU_295a638d2eff112f7b0707b26a2df99f_12.fzp
the fzp file which will be loaded in to:
prefix-dir/Documents/Fritzing/parts/usr/S4A_EDU_295a638d2eff112f7b0707b26a2df99f_12.fzp
where the directory “prefix-dir” above varies by operating system and can be found in the Folder structure section of the parts file format here:
with the part. section stripped and discarded.
The svg files go in to directories parallel to the core directory like this:
svg.breadboard.S4A_EDU_78c08539140e87873a7d0ebd198bd086_2_breadboard.svg
which will be loaded in to
prefix-dir/Documents/Fritzing/parts/svg/user/breadboard/S4A_EDU_78c08539140e87873a7d0ebd198bd086_1_breadboard.svg
without the svg.breadboard. prefix which is stripped and discarded by the loader. The other three svg files work similarly in to their respective directories. The important thing to take from this is that the
S4A EDU_78c08539140e87873a7d0ebd198bd086_1_breadboard.svg
portion of the image field must match, including case, the portion of the file name after the svg.breadboard. in the file name
svg.breadboard.S4A EDU_78c08539140e87873a7d0ebd198bd086_1_breadboard.svg
with the text after the breadboard/ in
<layers image="breadboard/S4A EDU_78c08539140e87873a7d0ebd198bd086_1_breadboard.svg">
if the case is different, the part will work on Windows, (which ignores case in file names although it keeps the case in the file system) but not load due to missing (because the case is wrong) svg files on Linux or MacOS versions of Fritzing. The check part script checks for this particular fault and will toss an error, but there are parts in core parts that have this problem. This means that to submit a part that you have created as a .fzpz file to the parts repository, you will need to remove the fzpz prefixes and move the renamed fzp and svg files in to their correct directories to be able to make a pull requset to get the part added to the repository. In this case the directories are not the ones above (which are for user loadad parts) but the core parts repository directorises which are of this form (similar to the above, but with slightly different names including in this case the new part core suitable file names for the fzp and svgs):
fzp file:
prefix-dir/fritzing-parts/core/part.S4A_EDU_1.fzp
where here the prefix-dir is the path to your Fritzing-parts repository.
breadboard file:
prefix-dir/fritzing-parts/svg/core/breadboard/S4A EDU_1_breadboard.svg
with the other tree svgs in similar directories with the viewId as the parent directory.
The new version of the parts checking script will be able to do this for you, but it isn’t finished yet. Also of note is that the file names must be unique. If the file name is already in use in a part (either in core parts or loaded by the user) in Fritzing you will get the “A part with this name already exists in Fritzing” message and the load will fail So in order to successfully load this part along side the original part in Fritzing you will need to change the moduleId, either the family name or the varient (the varient is not a good bet as the new part has the pins renumbered), and the fzp and svg file names of the new part. The next line down sets the layerId for the svg file. In this case, the standard breadboard is in use (as it should be) like this:
<layer layerId="breadboard"/>
you will sometimes see a layerId in parts. This should be avoided, because layerId breadboardbreadboard is special, and (along with a few other magic values in family and moduleId) is used to make the breadboards in Fritizng special. Unless you are very experienced, you do not want your standard part acting like a breadboard so change the layerId back to breadboard for most parts that have breadboardbreaboard set as a layerId (breadboard parts are the exception to this rule.) The value of this field (breadboard in this case) needs to be the id of a group that contains the entire part in the associated svg file (the breadboard svg in this case.) If the layerId is missing, the part will work, but the part will not be exported if the user asks that the sketch be exported as ab svg, I am not aware of anything else the breaks because of this, but that doesn’t mean there isn’t something (or many somethings). The safe bet is have correct layer ids from the set breadboard, icon and schematic, copper0, copper1, and silkscreen (the last 3 only for pcb svgs.) There are more for pcb, but these are the standard ones. Now a non standard trick to save file space. The icon file is usually a copy of the breadboard file, and is only used to create the icon in Inspector. The standard practice has been to copy the breadboard svg in to the icon svg, but that wastes disk space. A better alternative is to do this (which uses a single copy of the breadboard svg rather than 2 and saves a bunch of disk space in the part): change this
<iconView>
<layers image="icon/S4A_EDU_78c08539140e87873a7d0ebd198bd086_2_icon.svg">
<layer layerId="icon"/>
</layers>
</iconView>
to this (which reuses the breadboard svg as the icon svg)
<iconView>
<layers image="breadboard/S4A_EDU_78c08539140e87873a7d0ebd198bd086_2_breadboard.svg">
<layer layerId="icon"/>
</layers>
</iconView>
For SMD (surface mount) parts copper0 is omitted and only copper1 and silkscreen are present as pcb layerIds. The next major section is the connectors section. Here all the connectors for your part are defined. In this case, here is where the trouble starts. Connectors should start at pin 0 (for external pin1 which is confusing, but a quirk of Fritzing). They should (and for the part to work correctly must) increase in accending sequence to the last pin. It is strongly preferred to make part checking easier that they start at pin0 and go up in order. This part starts correctly at pin0 and proceeds in sequence to pin11 but after that it jumps to pin 50, goes for a while and jumps to pin 90 etc. There are only 69 pins in the part however, so this is incorrect (and likely came about because the original part this was cloned from came from the eagle2fritzing script which produces pin numbers like this.) One thing that breaks when the pins are not in sequence is the display the pin label when you hover on a pin in any view. In at least (and possibly only) parts with subparts (which are not that common) the out of sequence pins cause the wrong label to be displayed for an otherwise valid pin. The solution I use for this problem is to delete the entire xml from the opening to the closing and replace it with an in sequence set for the correct number of pins that is generated by a python 3 script (available from here on github):
using a command line of the form (for the 69 pins in this part)
$ FritzingCreateFzpConnectors.py new-cons 69
which writes the new connector xml to a file called new-cons. That xml is then substituted in to the fzp file in place of the xml that was removed. Once that is done it is necessary to use a text editor to add the “GND” and Tierra back in to the blank fields in the created xml
<connector id="connector10" type="male" name="GND">
<description>Tierra</description>
where the script had created this:
<connector id="connector0" type="male" name="">
<description></description>
with both name and description fields blank, ready for text to be added. This is much easier than trying to renumber the various fields in the connectors and get them all correct. Looking at the final fzp file for this part should make it obvious how to do this. After the connectors section there are a few optional fields, the one in use here is buses. For pins in a part that connect together internally (ground is a very common case, as is 5V and 3.3V power, but signals can also be bused) the connectors are defined in a buses section consisting of bus sections which look like this:
<buses>
<bus id="bus0">
<nodeMember connectorId="connector1"/>
<nodeMember connectorId="connector2"/>
</bus>
<bus id="bus1">
<nodeMember connectorId="connector3"/>
<nodeMember connectorId="connector4"/>
</bus>
</buses>
This causes connector1 and connector2 to be consdered to be connected internally. Clicking on pin1 will cause both pin1 and pin2 to light up yellow indicating they are connected. The typical problem here is that Parts Editor does not clear the bus definitions when you clone a part. Thus if the original part had buses defined, they (and their pin number from the original part) are still set as buses in the new part. This isn’t a problem if you are aware of it (but most people are not aware of it) and remember to check and remove the bus configuration if it is incorrect in your new part. This part originally had an incorrect bus configururation probably left over from the original part (beacause eagle2fritzing generates appropriate bus definitions for the parts it generates.) Thus I removed the entire bus section and created a new bus definition suitable for this particular part. Generating the list of connectors is time consuming. Basically you need to consult the documentation (if there is any) for the part, or if you have a part, use a beeper to identify all pins that connect together. In this case with minimal documentation, I more or less made an educated guess at the becessart buses and asked the person with the part to verify it. All the grounds are common, so they go on the list (the battery- terminal is also ground so it gets included too), same for all the V+ pins for the servos, which may or may not connect to 5V (I assumed not, as I think you can select an external source for V+ to allow for 6V servos.) I’m guessing the the middle blue tooth connector (which has no labels on the pcb) is the same as the top one and thus connected them together. All of this produces a bus section that looks like this:
<buses>
<bus id="gnd">
<nodeMember connectorId="connector1"/>
<nodeMember connectorId="connector2"/>
<nodeMember connectorId="connector3"/>
<nodeMember connectorId="connector4"/>
<nodeMember connectorId="connector5"/>
<nodeMember connectorId="connector6"/>
<nodeMember connectorId="connector7"/>
<nodeMember connectorId="connector8"/>
<nodeMember connectorId="connector28"/>
<nodeMember connectorId="connector32"/>
<nodeMember connectorId="connector36"/>
<nodeMember connectorId="connector57"/>
<nodeMember connectorId="connector58"/>
<nodeMember connectorId="connector59"/>
<nodeMember connectorId="connector60"/>
<nodeMember connectorId="connector61"/>
<nodeMember connectorId="connector62"/>
<nodeMember connectorId="connector63"/>
</bus>
<bus id="5V">
<nodeMember connectorId="connector18"/>
<nodeMember connectorId="connector31"/>
<nodeMember connectorId="connector35"/>
<nodeMember connectorId="connector65"/>
</bus>
<bus id="v+">
<nodeMember connectorId="connector10"/>
<nodeMember connectorId="connector11"/>
<nodeMember connectorId="connector12"/>
<nodeMember connectorId="connector13"/>
<nodeMember connectorId="connector14"/>
<nodeMember connectorId="connector15"/>
<nodeMember connectorId="connector16"/>
<nodeMember connectorId="connector17"/>
<nodeMember connectorId="connector51"/>
<nodeMember connectorId="connector52"/>
<nodeMember connectorId="connector53"/>
<nodeMember connectorId="connector54"/>
<nodeMember connectorId="connector55"/>
<nodeMember connectorId="connector56"/>
</bus>
<bus id="D12">
<nodeMember connectorId="connector25"/>
<nodeMember connectorId="connector68"/>
</bus>
<bus id="D13">
<nodeMember connectorId="connector26"/>
<nodeMember connectorId="connector67"/>
</bus>
<bus id="TX">
<nodeMember connectorId="connector33"/>
<nodeMember connectorId="connector37"/>
</bus>
<bus id="RX">
<nodeMember connectorId="connector34"/>
<nodeMember connectorId="connector38"/>
</bus>
<bus id="D11">
<nodeMember connectorId="connector42"/>
<nodeMember connectorId="connector64"/>
</bus>
</buses>
which I think correctly describes the part although pad locations in pcb are almost certainly wrong (subject to verification by someone that has one.) At present this fzp file and the associated svgs have errors so we can see how testing proceeds, (the errors were mostly by accident rather than design.) The fzp file with errors is in:
part.S4A_EDU_1-errors.fzp (40.4 KB)
So you can download it to proceed with testing the part in part4 (there is another copy of this file in there as well.) That finishes the fzp file and the part is now complete and ready for testing which is described in part 4 here: