In addition to the first post (due to hosting limitations)

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:

Having completed all the files for the part in (and earlier):

On to testing the part.

First run it through FritzingCheckPart.py, the part checking script. This checks the syntax of the part for errors and fixes some things that Inkscape does for CSS compliance that Fritzing does not support. Those are: remove the px from the end of font-size elements. Replace CSS style commands with equivalent inline XML (bendable legs do not support style commands), and insure that a stroke-width value (which may be inherited) appears in the copper1/copper0 groups (because gerber processing doesn’t do inheritance and will break without a stroke-width.) FritzingCheckPart.py is available from:

So to start download the broken fzp file created in the last part of this series:

part.S4A_EDU_1-errors.fzp (40.4 KB)

and copy it to part.S4A_EDU_1.fzp

then download the 3 svg files created in parts 1 and 2 of this series:

svg.breadboard.S4A_EDU_1_breadboard.svg.fzp (180.5 KB)

svg.pcb.S4A_EDU_1_pcb.svg.fzp (15.4 KB)

svg.schematic.S4A_EDU_1_schematic.svg.fzp (106.7 KB)

again you need to remove the trailing .fzp to recover the .svg file (because the forum has problems uploading svg files.) Then install FritzingCheckPart.py from github above if you have not and run FritzingCheckPart.py like this (this is under cygwin on Windows.) Note I used a newer version of the script that hasn’t been released yet because it has better formatted output messages so this output may not exactly match what you get until the new version is released but the error numbers should be the same, just the text is poorly formatted:

$ FritzingCheckPartw.py part.S4A_EDU_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.S4A_EDU_1.fzp

Error 6: ParseFile error parsing the input xml file part.S4A_EDU_1.fzp

part.S4A_EDU_1.fzp:12:53:FATAL:PARSER:ERR_TAG_NAME_MISMATCH: Opening and ending tag mismatch: url line 12 and unparseable

The xml error in the fzp file at line 12 as the error message above stated here somewhat cryptically:

part.S4A_EDU_1.fzp:12:52:FATAL:
                   ^^ ^^
		  |  |	
		  |  | char on line
		     | 
		     | line number

so edit the .fzp file with a text editor (here I am using vi under cygwin but any text editor should work) and correct line 12:

$vi part.S4A_EDU_1.fzp

where:

 <url>https://www.gotronic.fr/pj2-34440-1407.pdf</>

should be

  <url>https://www.gotronic.fr/pj2-34440-1407.pdf</url>

So use your text editor to correct that and try again:

$ FritzingCheckPartw.py part.S4A_EDU_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.S4A_EDU_1.fzp

**** Starting to process file svg.schematic.S4A_EDU_1_schematic.svg.bak

**** Starting to process file svg.pcb.S4A_EDU_1_pcb.svg.bak

File
‘part.S4A_EDU_1.fzp.bak’

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 43

Modified 4: File
‘svg.schematic.S4A_EDU_1_schematic.svg.bak’
At line 31

ReferenceFile

‘S4A_EDU_78c08539140e87873a7d0ebd198bd086_1_schematic.svg’

doesn’t match input file

‘S4A_EDU_1_schematic.svg’

Corrected

Modified 1: File
‘svg.schematic.S4A_EDU_1_schematic.svg.bak’
At line 50

Removed px from font-size leaving 60

Modified 1: File
‘svg.schematic.S4A_EDU_1_schematic.svg.bak’
At line 56

Removed px from font-size leaving 49

… (many more identical lines removed to save space!)

Modified 1: File
‘svg.schematic.S4A_EDU_1_schematic.svg.bak’
At line 212

… (many more identical lines removed to save space!)

Modified 1: File
‘svg.schematic.S4A_EDU_1_schematic.svg.bak’
At line 3330

Removed px from font-size leaving 49

Modified 4: File
‘svg.pcb.S4A_EDU_1_pcb.svg.bak’
At line 16

ReferenceFile

‘S4A_EDU_78c08539140e87873a7d0ebd198bd086_1_pcb.svg’

doesn’t match input file

‘S4A_EDU_1_pcb.svg’

Corrected

