thx for your quick reply!
32418398-7b8d7cf6-c269-11e7-9a2a-7aa3a58e50c0|690x391

This should do what you want. Note the mounting holes in pcb are only in silkscreen, so if you want mounting holes you need to drag 4 holes (set to 3mm) in to the sketch (from the pcb section of core parts) and place them over the holes in silkscreen to actually drill the holes in the pcb.

hx8357.fzpz (9.0 KB)

Peter

Humble apologies for not responding ordered 250 of the boards as they were am about to amend the layout as you suggest for the next batch which we will need in january thanks for all your help the products are going well.

Donald

Hello,

I created 10 PCBs with a Sound Module FN-M16P and used this Libary for the sound Module: http://fritzing.org/projects/dfplayer-mini-part

I think this is the same part but only the name is not correct.

Now i got the PCBs and the drills of that part are to big and there is no copper around them. I rechecked with flatcam the generated drills file and the drills are 1,44mm instead of 0,8. So there is no copper around them.

Has anybody an idea why i got this error? Also opened the SVG files and checked, that copper has correct color.

Anyone know how to fix that issue?

Thanks a lot.

While the referenced part is broken, it appears to generate correct holes and pads (0.035in holes) and pads in a geber output:

Capture875×598 2.25 KB

The top one is the referenced part, the one under it is the dfrobot version (which is more correct) from core parts. Either of these should create boards with pads. If you upload the .fzpz file of the part you used I’ll have a look at it. You should always check the gerber output with a gerber viewer (paying particular attention to the hole sizes in the drill.txt file) before ordering boards.

Peter

Hello Peter,

thanks for that fast response. Here is the file i used.

Everything seems correct in fritzing but in gerber not.

Thanks HeikoDFRobot-DFPlayer-Mini(1).fzpz (12.9 KB)

Thank you Vanepp. I have Uninstalled and re-installed Fritzing and the top view parts are now being imported correctly.
Best regards
Carlos Castanheira (Porrapai) South Africa

Your part is incorrect. The pcb svg has no stroke width defined, and thus the hole size is the same as the pad size. It shows correct in Fritzing but the gerber output is wrong. The solution is to use the version of the part in core parts (I had to modify yours to be able to load it, as it conflicts with the one in core parts.) If you type df player in to the search bar in the parts bin the one i core should come up. If it does not, you likely need to update your parts. There appears to be a bug in Fritzing that will load conflicting parts, so you may need to do a delete minus of the current part in your sketch (which will delete the part, but leave the traces present), save the sketch, then reload it (to remove the part from the temp parts bin) then use the one in core parts.

Peter

Good, if you run in to more problems feel free to ask.

Peter

Okay now I updated my libary and used the correct one. The other file I downloaded at fritzing parts page. With the core file it works fine. Thanks for your help

this is a continuation of

Here we are going to look at creating parts with schematic subparts. The purpose of schematic subparts are to allow elements of a multi element part (such as a dual op amp or a hex inverter) to move around schematic independently. I will use the 74x125 quad tristate buffer as an example of this. We will look only at the schematic svg and the fzp file as they are the only two files that are affected by this. Note that schematic subparts block the use of buses in the same part, I don’t know why and fixing that is a desirable enhancement but at the moment, subparts block the use of buses. First the 74x125.fzpz file so you can load it in to Fritzing and see what it does, and unzip it to get the fzp and schematic svg files that make up the part:

74x125.fzpz (9.6 KB)

Then an illustration of the standard part (top) and the standard part with the subparts moved independently to demonstrate their use:

example-schematic880×724 53.2 KB

as we see each of the 4 parts in the package can be moved independently of any of the others. So let us look at how to configure this (note, you must edit the fzp file via a text editor as the Parts Editor does not currently support subparts.) Lets start by looking at how the schematic svg needs to be laid out.

schematic-svg754×574 94.8 KB

This is fairly simple, the power and ground connections are one independent element in a group called subpart0, The 4 individual gates are contained in 4 groups called subpart1 to subpart5 (with more elements in additional groups if needed.) All the elements of a group need to not overlap the elements of another group. Here is subpart1 (the first independent element) as an example of this. Note all parts of the element including the connections are enclosed in the group.

subpart1839×653 125 KB

Now we move on to the fzp file which is the other place that requires configuration. The connector section is standard, like any other part, 14 connectors in this case:

....
<connectors>
 <connector id="connector0" type="male" name="C1">
   <description>Control 1</description>
   <views>
     <breadboardView>
       <p svgId="connector0pin" terminalId="connector0terminal" layer="breadboard"/>
     </breadboardView>
     <schematicView>
       <p svgId="connector0pin" terminalId="connector0terminal" layer="schematic"/>
     </schematicView>
     <pcbView>
       <p svgId="connector0pin" layer="copper0"/>
       <p svgId="connector0pin" layer="copper1"/>
     </pcbView>
   </views>
 </connector>
 ....
 <connector id="connector13" type="male" name="VCC">
   <description>VCC</description>
   <views>
     <breadboardView>
       <p svgId="connector13pin" terminalId="connector13terminal" layer="breadboard"/>
     </breadboardView>
     <schematicView>
       <p svgId="connector13pin" terminalId="connector13terminal" layer="schematic"/>
     </schematicView>
     <pcbView>
       <p svgId="connector13pin" layer="copper0"/>
       <p svgId="connector13pin" layer="copper1"/>
     </pcbView>
   </views>
 </connector>
