New options for small signal diodes and a fix for the 1n4001 in breadboard

Since I have need of a small signal diode (specifically a 1n4148) I have circled around to where I started on parts creation hell and finally done a series of small signal diode parts. Since I was doing it anyway I included a wishlist request for various sizes of foot print (from a 100 mil spaced vertical to 500mil spacing for jumping over traces) on the way by. At the same time I fixed a bug in the 1n4001 part where the pcb footprint is 300mill but the breadboard footprint was 400 (now reduced to 300 as it should be.
All parts have all 3 views and have been tested to insure they align to the grid and can be connected to. I copied the hole spacing from the resistor in to the PCB footprint for all the small signal diodes so the hole in the PCB should be better than the large hole for the 1n4001, but I haven’t cut a board to test it so far.

First the fixed 1n4001 part (the description was changed as well)

(edit: I have updated all of these parts to correct errors in pcb view)

Rectifier_Diode.fzpz (6.4 KB)

Then the set of new horizontal small signal diode parts:

diode_small_signal_1N4148_flat_300mil_1.fzpz (6.2 KB)
diode_small_signal_1N4148_flat_400mil_1.fzpz (6.1 KB)
diode_small_signal_1N4148_flat_500mil_1.fzpz (6.1 KB)

and finally the vertical 100 mil version

diode_small_signal_1N4148_upright_100mil_1.fzpz (7.7 KB)

Peter Van Epp

I wonder why FZ Gerber Export is reporting the 0.500" diode as having 0.055" drill holes.

@vanepp That is strange… I imported the pcb.svg into CorelDraw, deleted the meta data, then exported it back into the FZ diode part. the Gerber drill hole size is 0.035", the same as in CorelDraw. Idiosyncrasies… this could be a problem…

EDIT: Got it, the “stroke and stroke-width” are in the id=“copper0” layer. There is no stroke and stroke-width attributes in connector0pin and connector1pin elements… this has resulted in the stroke-width not being subtracted for circle diameter, causing drill holes in the Gerber to be drill as NON-PLATED HOLES instead of THROUGH (PLATED) HOLES…

FIX: In Inkscape, cut the “stroke and stroke-width” from the copper0 layer and past them into the connector0pin and connector1pin elements…

PS. Also when you save the .svg, check the box “Remove metadata”. That will get rid of a lot of that unneeded garbage and clean up the files.

More new things to learn (I’ll have to find and figure out the gerber export :slight_smile: ). The original issue is ugly because it seems to be Inkscape deciding to do this for itself. The original diode part that I cloned these from when loaded without change in Inkscape has

connector0pin (with stroke and stroke width)
connector1pin (with stroke and stroke width)

(all of which appear to be empty)

After the edit with Inkscape the empty groups are gone (which I expect doesn’t matter) and the stroke and stroke width are moved in to copper0 and removed from the pin definitions. I wonder if what I want is to set transformations (in Inkscape preferences) to Preserved from the current Optimised as that is the only thing I see that talks about stroke-width, and this sort of looks like it is optimising the stroke out of the two connector pins and in to the enclosing group. Otherwise I have no clue how to convince it to not do this. As to the metadata, I did have it ticked to remove, but it seems to sometimes also then forget to keep the edit data (which enable the grid and remembers the window sizes for the next time I edit the file). I probably need to experiment more to figure out exactly what is doing this. It sometimes seems I need to save the document first in Inkscape format and then re save it as optimized svg to get it to remember the settings. I’ll try all these things and see if I can figure out how to convince Inkscape to not change things.

(edit) Nope, changing transforms to preserve from optimize doesn’t help, it still moves the stoke in to copper0 and out of both connectors.

Peter Van Epp

It’s in Export/For Production/Extended Gerber/drill.txt file. I always Gerbview(in KiCad) parts to make sure.

I noticed those extra groups as well. The guys that came up with Fritzing added a lot of features - I’m still finding them - but didn’t make an instruction manual, so maybe they do do something, or something in the future.

Thanks I found that (and wish I hadn’t, lots of errors!). I grabbed gerbv from source forge which displays the gerbers I should still have a kicad copy around so I’ll probably try that too and see which I like better. Oddly enough the 300mil diode seems mostly OK. Thats odd because the 400 and 500 mil versions are a simple clone with the pads moved but at least the 500 is broken. When I moved the stroke and stroke-length back in to connector0pin and connector1pin with Inkscape xml editor it leaves them there but the square pad on pin 0 is now overwritten because the pads have become larger for some reason. I’ll continue poking at it and see if I can figure it out (and go back and look over all my previous parts for problems too …)
The extra groups are sensible for more fancy PCBs, its possible they just didn’t need the function for this simple a part but put the layers in anyway.

(edit) This keeps getting weirder! I just Inkscaped the apparantly working 300 mil part and it is identical (as it should be) to the 500 mil part except for pad spacing. It has the same stroke and stroke-width in copper0 but not on the connectors but it appears to work correctly (at least as far as I can see). Nope, the holes (when I remove the copper layers) are the larger size for the 300 mil and 400 mil too so it looks like the stroke thing is a problem and I so far haven’t found a fix. Keep trying I guess.

Peter Van Epp

That was lucky I grabbed the 500mil, because that was the only one I looked at.

The contact probably became bigger because it was now showing it’s correct hole size. On a side note I have noticed that if you pull a node out of a group, because it’s a child of a parent their attributes change.

I had a play with those extra groups a while back - mask - and didn’t see much, but then again I didn’t know what I was doing.

Just figured out that Gerbview can show the drill holes, but because I’m using the drill.txt file instead of the Excellon file I get an error, and when I looked at your 500mil it looks like the round pad hole is a touch offset.

I just tried Gerbv and the hole isn’t offset, so it looks like it’s better.

How did you get the drill file in to gerbview? It doesn’t seem to like the txt drill file from Fritzing. I am running Kicad 4.0.3 which may be old by now.

Gerbv (beta) download I used.

There is something wrong with Gerbv. I ran a ruler over the top copper layer and it says 600mil, and the Analyse drill says 0.042" holes. I tried 2.6.1 also

Looks like back to the drawing board for parts creation. My first part the Valor DC DC converter is also wrong. Holes .057 instead of …035 (from the drill file text) and the holes are all not plated through unlike the generic IC it was cloned from which are .035 plated through holes. Now to figure out why. Parts creation is hell I say! :slight_smile: I’ve already discovered that the mounting holes in the voltmeter and ammeter are wrong compared to the core hole part that I cloned them from. It creates only a drill file of the hole size where mine have copper 0 and copper1 pads as well as a drill file hole (which may not be the right size). Lots of parts to go back and try and fix …I agree gerbv seems less feature rich than Kicad’s grebview if I can figure out how to get the drill file in to gerbview.

Peter Van Epp

Apparently you can’t save as Optimized SVG… I guess it means back to Plain SVG… because attributes are optimized. All attributes that are the same will be combined in the same group. Sense the square and two circles have the same attributes and are in the copper0 group, the attributes are optimized in the copper0 group. If each attribute is different then they will remain with their own element.

Just use the load Excellon option under layer.

Hell I went through the same thing. It took me 3 months to make my ECU connector only to find out that it was a single layer 6 months latter, because the part I made it from was single layer and I didn’t know how copper worked. It was that gerbView and drill.txt that found it, and I only research it after I heard so many people talking about it

Holes without pads are something else again, I found that out with the TO-220 (nonconn0)

You can’t do much with Gerbview except look at it where as Gerbv has ruler and stuff, but unfortunately the dimensions are wrong using a FZ gerber.

Apparently it does not cause a problem in PCB view… it may be in the script that generates Gerber drill file.

Do you mean the Gerber that FZ generates, because I’ve been using it as Gospel and someone put my ECU to a PCB manufacturer and it was perfect.

Bottom of this post

You’re right the Gerber Export is wrong for some reason. If I export the normal resistor it’s fine in Gerbv, but Peter’s isn’t. That Gerbv is brilliant, so many more features than GerbView.

I believe that in the diode pcb.svg, when the attributes all got optimized into the copper0 group, that somewhere along the way (possible the Gerber drill script) does not pickup the attributes when they are in the copper0 group.

Yes, replacing the style line in all the connector pins and saving as plain svg seems to work correctly. The footprint is showing .040 through hole now in the drill file. So it is looking like there is a perl script in my future that can untangle which ever is easier, unoptimizing the copper0 stuff or rewriting the bent leg style stuff that started us in optimized svg in the first place :slight_smile: there doesn’t seem to be a middle ground. Of course the script can also clean off the px s that Inkscape likes to sprinkle on the text as well. I actually wouldn’t mind reducing the hole size to .035 to match the generic IC foot print but I don’t know how. Xml editor says the radius (at least I’m assuming r is radius) is 2.052 which somehow unclear gets to 0.040 in the drill file. Is there a way to figure out what the radius should change to to get a .035 hole? Then it will be on to correcting the “make this part” post for the new reality …

Peter Van Epp

It appears that the dimensions in Inkscape are in “thousands” (.001) of an inch, and that the radius in Ink is 27.5 (0.0257"), The circle diameter is 27.5 x 2 / 1000 (0.055"). The stroke-width in Ink is 20 (0.020"), 20 / 1000. Half of the stroke-width is inside the circle and half outside the circle, but there are two sides (0.020" \ 2 * 2 = 0.020")… that’s right, still 0.020". Take the diameter of the circle, minus the stroke-width = drill hold size (0.055" - 0.020" = 0.035"). In other words (27.5 * 2) - 20 = 35 (0.035").

In the Gerber drill file it my read something like “T100C0.034993”, but it will be rounded up to the next drill size at the fab house. (Tool 100 = 0.035") plated hole size. The actual drill bit size may be a few 10/1000" larger to account for the finished platted hole size to 0.035" (0.889 mm).

I checked it a long time ago and came to the conclusion the drill hole size is the white ID of the circle.

Thats good information to know, but in my current case in the svg that actually works and produces a drill file like this:


the associated xml in Inkscape looks like this:

cx 46.799999
cy 10.8
id connector23pin
r 2.052
style stroke:#f7bd13;stroke-width:1.22399998

which doesn’t match the numbers quoted unless they are being multiplied by something that I don’t know about. Your numbers do make sense for the case of the generic IC (I swiped the pcb file from the arduino pro mini part for the numbers above as it had text which the generic IC doesn’t):

cx 660
cy 60
fill none
gom 01.0.2
id connector23pin
r 27.5
stroke rgb(255, 191, 0)
stoke-width 20

this set produces a drill file with a .035 in place of the .040 but from very different numbers. There must be something that translates or scales to this in the first case, but I don’t know what or where to find it. I think the pro mini svg was from illustrator which may be the difference, but there must still be something in the xml that sets the scaling I expect since the final results are similar.