Warning 34: File
‘svg.pcb.S4A_EDU_1_pcb.svg.bak’
At line 752

translates are undesirable.

Error 15: Can not rename

‘svg.breadboard.S4Ar_EDU_1_breadboard.svg’

to

‘svg.breadboard.S4Ar_EDU_1_breadboard.svg.bak’

‘svg.breadboard.S4Ar_EDU_1_breadboard.svg’

No such file or directory (2)

Error 20: File
‘svg.breadboard.S4Ar_EDU_1_breadboard.svg’

During processing svgs from fzp, svg file doesn’t exist

Error 18: File
‘part.S4A_EDU_1.fzp.bak’

Connector connector21terminal is in the fzp file but not the svg file. (typo?)

svg svg.schematic.S4A_EDU_1_schematic.svg.bak

Error 18: File
‘part.S4A_EDU_1.fzp.bak’

Connector connector53pin is in the fzp file but not the svg file. (typo?)

svg svg.schematic.S4A_EDU_1_schematic.svg.bak

Error 18: File
‘part.S4A_EDU_1.fzp.bak’

Connector connector54pin is in the fzp file but not the svg file. (typo?)

svg svg.schematic.S4A_EDU_1_schematic.svg.bak

Error 18: File
‘part.S4A_EDU_1.fzp.bak’

Connector connector65pin is in the fzp file but not the svg file. (typo?)

svg svg.schematic.S4A_EDU_1_schematic.svg.bak

$

Which produces this huge bunch of output. The Modified lines like these can usaully be ignored (that is why they are output first in the listing, so they are there but easy to ignore). They document the changes the script has made to the various files in case something goes wrong.

This one records that the orginal reference file ‘S4A_EDU_78c08539140e87873a7d0ebd198bd086_1_schematic.svg’ was replaced with the svg file name ‘S4A_EDU_1_schematic.svg’ as it should be. As far as I know Fritzing doesn’t care about reference file names, but this is the correct value.

Modified 4: File

‘svg.schematic.S4A_EDU_1_schematic.svg.bak’
At line 31

ReferenceFile

‘S4A_EDU_78c08539140e87873a7d0ebd198bd086_1_schematic.svg’

doesn’t match input file

‘S4A_EDU_1_schematic.svg’

Corrected

Next we have a large bunch (all the text in the svgs) where the trailing px was removed from the font size. If the px is left on the font-size and the svg is processed by the New parts editor, the font size will be set to 0 which means the fonts will be tiny instead of their proper size. This is likely a Fritzing bug, but it hasn’t been fixed yet (and may not be fixable if its a QT issue.)

Next we have the warning messages. These are as the name implies Warnings, something is unusual, but not known
to break Fritzing. It is issued to alert the human to look at the issue and see if it is in fact an error that needs to be fixed

Warning 34: File
‘svg.pcb.S4A_EDU_1_pcb.svg.bak’
At line 752

translates are undesirable.

It is complaining about translates in polygons in breadboard, which I don’t know of a way to remove yet (it may not be possible except ar render time). It is intended to warn you that there are translates in a svg which it is desireable but not always possible to remove (some in pcb are marked as Error because they will break Fritzing.) Here we can ignore this (with the original script currently on github you won’t see this message)

Now come the important ones the Errors that need something done about(When I finish the new version of this script it will be added to the tool change for parts submission and in order to get a part included in core parts, all the Error conditions will need to be removed.):

Error 15: Can not rename

‘svg.breadboard.S4Ar_EDU_78c08539140e87873a7d0ebd198bd086_2_breadboard.svg’

to

‘svg.breadboard.S4Ar_EDU_78c08539140e87873a7d0ebd198bd086_2_breadboard.svg.bak’

‘svg.breadboard.S4Ar_EDU_78c08539140e87873a7d0ebd198bd086_2_breadboard.svg’

No such file or directory (2)

the breadboardfile image is misnamed (an extra r) in the fzp file, so correct that.

<breadboardView>
  <layers image="breadboard/S4Ar_EDU_1_breadboard.svg">

which should be:

<breadboardView>
  <layers image="breadboard/S4A_EDU_1_breadboard.svg">

