Mid-Mount SMD Part Creation


#15

I regret to say that it is not working correctly. When I add the part to my project the PCB view looks like this.

I can’t click on any of the connectors.

Here is the part that I have created. It worked great until I switched the copper layers and now there is the big red bar across it which prohibits me from connecting to the connectors.

Generic female header - 23 pins.fzpz (7.9 KB)


#16

That is likely because you have transforms in the pcb svg. The gerber code is not all that xml aware and has a few issues (not processing inheritance and not processing transforms being two of them). To fix this I edited the pcb svg in Inkscape and changed the fill on the text from #ffffff to #000000 (from white to black so I can see it to make sure it doesn’t move as the translates are removed), then ungrouped everything under silkscreen to leave only the three paths and the 2 texts (no groups) as well as the group containing the group silkscreen. At this point silkscreen still has a transform though, so now select the group silkscreen and ungroup then immediately regroup it. That removes the translates on the ungroup and regroups silkscreen (without the transform this time). Now do the same to copper1 and copper0 (copper0 has a bunch of subgroups as well). If you look at copper1 and copper0 in the xml editor you will discover they have non identical transforms which breaks gerber processing. Again select copper1 ungroup it and regroup it to remove the transform and re establish the correct grouping. Then save it as plain svg (I’m assuming Inkscape here!). However that doesn’t fix the problem, the connectors are still unhappy in Fritzing. It looks like you have generated a new part using the parts editor and not edited the fzp file. At present the fzp file has both copper0 and copper1 specified for each connector, in this configuration the connector needs to have only copper0 or copper1 (depending on which layer it is on) so you need to hand edit the fzp file with a text editor to make that occur. Since copper0 is odd numbered pins and copper1 is even, you need to remove the copper1 layer in the pcbView for the odd numbered pins and the copper0 layer for the even numbered pins. Except for connector19 (in copper1 not copper0) and connector22 which is in copper0 rather than copper1 (I would probably reverse those two to be less confusing :slight_smile: ). That still doesn’t fix the problem though. A trip through that parts check script flagged translates in pcb. A check indicates the pins have a scale (-1,0) translate (usually from rotating the pins). Removed them manually by copying the x coord in the tool bar, deleting the translate, then resetting the saved x coord in the tool bar. That didn’t fix it either (and may not be a problem). So in the fzp file change the family from “Pin Header” (which likely trips off special handling code) to "hdmi connector"from my original part. That didn’t help either. Move back to my original hdmi connector part and substitute your pcb file in to it. Discover my problem is I had some of the last 5 pins swapped between copper1 and copper0, correcting that fixes the part. Now to see how few of the changes above are actually needed. In order for top or bottom of the board to work, the family in the fzp needs to change from pin header to mini hdmi. As pin header it swaps in a pin header rather than your pcb svg. It looks like those are the only two necessary changes, the translates look to be being dealt with OK as is (although it is desirable to remove them). Here is a working part with only these changes made:

Generic female header - 23 pins-1.fzpz (7.8 KB)

Peter


#17

Awesome! Thank you for your help! Another part I am having trouble with is this Female HDMI connector. When viewing the Gerber it does not drill out the “oval” slots. Do you know why?

image

DIP - 20 pins.fzpz (8.9 KB)


#19

For non-circular holes, you can make cutouts in the PCB

I’ve posted how to do it (search…)

You can make them the shape you want - I did a quick example showing only one rectangular cutout (didn’t bother to Radius the corners, which would be needed unless laser cutting).

The image below shows Example of:
• Using Woof_App to get location of the desired pad location (shown with lower left Pad though I made the cutout for the upper left pad - too much morning coffee!). Woof App is also posted, (search…)
• Printout of Woof Data for corner points of pad
• Creating the Cutout (using Gravit but, you can use Inkscape / others). Also penned some ink around it for silkscreen example
• The resulting cutout shown in the Gerber’s Contour file

Ability to actually produce a non-circular cutout depends on who makes the pcb and equipment…


#20

Thanks opera_night. I actually added the holes into the custom PCB board shape.

On that last part that I attached (DIP - 20 pins.fzpz) when the gerber is viewed the pads are the wrong size. Any rectangle that I have used in my custom parts is enlarged. You can see in the picture that the pads form a solid copper connector.

image


#21

You’ve most likely discovered the ‘Fussy-ness’ of Fritzing and making Parts & PCB’s…

It does take a good bit of working with to understand the workarounds to getting what you want. But, you can get there.

( An aside comment) Personally, after ‘getting there’ with Inkscape, I discovered easier-to-use drawing apps and couldn’t delete Inkscape from machine fast enough!

But, ALL drawing apps I’ve used have Quirks requiring time to figure out… Not a perfect world.

Regarding your last post/issue - consider these comments:

