Problem with PCB svg

just_randy · March 16, 2020, 5:23am

Hi all,

I am working on creating a fritzing part for this item:
https://www.tindie.com/products/avandalen/sam15x15-arduino-zero-compatible-samd21-board/?pt=ac_prod_search

In the parts editor, the svg for the breadboard works, however the svg I created for the PCB view isn’t working. When I load the pcb svg, I get the error message:
"This version of the new Parts Editor can not deal with separate copper0 and copper1 layers in ‘filename’ "

I get what the error message says, but I’m not seeing the problem with my svg file. It has a copper0 group that contains a copper1 group that contains all the graphics for the copper layers. Here’s my svg:

https://drive.google.com/file/d/1TrGdl085mUMNI5vKOYZ42eDDJ8OZQC1r/view?usp=sharing

As far as I can tell, I have the copper0 group that contains the copper1 group as it should be. If anyone can tell me where I am going wrong, I’d really appreciate it.

Thanks
Randy

vanepp · March 16, 2020, 4:27pm

The svg looks correct, other than copper1 and copper 0 should be reversed (i.e. copper1/copper0 not copper0/copper1) but I don’t think that is what parts editor is complaining about (although since I rarely use parts editor I’m not sure, so trying it may be a good bet). The usual cause of that complaint is

g copper1
g copper0

at the same level which is legal in Fritzing but not in parts editor. Another thing to try would be in Parts editor “File->save as new part” to create a part without your svg in it to the mine parts bin, then right click the part, and select export part to get the fzpz file. Then unzip that and rezip it with your pcb svg file replacing the pcb svg and see if that fzpz file loads correctly (as I think is should.) If that dies, post the failing fzpz file and I can tell you what is wrong with it.

Peter

just_randy · March 16, 2020, 7:57pm

Thanks Peter for taking a look and your advice, I will work on this and post back.

However, in this thread that you helped me with:
https://forum.fritzing.org/t/2-8-spi-lcd-part-creation-help/7851/7
You said I had the same problem with copper1 & copper0 reversed. I made these .svg in inkscape, not using a template, but from scratch. I did however use a template as reference. The template I’m using for reference I downloaded from here:
http://fritzing.org/fritzings-graphic-standards/download-fonts-and-templates

That template has this structure:

+silkscreen

-copper0

  +copper1

+keepout......

Showing copper0 as the top most copper group. If the top most copper group should be copper1, perhaps those files should be updated. However, I will keep this in mind, and perhaps update my copy of those files, so I don’t do this again.

I’ll let you know how it works…
Randy

vanepp · March 16, 2020, 8:05pm

Yes the templates need work. Much worse than the copper order is that the svgs are dimensioned in px and scaled as 72dpi old Illustrator which causes scaling problems with Inkscape. I don’t know that Fritzing actually cares about the order of copper1 and copper0 as long as both are there, but copper1 is the only group for a SMD part and copper0 below it seems a better bet.

Peter

just_randy · March 16, 2020, 8:25pm

Your trick worked! I appear to have the correct pcb view of the part now. Can you explain why it failed and how your fix sidestepped this?

Good to know this tid bit as I have made a SMD relay, I will have to recheck it now.

I wish I had the time to donate to help update things like the website, and templates, and stuff…

Thanks,
Randy

vanepp · March 16, 2020, 8:34pm

Unfortunately no without actually looking in the source code, I’m actually surprised it worked. Either something in the source cares about the copper order (but I know of parts that work fine with the layers in the wrong order) or it was checked in Parts editor to enforce future correctness for some reason. Anyone that would have known has likely moved on at this point so the source is the only place to look and it isn’t easy to understand. I’m just glad the simple fix worked!

I’m luck enough to be retired and thus have time to do things that interest me, but we do need more people (or more donations to pay for developers) to keep Fritzing going. The current theory is the code base is to complex to expect volunteers to work on it so the donations are aimed at funding professional developers to complete Fritzing (which was the original goal in 2016 too)

Peter

just_randy · March 19, 2020, 1:40am

We should sit down and talk about this sometime, exchange ideas, etc…

Anyway, your trick on the pcb.svg worked until… I reloaded it into the parts editor, then I get the error message again. So I keep working on the part, adding in the schematic svg and stuff. Now that I’ve added in the schematic symbol, I have a new problem.

I startup fritzing, remove the breadboard and drag in my new part. Drag in a resistor and connect it to 2 pins on my part. Check schematic view, everything is fine. Start fritzing again, remove the BB and drag in my new part. Switch to schematic view and the symbol is rotated 90 degree clockwise. Any ideas on what might be causing this?

I can post the files if needed…

Randy

PS - the error about copper layers for the pcb.svg appears to have no effect, the part does appear correctly in pcb view, and gerber output appears correct.

vanepp · March 19, 2020, 4:30am

Assuming you dragged the part in to breadboard first, this is a bug. Fritzing does not appear to copy the orientation of the part in to schematic (or I think pcb) when it is dragged in to breadboard first. I’m fairly sure this is a parameter not being passed between the views but I haven’t yet been able to find it. If you drag the part in to schematic first the alignment will usually be correct even in the other views, but dragging the part say 10 times in to breadboard will get a random set of alignments in schematic (some correct some rotated.)

by all means post the .fzpz file and I’ll check it over and see if I find anything. It sounds like the parts editor complaint is likely a parts editor bug, although I don’t remember hearing of it before.