Note there is some truth to the opinion that this is why you should use the New parts editor to edit parts, because it does not make mistakes like this. If that works for you, then using New Parts editor is fine. For me it doesn’t work in enough cases that I prefer to do this and deal with the errors I create.

Next there are several pins misnamed in the schematic svg file which also need correcting (in this case the
error isn’t in the fzp file because the connectors in the fzp file were created correctlly by a script leaving only the svg, in a normal part it could be either, so you need to check both).

Error 18: File
‘part.S4A_EDU_1.fzp.bak’

Connector connector21terminal is in the fzp file but not the svg file. (typo?)

svg svg.schematic.S4A_EDU_1_schematic.svg.bak

This is telling you that connector21terminal is defined in the fzp file (and we see as noted it is spelled correctly because it was generated by a script rather than me typing), but a corresponding id was not found in the scheamatic svg svg svg.schematic.S4A_EDU_1_schematic.svg.bak. The .bak on the end is because that is the original svg.schematic.S4A_EDU_1_schematic.svg which was saved as a backup before the script processed the file. The .bak file is used here because the line numbers in svg.schematic.S4A_EDU_1_schematic.svg may be different if certain modifications were made by the script to the svg file. I usually ignore the .bak file and edit the svg.schematic.S4A_EDU_1_schematic.svg file remembering the line number may be out a line or 2 either way. In this case the fzp file doesn’t know what line number the terminal it can’t find should be in the svg, and thus doesn’t provide a line number so we need to search for the listed pin (which is probably misspelled). This is where it is useful to have the terminals in order on the bottom of the xml editor window. That makes it easy to find connector21terminal which in the svg file is connectort21erminal which needs to change to connector21terminal to match the fzp file. Similar things for the other pins and terminals with the error and correction listed below:

connector53tpin

to

connector53pin

connector54pi

to

connector54pin

and then

lconnector65pin

to

connector65pin

Now run

$ FritzingCheckPart.py part.S4A_EDU_1.fzp

again, which will now complains about breadboard because it didn’t process it the fist time due to the file name error:

… (px removed warnings snipped)

Warning 34: File
‘svg.breadboard.S4A_EDU_1_breadboard.svg.bak’
At line 52

translates are undesirable.

Warning 34: File
‘svg.pcb.S4A_EDU_1_pcb.svg.bak’
At line 752

translates are undesirable.

Error 18: File
‘part.S4A_EDU_1.fzp.bak’

Connector connector15pin is in the fzp file but not the svg file. (typo?)

svg svg.breadboard.S4A_EDU_1_breadboard.svg.bak

$

If the pins in breadboard were not in order (which may not be because of how the connectors are constructed, where moving the connector to the bottom of the xml window modifies the appearance of the connector) it is neccessary to search for the connector in Inkscape. To do so load the svg in Inkscape and then click in the xml editor window to select something, (anything will do), then press cntrl-f, Inkscape is being uncooperative and closes the search window when I switch to snip tool. In Inkscape a blank rectangle appears in the xml editor window that you type the search term into in this image:

bb-xml-element-selected.PNG

in the box that comes up type connector15 which finds nothing, so switch to r15 which finds

cnnector15pin

which needs to be

connector15pin

In this case because the pins are in order you can more easily just scroll down to connector15 though. Now run FritzingCheckPart.py again:

$ FritzingCheckPart.py part.S4A_EDU_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.S4A_EDU_1.fzp

**** Starting to process file svg.breadboard.S4A_EDU_1_breadboard.svg.bak

**** Starting to process file svg.schematic.S4A_EDU_1_schematic.svg.bak

**** Starting to process file svg.pcb.S4A_EDU_1_pcb.svg.bak

File
‘part.S4A_EDU_1.fzp.bak’

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 43

Warning 34: File
‘svg.breadboard.S4A_EDU_1_breadboard.svg.bak’
At line 66

translates are undesirable.

$

and this time it runs clean. The warnings about px are missing because they were removed on the first run through of the script and are thus no longer a problem. If you had to edit the svg in Inkscape they may have returned as Inkscape re adds the style and px for CSS.

