Not sure what you mean by saying that the silkscreen should be on a lower layer than copper. I believe I did change the silkscreen lines to stroke="#ffffff".
The order of the layers in the fzp file should not matter, but the silkscreen should be “behind/below” the copper graphics. Which actually means it needs to be “before” the copper in the svg file. That is do to the way svg (and Fritzing) implement search and selection from the mouse coordinates. That selection starts from the “top” layer, which means “later” in the svg file.
Since the connectors are smd, not tht, the fzp file should show only copper1 for them (in the individual connectors). Putting them on both, as I initially indicated, tells Fritzing that they are THT connectors. The copper0 is (I believe) needed for (only) the main view definition, so that Fritzing will generate holes for the circles on the (combined) copper1 and copper0 layers in the svg file.
The issue with copper bottom, is probably the copper1 and copper0 combination on what is intended to be smd connectors. Whatever connector(s) have a “GND” name will be used as seeds for copper fili / ground fill, which is separate.
We decided years ago that everything should be below connectors(higher in the XML), because it was hard to select pins when assigning them in FZ when there was an object blocking it.
If copper0 is in copper1, you put THT in copper0, and SMD in copper1. If you are doing a SMD, which doesn’t need copper0, you still put an empty copper0 in copper1 or FZ will give an error when you try to load the part.
I though the “GND” was a thing too, but it actually seeds whatever Net you select to GND seed.
I though the initial ground seed would be one that is marked as “GND”, or connected to a schematic view ground connector. That can be changed by explicitly setting a ground seed.
Yeah that’s what I thought, but in the vid I select a row of random header pins connected together, and they all seeded. GND seed is obvious, but I guess it’s so you can do a PWR plane.
I plan on getting started on the BME280 footprint but wanted to ask about another part in the pipeline, the QG-2864KSWEG02. https://statics3.seeedstudio.com/images/opl/datasheet/308020028.pdf The OLED’s PCB connector footprint is surface mount ribbon/zif cable like and 27 “pins”. Any recommendations as to what should I use as the starting point?
Make sure you do a Goo image search for the Fritzing part, or might might be wasting your time.
I assume the ribbon is for the BB view, so I would do an image search for - ribbon Fritzing. If there is one I would get that svg, mod it, and add it to my drawing. I’ve got vid tutorial here that shows you how to get other people’s svg to add to your svg.
The different top and bottom connectors were the main issue here. The edge connector case as you note needs them to be separate and this is the only way I know of to achieve that. I did realize that I could do the copper1 only smd pads but that doesn’t work for edge connectors.
Peter
Here’s my first run at the BME280lga, I have yet to install the parts checker so I’ve yet to determine what I did wrong so far: BME280lga.fzpz (4.5 KB)
P.S. #ffffff is white, #000000 is black sorry about my mistake earlier.
I see 2 ways. The way you described, which keeps copper1 and copper0 groups totally separate, then duplicates each of the connector pin (or pad) where they are actually THT, or use the standard copper0 inside copper1 for the THT connectors, and duplicate the copper0 (initially copper0a) group outside of copper1 for the top only smd pads. That way, none of the connector pins is duplicated. Just the copper0 group, one inside copper1, the other outside. Which is a one line fix (change “copper0a” to “copper0”) after finished editing with Inkscape. Instead of needing to remove that suffix from every duplicated tht connector pin.
Ran the parts checker. It seemed to be fine with the schematic. It thought that the part is through-hole due to the empty nested copper0 in the pcb. It didn’t seem to like another nested group early on in the breadboard but mine was based on a sparkfun part that worked. In the fzp, there was a locating issue that was confirmed by some messing around and freezing of fritzing. Still not sure what my error was in the 4 xml files that I text edited. However, I used the parts editor to load the 3 svgs and to create an fzp without the error and sure enough it worked: BME280r2.fzpz (5.5 KB)
As best as I can tell, the best starting footprint for the https://statics3.seeedstudio.com/images/opl/datasheet/308020028.pdf is by choosing a generic header, choosing an un-shrouded format, choosing single-row, choosing SMD, choosing 27 pins, and choosing 1.27 mm spacing. This provides: smd_single_row_pin_header_27_50mil_pcb.svg
I tried a couple SMD parts from CORE bin, and yeah, FZ does complain about empty copper0. What can we put in there that it will accept, but won’t come out on a PCB.
EDIT - I tried about 20 things - I even made a new PCB svg -, and I can’t make it not error.
EDIT EDIT - Ahh now I get it. The part is ok, it’s the PCB that it doesn’t like when you export the gerbers and there is nothing on the other side of the PCB. I switched it to single side and it’s fine.
Thanks! I’ll poke at this and see if it is a better way to do what I want. A single rename would be a lot easier …
Edit: I poked at this and have come to the conclusion that the best way forward is to modify FritzingFixPart.py to detect a pcb svg of the form svg.pcb.part_name.pcb-ink.svg that has separate copper0 and copper1 groups with different ids (for Inkscape) such as connector0pin in copper0 and connector0pin- in copper1. This svg will render correctly in Inkscape (but not Frtizging) and get copied in to svg.pcb.part_name.pcb.svg by FritzingFixPart for Fritzing then have the connector0pin- id changed by FritzingFixPart in to connector0pin leaving connector0pin in both copper0 and copper1 for Fritzing. This is what FritzingFixPart is supposed to do, modify things that Inkscape wants that Frtizing doesn’t.
Peter
I’ll have a look at the data sheet and see (and post) what I would do to make the part.
edit: here is how I would make this part:
That will do for pcb, but OLED-128x64-I2C-Monochrome-Display-fixed.fzpz which has the breadboard for the display (except it is I2C and thus has only 4 connectors) is the best place to start in breadboard. Assuming you want all 27 connections (as opposed to a breakout board as in the original part) add a 27pin header on .1 centers to breadboard and making a new schematic is likely the correct answer. I would also consider using a 27pin fmc type zif connector so the display plugs in (as opposed to soldered down) unless you are making a lot of them. Use the fzp file from the smd_single_row_pin_header_27_50mil_pcb.svg part and modify the description fields to reflect the new pin names. It would also be possible to make a breakout board similar to the OLED-128x64-I2C-Monochrome-Display-fixed.fzpz by making the necessary connections to the fmc connector in pcb (although that is quite a bit more work.) Here is a copy of the OLED part (it is in the forums here somewhere as well!)
OLED-128x64-I2C-Monochrome-Display-fixed.fzpz (9.0 KB)
Peter
The part is mostly fine. The only FritzingCheckPart.py warning (which should be an error likely) is that needs fixing is this one:
Warning 14: File
‘part.bme280r2_74a038ffa500481f218ed97c5f41f4aa_10.fzp.bak’
At line 154
terminalId missing in schematicView (likely an error)
it is currently only a warning because in some rare circumstances the terminalId isn’t required, but since having a terminalId isn’t harmfull, I think makiing it an error is a better bet. I’ll correct that in the new version of FritzingCheckPart. The lack of the terminslId in connector8 in the fzp file part.bme280r2_74a038ffa500481f218ed97c5f41f4aa_10.fzp causes this error:
to correct it you need to add the terminalId field to the fzp file:
connector8 (wrong):
<connector name="VDD" id="connector8" type="male">
<description>VDD</description>
<views>
<breadboardView>
<p layer="breadboard" svgId="connector8pin"/>
</breadboardView>
<schematicView>
<p layer="schematic" svgId="connector8pin"/>
</schematicView>
connector3 (correct):
<connector name="SDI" id="connector3" type="male">
<description>SDI</description>
<views>
<breadboardView>
<p layer="breadboard" svgId="connector3pin"/>
</breadboardView>
<schematicView>
<p terminalId="connector3terminal" layer="schematic" svgId="connector3pin"/>
</schematicView>
connector8 needs to be
<p terminalId="connector8terminal" layer="schematic" svgId="connector8pin"/>
as the correct element is already in the schematic svg. Otherwise FritzingCheckPart shows all warnings, so the part should work fine. The output below is from a later version (not released) of FritzingCheckPart and thus has some extra warnings from the version you used. Note warnings won’t break Fritzing, only Errors indicate something known to make the part not work is present (except for the case above!) That said, connectors in Fritzing should start from 0 (not 1 as in this case) and increase in sequence. The scale of the svg should be 10.41667 (in Inkscape, other editors may be different!) not 0.25794 as pcb and schematic currently are. The part is SMD and thus doesn’t need copper0 so that group can be deleted.
Peter
May want the reverse code too. To be able to take the Fritzing compatible image, and turn it into something that Inkscape can work with.
You are right, I was assuming you would have the original Inkscape part first, but if you only have the fzpz an option to create an Inkscape friendly version of the pcb svg would also be useful.
Peter
Looks fine as is! It isn’t a core part as it lacks breadboard and schematic, but I assume you only needed the pcb layout and that looks fine.
Peter