DRC rules aren't happy with my part

[CuriousJames]

So I modified the new Raspberry Pi connector @vanepp made so that I can ensure the board, mounting holes, and GPIO header pins all perfectly align (there are very slim margins!).

What I did was took his great part, and then added a board, and mount holes, in the sub mm perfect places, great work around I thought! I delete the ‘board’ group when I add the SVG to the pi connector part, and I delete the silkscreen and copper layers when I add the PCB Board design to Fritzing, I then set both the board and the part in the PCB view of Fritzing to exactly 0.000 (though there’s also a minor issue there too - for some reason they never actually take 0.00 on the x axis, they are either -0.001 or 0.003, but never more than 0.003 off what I want.

My Main issue, however, is that when I do my DRC when I think it’s all done it complains that traces are going over the pads that @vanepp made, but they didn’t when I used his part without modifications so I’m quite confused by that. I did nest copper layers, so just one, inside copper1 and 0, but I’ve also tried it with the two layers that @vanepp originally made, and that too brings the same issue on DRC.

Here’s the problem according to DRC:

Here’s the project that the above screenshot is from: Door Pi.fzz (197.4 KB)

Here’s the post where @vanepp submitted his part to the forum: Raspberry Pi 40pin Header and this is the part I’m using: https://forum.fritzing.org/uploads/short-url/vjZD8e7vWQOK6oFjDyglJsGaKZc.fzpz

Sorry guys, I really thought I had got a real handle on Fritzing now but this has quite thrown me.

If you’re able to help, that would be epic!

Thanks, James.

[CuriousJames]

Ahh, I’ve part cracked it - it’s only doing it for traces over 16mil, I don’t really understand why though?

I’d quite like a thick line to 5v and ground as the Pi can consume up to 2A so it needs a large trace.

I could also reduce the standard ones (24) to 16 but do I need to, is there really an issue here, or is DRC just failing? I.e. can I ignore these issues for now at least as I’d love to get this board made up (as soon as I tidy up the board a little more).

Thanks!

[microMerlin]

It is not the trace thickness causing the problems. I Narrowed one of the drc complaining traces to 8 mil and it still complained. However, when I added a via, and moved the complaining piece to the top board layer, it quit complaining even at 48 mil. Looking over the drc results ALL of the complaints (for the header part) are for the bottom layer. Which gives a place to look in the part definition and svg. If all of the copper0 is nested inside of copper1, it should not be an svg problem.

I have been doing some working on a couple of issues with drc, and this initially looked potentially similar. I ran your file through my development version, that fixes some things, and got the same (at least close) complaints. After checking for top versus bottom differences, if nothing shows up, I can run a slower debug test to find out the state in drc for the complaints. Tracing what is happening in drc is all set up, because of the other fix I was working on.

There are some unrelated drc complaints on other parts of the board that look real. Probably will get handled by that “tidy up” you mention, but here are some screenshots. I hope I left enough around the zoomed sections to match to the full board.

I extracted your part from the sketch file, and ran it through a checking (validation) tool. It did not complain about anything in the definition file and my quick scan did not notice any obvious problems. The relevant complaints are:

Warning 20: File
'…/svg.pcb.RaspberryPi Connector and Hat_00e45d2c131e75a2568c29ffe4cebaff_2_pcb.svg'
At line 28
copper1 layer should be at the top, not under group copper0

Warning 25: File
'…/svg.pcb.RaspberryPi Connector and Hat_00e45d2c131e75a2568c29ffe4cebaff_2_pcb.svg'
At line 122
Silkscreen layer should be above the copper layers for easier selection
in pcb view

Warning 23: File
'…/hat/svg.pcb.RaspberryPi Connector and Hat_00e45d2c131e75a2568c29ffe4cebaff_2_pcb.svg'
At line 124
Key -inkscape-font-specification
value 'Droid Sans, Normal' is invalid

Error 69: File
'…/hat/svg.pcb.RaspberryPi Connector and Hat_00e45d2c131e75a2568c29ffe4cebaff_2_pcb.svg'
At line 19
Found a drawing element before a layerId (or no layerId)

Only the last of that is considered to be an error by the tool, but it prompted a closer look at the svg file. Which discovered likely problems the tool was not noticing.

Warning 20:

    <g transform="translate(27.228583,7.6328196)" >
        <g >
            <g partID="858626900"  gorn="0.4.0.0" id="copper0">
                <g transform="translate(-0.84937993,0.42607221)" >
                    <g >
                        <g  gorn="0.4.0.0.0.0.0" id="copper1">

Having copper1 inside of copper0 is only a warning, but I also see that there is a transform between them. the copper1 layer is shifted a little relative to copper0, which I think could cause problems. There is nothing in cop0 that is not in copper1, so it should not be too bad. The transform around both copper layers is valid svg, but there are multiple reports that in some conditions Fritzing is not handling them properly. I also see a partID in there, which is not expected in a part itself. It is used in a sketch to track (potentially) multiple copies of a single part. I assume that got in there because you pasted something into Inkscape that that was exported from a Fritzing sketch. Cleaning up the groups and transforms described below will get rid of that too.

Warning 25: Self explanatory. The silkscreen layer/group is at the bottom of the svg file instead of the top. It also has an unneeded transform around the group.

Warning 23:

                <g stroke-width="1.0004" stroke="none" xmlns:xml="http://www.w3.org/XML/1998/namespace" fill="#000000" font-size="2.39999"  gorn="0.5.0.0.1" xml:space="preserve" fill-opacity="1" id="1Silk" style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:1.25;font-family:Droid Sans;-inkscape-font-specification:'Droid Sans, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;stroke-miterlimit:4;stroke-dasharray:none">

Somehow you got inkscape to specify the font strangely. At least strange for Fritzing, according to the checker tool.

Error 69:

    <g transform="matrix(1.0429448,0,0,1.0322221,-26.614969,1.3818347)" >
        <g >
            <g stroke-width="0"  gorn="0.3.0.0" style="stroke-miterlimit:4;stroke-dasharray:none" id="board">
                <rect stroke-width="0" stroke="none" rx="8.5301027" y="-1.338699" stroke-opacity="1" fill="#008000" height="160.65027"  gorn="0.3.0.0.0" ry="8.5301027" width="184.81889" x="25.518803" fill-opacity="1" id="rect2424" style="stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;"/>
            </g>
        </g>
    </g>

I have never used a board layer in a part. I do not know quite what is valid. Can definitely do without that wrapping transform. Did that maybe get carried in from wherever that partID came from? Or did you created it deliberately?

To get rid of all of the transforms, select the pieces and ungroup them. Multiple times to unwrap the various groups/layers. That will also remove layer definitions, so those need to be added back in after all the unwrapping. Before adding those back in, select everything in the drawing (as a block), and move it to coordinates 0,0. Then add only the needed groups back in.

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" y="0in" height="58.499996mm"  gorn="0" width="68mm" x="0in" viewBox="0 0 192.75534 165.82675" id="svg261">
>>> 192.75534/68
2.834637352941176
>>> 165.82675/58.499996
2.834645492967213
>>> 165.82675/58.499996*25.4
71.99999552136721

Your svg file dimensions are a little odd. Those values translate to about 2.83 pixels per mm, which is 72 px per inch. So fairly normal after converting through mm.

[CuriousJames]

Thank you so much!

So as I was saying I remove the Board layer when I add the SVG to the part, and I remove the silkscreen components (not the layer itself) and the copper layers when I save off the plain SVG for the board.

So I start with the Master file in Inkscape SVG formate:
I then save a copy as plain svg with those changes for the connector (part):
I then save another copy as plain SVG with those changes for the board:

So I went into the XML editor and adjusted the transforms, most layer ones are removed now, accept on copper0, copper0 is now nested inside copper1, but for some reason Fritzing part editor STIL says it cannot handle seperate copper layers, which is REALLY odd as they are not seperate, any ideas on that one?

DRC now doesn’t complain, it must have been those transforms of the incorrect nesting, so thanks very much!

Lastly I’ve setup those mounting holes as plated through holes, but even when I copy the pin connectors @vanepp made and adjust those they don’t show with the red hole in Fritzing, like other plated holes do, I can see in Aisler though that they are showing as a plated hole, but if you can tell me what’s going wrong there that would put my mind at ease.

Thanks again!

[CuriousJames]

Additionally I just found that the the issue of not being able to place the board and part exactly on 0 x and y axis has cleared up, they now both sit on 0.000 and 0.000 when I tell them to place at 0. So that must have been due to the layer translations I guess?

Thanks, James.

[microMerlin]

@CuriousJames

Fritzing part editor STIL says it cannot handle seperate copper layers, which is REALLY odd as they are not seperate, any ideas on that one?

Nothing obvious. I don’t use the parts editor. I build the parts manually by editing the parts defining in (raw) xml.

@CuriousJames

Lastly I’ve setup those mounting holes as plated through holes, but even when I copy the pin connectors @vanepp made and adjust those they don’t show with the red hole in Fritzing, like other plated holes do, I can see in Aisler though that they are showing as a plated hole, but if you can tell me what’s going wrong there that would put my mind at ease.

Nothing obvious here either. In general, for that sort of checking, we would need a copy of the created part, or a sketch with the part in it. To look at the details of pieces.

@CuriousJames

So that must have been due to the layer translations I guess?

Likely. The transforms mean that Fritzing has to calculate where the part actually ends up, based on the transform and the element coordinates. That calculation is often not exact. The rounding error can accumulate enough to notice in the displayed coordinates. The units specified for the file can also play into that. Fritzing has to convert (scale) every part to match the sketch file. More calculations that are often not exact. The fewer manipluations like that that are needed, the better the chance that the final numbers will land where you want/expect them to.

[vanepp]

@CuriousJames

Lastly I’ve setup those mounting holes as plated through holes, but even when I copy the pin connectors @vanepp made and adjust those they don’t show with the red hole in Fritzing, like other plated holes do, I can see in Aisler though that they are showing as a plated hole, but if you can tell me what’s going wrong there that would put my mind at ease.

Sorry for the late reply ( my network connection is dead and I am on a borrowed machine at the moment), the mounting holes are just holes, they don’t (or shouldn’t) have a connector id. Thus Fritzing doesn’t change them to red as they aren’t a connection but if you set a non zero copper ring they should be plated through (which it sounds like they are) although you don’t necessarily want plating through on mounting holes (to eliminate it set the ring width to 0). As to your pads, I just got back the boards I made with the new pads here:

Through Hole Help

I had started modifying the parts factory code to fix a bunch of things (incorrect scales, overly complex svg, too long pins) before getting distracted by trying to restart development. When I get back to it, I intend to fix double sided headers in breadboard (they are currently broken), add options for 2mm , 1.27mm and 1mm headers (with the correct pads sizes, as you can do 2mm now if you adjust the pad size in Inspector) and a choice of oblong pads for all of headers, the generic ICs and the …

and they appear to work fine. You may want to switch to them. They are smaller than the ones in the original shield but allow stacking connectors and will route a standard width trace between pins without drc complaints.

Peter