If you did not choose to reuse the breadboard svg as the icon image file, copy the breadboard svg in to the icon svg (checkpart ignores icon svgs, so it is desirable to have the corrected breadboard svg in there).

use 7zip (or any other zip program) to create the fzpz file from

part.S4A_EDU_1.fzp
svg.breadboard.S4A_EDU_1_breadboard.svg
svg.pcb.S4A_EDU_1_pcb.svg
svg.schematic.S4A_EDU_1_schematic.svg

Note 7zip will allow you to rename the default .zip file to .fzpz, if your zip program won’t create it as a zip file and then rename the .zip to .fzpz.

to a file called S4A-EDU-improved.fzpz to create the new part.

Start Fritzing and

open->S4A-EDU-improved.fzpz

which immediately shows a problem:

in schematic view the part is showing as “part1” because there is not a label element in the fzp file so go correct that first. Open the fzp file in a text editor and make this change to add a label field:

  <title>Tarjeta S4A EDU</title>
  <url>https://www.gotronic.fr/pj2-34440-1407.pdf</url>

to

  <title>Tarjeta S4A EDU</title>
  <label>Mod</label>
  <url>https://www.gotronic.fr/pj2-34440-1407.pdf</url>

Now you need to rezip the fzpz file to make the above change, and now when you load the part it should be labeled Mod1 not part1.