• Correct Layer Order
• Correctly ‘Differenced’ or ‘Subtracted’ features
• Correctly made Paths
• Correctly ‘Scaled’ features (depends on DPI export and design values of feature size)

• The big Red rectangle results from incorrect aspects of the above (been there a million times with similar results). That, in addition to a few other ‘head-scratching’ quirks.

Never saw Big-Red for “PCB” but have seen it many times for ‘Parts’ and the Part’s PCB svg. Attending to the above corrected it.

Can’t make cutouts in Parts only can do it in PCB (not the PCB of a Part)


#22

If you post the part .fzpz file I’ll have a look. The most likely answer is translates, they tend to react badly (sometimes) in gerber creation and are evil in general as they are likely a performance hit as well (they require a matrix multiplication to render). They are somewhat difficult to remove sometimes (ungrouping and regrouping will remove some of them though).

Peter


#23

vanepp, the part that I got from you (Generic female header - 23 pins-1.fzpz) has the same problem.


#24

That is odd because it appears to work for me:

although when I look at the gerber output in detail the pad internal spacing is probably not large enough (from the gerbv gerber viewer):

Perhaps I was wrong about being able to not remove the transforms. I’ll remove them and see if things improve, although neither of these are as bad as you example.

edit:

Not the translates (although I removed them anyway) but something in the extra stroke xml. Stroke is set to none so that shouldn’t impact anything but setting stroke-width to 0 and linecap from round to butt corrects the gerber spacing (most likely the stroke-width, with gerber ignoring the stroke=none parameter).

Generic female header - 23 pins-2.fzpz (8.0 KB)

Is the image with the bars all merged by chance an svg of both layers of the board? The Inkscape pcb svg looks like that because both copper0 and copper1 are overlayed and you have to delete one or the other layer to see the real spacing of the pads.

Peter


#25

Awesome, setting the stroke width to 0 and cap to butt in inkscape worked great!


#26

New problem! When exporting the file as Gerber it neglects to include part of the contour. Any ideas?


#27

Good progress!

Regarding “New Problem”… From my experiences with similar problems:

• These truly do affect the outcome:

  • the aspects of making lines
  • closeness to other lines and cutouts
  • radius’d corners
  • difference/subtraction order and path
  • layer order in the file

I recommend first verifying the missing cutout is in the correct layer and was attended to with respect to the above and my previous comments.

Second, make it a rectangle (no radius corners) and see what happens

If you post your PCB file I’ll look at it


#28

Check the missing element for translates or other changes from the ones that work. As always post the sketch and we will have a look, it is hard to say without looking at the xml and/or experimenting with the part.

Peter


#29

As mentioned above, “radius’d corners” will affect outcome. Took a few moments as I wanted to post this followup to underscore that point… (mostly for future readers of this post).

Attached result shows the same file with only difference in the ‘corner’ of the rectangle: one with Radius, the other Without Radius.

The Contour file shows one with Radius’d corners simply would not properly work in Fritzing (though the SVG is good). No matter how I Path’d, Differenced, Subtracted, Grouped, Filled… etc


#30

Could you upload the files for these two please? I’d like to figure out how to make slots and to try and figure out why it fails because with development starting again we may be able to fix it.

Peter


#31

files attached.

Note: Sometimes the radius corners will cause only the specific shape to be missing.
Sometimes all of the cutouts will be missing. Somewhat non-consistent and can depend on size of radius, stroke…etc

NotWork.fzz (29.0 KB)
Works.fzz (28.9 KB)
NotWork.svg.fzp (128.1 KB)
Works.svg.fzp (127.8 KB)


#32

making it easier… I deleted the unnecessary items.

These have only a silk perimeter and the cutout…

simplified_woRadius.svg.fzp (1.1 KB)
simplified.svg.fzp (1.4 KB)


#33

Thanks, I’ll have a look and see if I can figure anything out.

Peter


#34

The simplified files would be easier to inspect as they eliminate the bazillion data points created by Pathing the text, face image… etc…


#35

I think we have more than one problem here. It looks like Fritizng is assuming px as dimensions (which is a problem because that depends on what it thinks a px is 72dpi, 90dpi (I think what it is using) or the current 96dpi (which I don’t think it knows about). This gerber image from the working svg (in orange) is dimensioned in px. The purple one has only the units changed from px to in, which should only change the viewbox, but as we see it also changes the scale and causes truncation. I suspect this is why you need to use a path on the text, Fritzing is getting the scale incorrect when it renders standard text (which is why I was trying to get dimensions in inches). There is also a transform in the silkscreen Perimeter_Rectangle which may or may not be causing problems (it shouldn’t affect the board layer cutouts though they don’t have any transforms). I need to figure out how to create one of these things from scratch to see if starting out with a drawing in inches at the standard scale makes any difference (its possible the paths are not being scaled when the units change for some reason) but so far I haven’t figured out how to get the path difference to work.

Peter