</connectors>

After the connectors are defined we now have a new optional section of the fzp that defines the subparts. It looks like this:

      <schematic-subparts>
        <subpart id="subpart0" label="">
          <connectors>
            <connector id="connector6"/>
            <connector id="connector13"/>
          </connectors>
        </subpart>
        <subpart id="subpart1" label="1">
          <connectors>
            <connector id="connector0"/>
            <connector id="connector1"/>
            <connector id="connector2"/>
          </connectors>
        </subpart>
        <subpart id="subpart2" label="2">
          <connectors>
            <connector id="connector3"/>
            <connector id="connector4"/>
            <connector id="connector5"/>
          </connectors>
        </subpart>
        <subpart id="subpart3" label="3">
          <connectors>
            <connector id="connector7"/>
            <connector id="connector8"/>
            <connector id="connector9"/>
          </connectors>
        </subpart>
        <subpart id="subpart4" label="4">
          <connectors>
            <connector id="connector10"/>
            <connector id="connector11"/>
            <connector id="connector12"/>
          </connectors>
        </subpart>
      </schematic-subparts>
    </module>

The layout is similar to buses. Each subpart has a label (which needs to match the group id in the svg file) and a list of the connectors that make up the subpart. The connectors can only be in one subpart and as noted the part can not (at present at least) have buses defined. One drawback of subparts is a lot of them (around 10 to 12) in a sketch will start to slow rendering down. Presumably the more subparts present the slower rendering will become. However for some parts (such as logic buffers in this case and dual or quad op amp parts) they are very useful and not that difficult to create once you know how. The FritzingCheckPart.py script understands and will catch configuration errors (in the fzp file only, not the svg so much) to help keep things straight.

hello
. excuse me ,could you get the models of ramp 1.4 board and 128*64 lcd display ?

There doesn’t appear to be a fritzing part for the ramps 1.4 board (although there are eagle files so one should be fairly easy.) A google search for “fritzing part 128*64 lcd display” turns up several parts, but you would need to check if they match what ever display you have, and if not provide a pointer to a data sheet for the display you want.

Peter