At this point (before routing the test connections to avoid having to redo that!) export and check the gerber files. To do that, with the part the only thing in pcb view, (if needed, it is not in this case, in Inspector increase the size of the pcb from the default 56.4mm to fit the pcb and drag the pcb background til the entire pcb is present like this:

pcb-to-gerber.PNG1144x596 109 KB

Then click on File->Export->For production->extended gerber (RS-274X) and select a directory to store the gerber files and click Select folder to write the gerber output to that directory. When that is done, edit the Untitled Sketch_drill.txt file in the directory where the gerbers were written and check the hole sizes (in this case they are all 0.038in for .1 square headers). If they are not as expected (i.e. one or more are some odd value due to an error), correct that first before proceding to route the test sketch (because you will just need to waste time redoing the test sketch after you fix the drill sizes later.) In this case they are correct because I copied in the pcb of headers made correctly by the parts factory. This is from a sketch that someone posted to the forums (because it has a wrong hole size):

Untitled Sketch_drill.txt

; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T1C0.086614
T100C0.015748
T101C0.038000
T102C0.035000
T103C0.036076
T104C0.040000
…

In the above the line “T103C0.036076” is wrong (this is the DFRobot DFPlayer Mini part in core parts at present.) The hole for a .1in header pin should be 0.038in (like the line two above it) not 0.036076in. At this point you should go back to the pcb svg and correct the pads involved to adjust the hole size to 0.038in (or whatever the data sheet specifies for the hole.) In Inkscape the hole diameter is set to hole diameter = pad diameter - 2 * stroke-width. At the 10.41667 scale used here and the standard 20 thou stroke width, we produce a 0.038in hole by 20 (stroke-width) * 2 = 40 + 38 (0.038 inches in thou) = a pad diameter of 78 thou. A complication in Inkscape is that the start position of the hole is the edge of the pad, but pitch is to the center of the hole. The lazy way out of this is to select a pad, then in the tool bar set the height and width of the pad to 0.078in and record the radius value from xml editor. Now use Edit->undo to undo the height and width change, then in xml editor set the radius to the value you found by changing the height / width above. An example using a pad from this part’s pcb svg to illustrate this process. First I will change the radius of an existing pad so the pitch is correct (at .1 in) but the hole size is not (it is 0.035in rather than 0.038 as it should be) (note: I adjusted the grid offset in Document properties here so the pads are centered on the grid to demonstrate the change in offset):

pcb-smaller-radius-hole.PNG1688x613 152 KB

Now I set the smaller pad’s diameter from 0.075in to 0.078in via the tool bar (highlighted in blue) and we see the pitch of the pad changes slightly to the right in x and up in y (highlighted in red):

pcb-diameter-changed-hole.PNG1225x622 122 KB

So take note of the new radius in xml editor (29 instead of 27.5) and then Edit->undo change attribute twice to reset the diameter to 0.075in. Now instead of changing the diameter via the tool bar, in xml editor change the radius from 27.5 to 29.

pcb-change-radius.PNG1222x621 110 KB

That changes the size of the pad to 0.078in but leaves the center of the pad where it is, which is what we need to preserve the proper pitch:

pcb-radius-changed.PNG1222x619 108 KB

As we see the pad is now the same size as the one next to it, and in the correct x/y position. Job done.

Now using a gerber viewer (I use gerbv from the Geda project, but there are lots of them) load the copper0 (if there is one, SMD parts only have copper1), copper1, drill, silkscreen top, and silkscreen bottom layers. Check that everything that appears on those layers in Fritzing’s pcb view is present. There are bugs where sometimes an element is displayed correctly in Fritzing PCB view, but is incorrect (outline paths in silkscreen are a common one) in the gerber output. Since the gerber output (not Fritzing pcb view) is what makes the board, the board will be wrong. If there are problems here, correct them before going on with the testing so you don’t have to redo the later testing (laziness ruling yet again!) Next That isn’t always the case if you started from another part though. The line “T100C0.038000” indicates that hole type T100C (plated through hole) will be drilled to the desired 0.038in.

; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T100C0.038000
…

Now before you route the test sketch, check the bus configuration, if there is one in your part (there is in this one and there is an error here.) To do that, with the part loaded in to Fritzing, pick one of the three views (I usually use schematic because the pin labels there make it easy to check the members of the bus are correct), and click on a pin that is a member of the bus. All the other pins that are supposed to be in the bus should light up yellow. If one or more do not, or a pin not in the bus lights up, there is a bus error and you need to fix that before proceeding. In this case (since there is a bus error in this part) lets try it. With the Tarjeta-S4A-EDU-improved.fzpz loaded in to Fritzing, click on the isp-5 pin RESET. It should not be bused as RESET isn’t an external pin, however it is bused to D11 due to a typo in the fzp bus definitions (connector66 instead of cconnector64 as it should be), so edit the fzp file and correct that:

reset-bused-wrong.PNG614x719 56.3 KB

(the yellow highlight only exista as long as the pin is hovered over in Fritzing, hovering over the Reset pin outlined in blue here should incorrectly light D11 yellow.) To correct this edit the fzp file in a text editor and correct the bus definition for the D11 bus:

<bus id="D11">
  <nodeMember connectorId="connector42"/>
  <nodeMember connectorId="connector66"/>
</bus>

should be

<bus id="D11">
  <nodeMember connectorId="connector42"/>
  <nodeMember connectorId="connector64"/>
</bus>

so correct that and rebuild the fzpz file with 7zip load it and make sure clicking on D11 lights isp-4 MOSI rather than isp-5 RESET as now. At this point we have verified the pcb to gerber and bus definitions are correct so now we can route the sketch to verify all the connections. To do that I use connectors of the appropriate length to work in scehamtic (someiimes as in this case connectors in breadboard are different in schematic). Note due to a current Fritzing bug (which hopefully will be fixed in an upcoming release), you are best off to drag a part in to schematic first. If you drag it in to breadboard or pcb, its orientation in scheamtic will be random (i.e. correct sometimes but rotated others.) Dragging it in to schematic first normally places it correctly oriented. So lets start testing the part (which typically takes almost as much time as making it!) Because the servo pins are odd (i.e. different in schematic than in breadboard) I will start there by creating a 3 pin connector for the top row of the three 9 pin headers like this:

bb-first-con.PNG1147x800 136 KB

Laziness tip: the connector will likely be misaligned in schematic, aligning it correctly in schematic before duplicating the next eight for the other conneectors in breadboard will save re aligning later ones in schematic.

now switch to schematic to align the connector (which is indeed incorrectly aligned and needs to be flipped horizontal):

schematic-first-con-misaligned.PNG1146x804 135 KB

So right click on the connector and click flip horizontal to change it to the correct alignment and move it in to the correct position like this:

Of note here is the end of the connector is two grid marks up and two grid marks left of the end of the connector. The purpose of this is to check both the alignment and the position of the connector terminalId. If the terminalId is missing (which the check script should catch) the connection will be to the center of the pin like this:

with the connector offset from the pin, the error becomes obvious:

which is why to use the offset pin layout. Now switch to pcb view to route the connector there (this avoids confusion later when all the connectors align on top of each other.) First use inspector to increase the height of the background pcb from the default 56.4mm to 100mm to give more space for connectors (if they are outside the grep pcb area, they will be truncated in the gerber output!):

pcb-first-con-routed.PNG1147x984 213 KB

of note here is I moved the connector in pcb in to position, routed it (all on the bottom level) and set the trace widths to super fine 8mil (8 thousandth of an inch) in Inspector (outlined in red), as sometimes the traces will need to go between pins. Note this isn’t a practical routing, the idea is to verify that the pins connect to the correct place so, I don’t care about whether the placement makes physical sense or not. Now switch back to breadboard and duplicate the first connector to use for the second one. Now switch back to breadboard view and select the first connector, right click it and duplicate it.

which appears correctly aligned in schematic (although overlayed on the first connector):

click and drag it in to position:

and laziness wins, you don’t have to flip in horizontally and move the pin label. There is however an issue:

here because the middle connector is bused, and the connection on the pin above it is closer to the second pin, the rats nest line connects to the incorrect connector. That isn’t a problem, you just need to click on +V pin on the part and drag that to the pin on the connector (shown poorly by a blue line in the image) to make the correct connection like this:

Now because I am lazy and don’t want to redo all the work I have jumped to the isp connector where we come on an error, breadboard is fine:

but schematic has a terminalId offset by .1in (which the script won’t catch, as the terminalId is present, just in the wrong position) which causes this:

here the connector64terminal and connector65terminal y coord are the same rather than .1in different. Thus both the lines from the connector connect on pin3 rather than one on pin 3 and one on pin4 as should happen. To correct this you need to correct the position of connector64terminal in the schemaitc svg. In this case the visual check finds an error that is difficult for automated tools to find. Now back to pcb to route the second connector. To do that we need to set the grid size finer than the default .1 in so in Fritzing in pcb view click on view->Set grid size and set the grid size to .05in like this:

pcb-set-grid.PNG739x569 83.2 KB

that allows you to route the second connector like this (without shorting any of the other pads):

pcb-second-con-routed.PNG329x670 49.4 KB

Now route all the rest of the part to end up with this:

test-Sketch.fzz (73.9 KB)

Once pcb is all routed run DRC (Routing->Design Rules Check) to make sure your part has sufficient clearance. For some high density SMD parts you may need to adjust the DRC rules to make it pass, but it is preferable to be able to pass the defailt rules if possible. As the last step, export the pcb view as gerbers (File->Export->For production->Extended gerber (RS274X) and check the result in a gerber viewer to make sure pcb view is being correctly reflected in the gerber output (there are some bugs in the gerber code, so this isn;t always true.) The gerber output from gerbv for this particular sketch looks like this:

gerbv-gerber-output.PNG1453x850 95 KB

When all that passes, your part is ready to publish.

There is another version heading for core parts here:

Because it is github the file is called Arduino-Sensor-Shield-v5.0.fzpz.zip (because github doesn’t do .fzpz files) so it is somewhat hard to find.

Peter

I have been using iTunes in my apple device for file sharing with other devices. Recently I reset my device and when I opened iTunes at that time 0xe8000065 pop-up message shown on my device. I could not share anything with other devices. How can I fix the problem?

Getriebemotor.fzpz (12.8 KB)

Nice job in breadboard, but a few problems: dimensions are in px, which can cause scaling problems (and has here):

my new part on the left has the dimensions changed from px to in. I would guess this was done in an earlier version of Inkscape such as 0.9.2.1 that is 90dpi/px where I am using 0.9.2.4 which is 96dpi/px. If dimensions were in in or mm that wouldn’t matter, but in px it does (as well Fritzing guesses at the px value and often gets it wrong.) I also chose to add connectors for the barrel jack instead of only the terminals (and suppressed them in pcb view as not useful, which turned up a new Fritzing bug!) It is possible (I did it to see a couple of years ago) to make a barrel part that will “connect” in breadboard with a female barrel socket, thus the extra connectors. Nothing I am aware of uses this, but it is possible and a wall wart using it would be useful as a part (I just haven’t gotten there yet.) In pcb

The holes in pcb are too small for a .1 connector (0.030in instead of 0.038) and the pads are paths which make it very hard to change the hole size (at least for me). I also removed the text. The reason is, if the text is in the part, you have to modify the part to remove it if you don’t want it. If the text isn’t in pcb, you can add it to the sketch if you want it, but someone that doesn’t want it doesn’t have to change the part to remove it.

Schematic is too large (space is valuable in schematic, smaller is better) and lacks terminalIds. Because the pin is square, (which is non standard) that is less of a problem than it might be. Svg scales are incorrect, but that is a minor issue. All of these are fixed up in this improved part (breadboard needs the scale adjusted so it matches the real part though):

2.1mm Barrel Jack with Terminal Block-improved.fzpz (6.3 KB)

Peter

Passive Buzzer.fzpz (21.6 KB)

Switch with Pull-Up and LED.fzpz (35.1 KB)

H-Bridge with L298N.fzpz (20.0 KB)

Hi!

Voltage Sensor 25V.fzpz (16.3 KB)

Безымянный2.png450x590 186 KB

Not a bad job overall, better than many I have seen. There are a few problems however. Breadboard is fine, mostly (the buses are wrong but that affects all views.) Schematic s where the problems start:

schematic.PNG1142x590 69.7 KB

on pins 3 and 4, the terminalIds are missing or incorrect, so a wire connects to the center of the pin instead of the end. If you click on the VCC pin, the + pin lights up yellow, unfortunately the data sheet says the + pin on the connector is NC, and the GND pin does not light up the - pin on the connector pin yellow as it should. On to pcb, again there are a number of problems:

pcb.PNG874x584 82.5 KB

all the traces are on the top layer, because there is no copper0 layer, (just one called copper, which isn’t defined in the fzp). The two pins on the terminal block show up in pcb (where I suppressed them as not being practical in pcb.) As well your pads are not appropriate for .1 header connectors (a 0.038in hole) but rather 0.031in

from the gerber drill file.

M48
INCH
T100C0.038000
T101C0.031496

the top number here are the holes in my part at the correct 0.038in, followed by yours. As well DRC (routing->Design Rules Check) complains about the lack of a second layerId:

drc.PNG880x597 68.1 KB

My improved part

Voltage-Senso-25V-improved.fzpz (9.3 KB)

and the test sketch:

test-Sketch.fzz (31.9 KB)

What I did to change your part in to mine can be found in this series:

Peter

On the download page, there’s a very large button prominently labelled ‘Download’. If you press this, you get logged into Paypal and presented with a payment page.

Please don’t do this. It’s really scummy — it’s the classic Dark UI scammer behaviour. I don’t mind you asking me to donate towards Fritzing development. I don’t like you trying to trick me into paying.

This kind of behaviour is extremely alienating and makes me much less inclined to trust the developers, which I don’t think helps anyone.

trabalho2.fzz (3.2 KB)

Fritz.png1488x648 11.1 KB

Hello, I only have this part done, can someone help me doing the rest of the system?

Ty for the attention.

If you tell us what problem you are having we will likely suggest a solution. Off the top your two capacitors should be electrolytic not ceramic (ceramics typically don’t come as large as 10Uf.) Other than that, the parts all appear to be in core parts and just need to be placed. You are best to complete one view (probably breadboard) then carefully connect the rats nest lines in the other two views. It is possible by miswiring in another view to corrupt the sketch and have to start again, so keeping a backup of the last working sketch is a good bet.

Peter

hello, thanks for sharing .
i would love to get the fritzing part file to the WeMos D1 mini used, can u guide me on how to go about it. thanks

While I’m not the author of this thread, there is a wemos mini part here:

If neither of them suit, post a link to the board you have and I will see what I can find/ make.

Peter

Just tried it myself, not a fan of this either.