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

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.

https://sourceforge.net/projects/gerbv/files/gerbv/

EDIT
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
http://speeduino.com/forum/viewtopic.php?f=27&t=338&start=20

EDIT
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:

; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T100C0.040000
%
T100
X017222Y011222
X017222Y016222

the associated xml in Inkscape looks like this:

cx 46.799999
cy 10.8
gom 0.4.0.0.0
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.

What file is this? Please send me the part…

EDIT: Never mind… I found a similar file. The SVG are extremity complex. It looks like it imports into Inkscape in different units, increments, and formulas… I never understood the complexity of SVG formats. Here is some “basic” information for sorting it all out; Coordinate Systems, Transformations and Units — SVG 2

I don’t have this problem in CorelDraw… I can change the units and precision on the fly…

EDIT AGAIN: There is a way to set the drill hole size to 0.035" in Inkscape: First, open the dialog box “Fill and Stroke”, and click the tab “Stroke style”, set the units to Inches and width to 0.020". Now go the the tool bar and set the units to inches and the width and height to 0.075". Shazam!.. The outside diameter of the circle including the stroke-width minus the stroke-width x 2… leaves you the inside of the circle (drill size). CorelDraw is a little different, the toolbar dimensions are the actual dimensions of the circle and the stroke-width is in a separate window…

Thanks for both. My head hurts from just reading the standard document but it confirms what I suspected, that the transform statements describe modifications to the coordinate system, if not why anyone would want to :slight_smile: let alone do so as in this case. For my purposes I think the way to get Inkscape to do it for me is going to be the way to go. Since I’m going to be modifying xml in a script anyway perhaps I’ll see if I can figure out how to transform an Inkscape trans text output in to xml that Fritzing will accept (that being why I used the mini part instead of the generic IC pcb.svg) to avoid using such svgs in future.

Peter Van Epp

Are we having fun yet??? :relaxed: The transform statement is generated by the graphics editor when an element has been altered from its original orientation. In a through hole connector, with original orientation, the connectors in FZ PCB View will have the multicolored red halo. If I rotate it, a transform statement will be generated and the connector will only have a red dot in the center.

As for the SVG format, what ever unit the .svg file is in (in, mm, px…) that will be the unit throughout the rest of the document unless the unit is specified. If I import a .svg file into Inkscape that is in inches, then the dimensions in the XML editor are in inches… If I start a new document in Inkscape, it defaults to pixels (px), and the dimensions in the XML editor are in pixels. I don’t know if there is a way to set the default units or change the units in the Inkscape XML editor or not.

Yes! At least I am having fun :slight_smile: , better yet I’m both learning and making progress. I think I can set default units in Inkscape in the preferences.xml file (or via edit->preferences) although some things remain in px. The good news is that I kept a copy of the broken voltmeter part (or more correctly an unbroken voltmeter part that I know how to break!) and have reproduced the change to style that breaks bendable leads. I also can manually edit the file to return the style statement to plain xml and have the modified svg work again in Frtizing and thus can get perl to do the same thing when post processing the Inkscape svgs saved as plain svg. That seems at the moment the easier of the two possible changes (this one or using optimised svg and trying to reinstate the optimized out data back in to the pins). We will see if that remains the case! Assuming I can get this working then there will need to be major changes to the create howto document in the never ending stream of work, but parts creation will get a little easier and more documented …

Peter Van Epp

I asked someone about text and this is what I got, which would explain the default px.

FWIW, this may go back to the way units are handled in Inkscape, svg and css. AIUI, svg does not require explicit unit identifiers (e.g. px) but css does… so to be css compliant, Inkscape adds the identifier. ( I could be way off on this, maybe a dev can chime in.)

There was a point I think, when setting the text units in preferences also wrote the selected unit identifier in the xml (e.g. pt), but that was in a development build.

Ever since I fixed my icons in Ink’s XML Editor the File/Document Properties/Default Units change is more global. Basically everything changes except stroke.

The only way I could change default units was use a template.

Will these be added at some point to the next or a later version of Fritzing?

In theory yes, that’s why they are in parts submit. With the note I’m relatively new to Fritzing, the in theory is because it seems to me (but not to some of the folks that have been here longer) that development has stopped. There haven’t been any commits since July to either source or the parts repository and there are parts pulls outstanding…