I have just tried to submit a new part via GitHub (https://github.com/fritzing/fritzing-parts/pull/230), but the checks fail with “Travis CI build could not compile”. This is the first time I’ve submitted anything through GitHub, so I’ve really no idea where my problem lies.

The critical part of the Job Log appears to be:

[0K$ go get github.com/fritzing/fzp/bin/fzp
# github.com/fritzing/fzp/bin/fzp
../fzp/bin/fzp/command-create.go:13:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:18:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:22:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:27:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:31:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:36:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:40:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:44:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-create.go:48:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-encode.go:15:16: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
../fzp/bin/fzp/command-encode.go:15:16: too many errors
travis_time:end:22c23b48:start=1577795887819766211,finish=1577795895145004674,duration=7325238463,event=install
e[0Ke[31;1mThe command "go get github.com/fritzing/fzp/bin/fzp" failed and exited with 2 during .e[0m

Your build has been stopped.

I do have a programming background, but I have no idea what these error messages might mean in relation to either my part or the submission process. Can anyone direct me to something like a Troubleshooting Guide that might help me work out what’s going wrong?

(I have actually tried to submit three new parts, and the submissions all fail in exactly the same way, so I am at least being consistent with what ever it is that I’m doing.)

Thanks

Welcome aboard! People making parts are always most welcome. Unfortunately documentation is a major lack. Questions in here or on github are the usual solution. It looks like you have hit a bug in the TravisCI checks (which are brand new, development had stopped around 2016 and is just restarting and the build chain had to be completely rebuilt.) It is likely caused by something invalid in the part .fzp file. The easiest fix is to post the .fzpz file for the part here and I’ll have a look at it and see what is wrong. To get a .fzpz file in Fritzing right click on the part in the mine parts bin and select export part which will write a .fzpz file. Upload is 7th button from the left in the reply menu. An alternative is to run your parts through the FritzingCheckPart.py script available here:

which will check for common errors and syntax errors in a part. However the output depends on you knowing what the correct xml should look like which is not necessarily easy.

Peter

Thanks Peter. I’ve had a quick look at the FritzingCheckPart.py stuff and I see that there’s a fair bit to get around there so let me take the easy way out this first time around and just post the part for you to look at.

As noted, I have three parts to begin with. They were all created, starting with the Fritzing templates, using Illustrator. The only thing I can see from reading the FritzingCheckPart documentation is that maybe I didn’t create the square PCB pads correctly (because there wasn’t one in the template). I also had to ‘fiddle’ with the ‘copper0’ and ‘copper1’ layer order to get the part accepted by Fritzing in the first place, so that is another deviation from the PCB template that might be a problem.

Anyway, I’ve just attached the one part for the moment. I’m pretty confident that any problem will be the same in all the parts I have created so far.

Thanks

Heltec WiFi LoRa 32.fzpz (38.1 KB)

I think this may be a tool chain problem rather than yours. Your part looks by and large fine, and I don’t see anything that should cause the errors you are seeing. One problem I didn’t correct is the pins are not in sequence (pin1 is missing, there is a bug in parts editor where it skips pins.) The only thing that may effect is the hover on the pin to get the label function. In (I think only subpart parts which this is not) that screws up if the numbers are not in sequence. Breadboard and schematic lack layerIds , but all that affects is svg export (the part won’t show in a svg export.) PCB looked fine (other than the holes are likely too small for .1in headers). In this part I rescaled all the svgs to be the standard (which will make no difference to Travisci, it doesn’t check scale), changed the pcb pads to have 0.038in holes suitable for .1in headers and removed one bus (gpio17 to connector pin 1 which doesn’t exist, gpio17 doesn’t look like it should be bused to anything.) I also ran it through FrtizingCheckPart.py which inlines styles (which Fritzing sometimes doesn’t support) and removes px from font-size (which causes font-size to be set to 0 on a parts editor edit). The original file only has these two errors and the second isn’t actually an error in this case, the lack of a terminalId will be ignored by Fritzing as will the missing bus member:

Error 53: File
‘part.HeltecWiFiLoRa320000_60af58a4a22947c531eac6e81f836375_22.fzp.bak’
At line 601

Bus nodeMember connector1 does’t exist

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

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

svg svg.breadboard.HeltecWiFiLoRa320000_6af188b3115e879b6ec332508a4ec538_3_breadboard.svg.bak

Here is the improved part, you can try running it through travisci and see if it is any happier, but I don’t see why it will be.

Heltec WiFi LoRa 32-improved.fzpz (37.0 KB)

Nice job on the part! If as I expect travisCI still complains, you need to log a bug on github to get the developers to look at why TravisCI is failing.

Peter

Thanks Peter, but whatever change has been made has had a knock-on effect in that the Stroke Weights are no longer correcetly interpreted by Illustrator. I had noticed this with other parts that I originally tried to use as a template for what I was doing and finally decided that I would be better off starting from scratch. At one level this is not a problem, because I don’t ever modify the .svg files when making changes, I generate new versions from the ‘parent’ Illustrator file, which then has me worrying that this problem is going to surface every time I amend a part (if I can’t work out what to do either up front in Illustrator, or within the Parts Editor during the creation process).

On the specific error noted, i.e. the absence of a ‘connector1’, I noted that when I created these parts, Fritzing would indeed start with ‘connector0’ when defining connectors, but would always skip ‘connector1’, so that while ‘pin1’ was always ‘connector0’, ‘pin2’ became ‘connector2’ and so on.

I’ve just checked this again now. I started defining a new part, as I believe was recommended somewhere, using a standard Fritzing part (the 8-pin IC) as the base. When I got to defining connectors, due a completely different problem I encountered early on, I didn’t just replace the 8 with the new number (36 in this case), I erased all the connector descriptions first by entering 1 (0 didn’t work), then I entered the desired number (36 in this case).

I do now note that if I just replace the 8 with 36 the new connectors are created and the sequence ‘connector0’, ‘connector1’ etc. is retained, but if I first enter 1, whereupon we end up with just a single connector, correctly identified as ‘connector0’, and then enter another number, 36 in our case, the new connectors that are created, after ‘connector0’, start with ‘connector2’ and skip over ‘connector1’.

Interestingly, I’ve also tried this with the first four parts in the ICs section of the Core Parts—IC, atmega168, LM 358 Dual Op-Amp and 555 Timer—and all but the atmega168 part display this behaviour. If I set the number of connectors to 1, then to 36, ‘connector1’ is skipped. Curiously, if I do the same with the atmega168 part, first enter 1 then 36, the correct numbering is retained. I’m using Fritzing 0.9.3 on OS X 10.11.6. if that makes any difference.

This behaviour seems to be repeatable, and may be where things need to be fixed.

Any comments?

I use Inkscape rather than Illustrator (mostly because as Inkscape is open source, most folks use it) and I normally don’t use parts editor because I find it easier to edit the fzp file directly. If I don’t have a suitable part I usually use a generic IC of the appropriate number of pins (because its svgs are the correct scale from Fritzing) or a generic header (whose scale is not correct) if it is an odd number of pins. In both cases the part factory will generate the pins with the correct sequence, it is only parts editor which will generate missing pins as far as I know. Illustrator may not be happy with something Inkscape did to the svgs, although I don’t know what exactly.

Peter

OK, having now looked at the structure, I think I’d be comfortable working with the .fzp file directly, but how are the ‘linkages’ between the .fzp and .svg files created? The .svg files I feed into the Parts Editor don’t have any connector labels as such, but I note that the ones extracted from the .fzpz file do. The Parts Editor presumably does something in the background when I ‘Select graphic’ for individual pins. Should I just go and read about that somewhere, or just keep askling quesitons here?