Peter

just_randy · March 20, 2020, 3:05am

ok, here’s the part:

28x28mm SAMD21G.fzpz (94.3 KB)

Please run it thru your ‘crystal ball fix it’ thing that fixes stuff… I know the font size is in px, but I think everything else is in order. I was going to redo the schematic & pin definitions to be more inline with the documentation on seller’s website, but why bother? Chances are, I will be the only user around here that will ever need this part.

To borrow a hockey term… I think I just cross-checked my OCD…

Thanks,
Randy

vanepp · March 20, 2020, 6:19am

OK a few problems:

bb

remove the image which doesn’t do anything (here I moved the image down about an inch to see what was in it.) This won’t hurt anything and so could be left in.

pcb

group 183 is unneeded (and likely what is causeing Parts editor to complain)

copper0 has a transform that isn’t in copper1 (which will likely cause problems in gerber output if the part is moved to the bottom of the board) so ungroup the whole thing to remove the transforms then regroup it.

The pad holes are likely too small. The calculation is hole diameter = pad dia - (2 * stroke-width)

currently that is 0.068 - 40 = 0.028in hole a standard IC hole is 0.035 so change the radius of all the pads from the current 23.779499 to 27.5 (giving a 0.075 pad diameter and a 0.035in hole) without moving the x/y coords of the pads.

schematic

removed several layers of redundant groups (from parts editor) otherwise unchanged.

fzp

    <breadboardView>
      <p svgId="connector0pin" layer="breadboard" terminalId="connector0terminal"/>
    </breadboardView>

should be

    <breadboardView>
      <p svgId="connector0pin" layer="breadboard"/>
    </breadboardView>

as there are no terminalIds defined in the breadboard svg. Didn’t change them because Fritzing will ignore them (and I am lazy ) and us the center of the pin as the terminalID which is fine in this case.

Built a test file (incomplete in this case due to laziness again ) that makes sure the schematic terminalId is correctly at the end of the pin (I assumed the others were correct):

If your terminalIds are not correct the wire won’t terminate at the end of the pin. They are correct here and I assume also on all the rest of them. Then export the gerbers for the test sketch and edit the drill.txt file to check the hole sizes are correct:

from the drill.txt file:

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

The 0.038 holes are for the headers and the 0.035 holes are for the IC holes as desired.

The corrected part (I was too lazy to change the moduleId and file names so you willl need to unload your current part to load this one or change the moduleId and file names of the svgs to be unique to load them together)

28x28mm SAMD21G-fixed.fzpz (28.1 KB)

and the test sketch

test-Sketch.fzz (30.9 KB)

Peter

just_randy · March 20, 2020, 11:20am

Oopps, forgot that was still in there.

Not sure how that group got in there. Same for the transform, not sure how that got in there.

As to hole size, I had the same problem with the 2.8 lcd touchscreen. So I looked into this and apparently it’s because I’m using inkscape .91, (outdated OS, can’t upgrade). In your screenshots, inkscape shows the copper0 group is 103.488 px, in my inkscape the copper0 group is 97.059 px x 97.059 px.

I did create the pads to be .078 in size with a .02 stroke, which should have given me .038 holes. Must be the changes in dpi between inkscape .91 and inkscape .92 causing the problems.

Anyway, thank you for helping fix up the part for me!

Randy

PS - Above you mention that copper1 is for SMD, so all contacts for a SMD part should be in the copper1 group?

vanepp · March 20, 2020, 6:06pm

The group must have been you or the parts editor, I’ve never seen Inkscape do that for itself. The transform was probably Inkscape, it loves them , if you moved a pad without ungrouping Inkscape will likely do it with a transform. I usually ungroup everything, make all my changes and then regroup. Alternately when finished just before saving you can ungroup everything (which will usually remove the transforms) then regroup. A PITA but it works.

Because the svg is dimensioned in inches (I checked, but FritzingCheckPart would have tossed an error if it was not), that shouldn’t be the cause. 0.91 uses 90dpi as the resolution, and (I think!) 0.92 and later are 96dpi which is why the different px values, but as long as the dimension is inches the values will be correct so that doesn’t explain the wrong hole sizes. The main thing you lose with 0.91 is being able to adjust the scale (0.91 didn’t have the scale box in document properties.) The stroke width was correct at 20, the change was in the hole diameter (which translates to w and h in the top tool bar) was smaller than 0.078in (I set it to 0.075 to give 0.035 holes, if you want 0.038 holes for .1 headers change the radius in xml editor from 27.5 to 29 for each pin in pcb, that expands the pad around the center without changing the x/y coord of the pad.) It could be that since I use 0.94, that Inkscape didn’t detect this was a 90dpi part and didn’t translate correctly between 0.91 and 0.94. You should probably check the results are correct when you edit the svgs with 0.91 in case the inverse is also true. The best way to check hole sizes is to export the part as gerber and read the gerber drill.txt file to see what drill sizes it specified.

Yes, for an SMD part there should only be copper1 (no copper0) with all the pads in it. If you use copper0 the part will appear on the bottom of the board by default (and something may break in Fritzing as well.) Mixed parts (through hole and smd in the same part) are possible but non standard and has some limitations (parts editor can’t deal with them for one, and moving them to the bottom of the pcb no linger works correctly.)

Peter