A new part creation HowTo (long! So long it is in 2 posts)


#21

I followed a tutorial I found, but when I went to place it on the PCB, I could not resize it, or get it small enough to be seen on the PCB.

Will start over and give it another go.


Do you recognise a 6 pin oled display?
#22

I think it has to be the exact size dimensionally for the PCB view, like all parts.

In Fritzing measure how much room there is, use coordinates bottom left and click it to change units, then set the drawing svg units the same and make it 1:1.


#23

I just replaced the complete text of the first two posts in this thread that make up the howto with a corrected and expanded version. If you have read the original please read the update, as parts of the original are just plain wrong!

Peter Van Epp


Hologram Dash - Cellular MCU
Help please to edit a component in inkscape and then use it
#24

Thanks, Should those post be made into a sticky? I see a lot of threads asking about creating a part.


#25

#26

@vanepp can you please give me some idea as to what the issues were with optimized svg? I missed the change in the guide and a number of my recent parts have been submitted in optimized format - some of which are now in git, so I need to do some serious damage assessment. Note that if you use a master copy of your file as proper inkscape, and then ‘save a copy’ to plain svg, that has a number of benefits - no annoying warning, no loss of inkscape metadata like layer label;s. You can also automate the export process using the command line and --export-plain-svg.


#27

Its been a while, but the main one I think is that pcb view doesn’t deal with inheritance of some of the parameters (I think likely fill) that Inkscape was optimizing in to the group above it. Some part of pcb (probably square pads if I remember correctly) wasn’t rendered correctly til I went back to plain svg. This is why I’m working on inlining all the style commands and inheritance in the python scripts so that you can run optimized in Inkscape and the script will fix the problems. It looks like from my notes of the time that
the problem was to do with the connector pins in pcb (@steelgoose is who actually identified the problem, so maybe he remembers the exact details if we are lucky)
(edit: fit the enter key instead of paste …)
Found the reference in

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.


#28

This is where I fall down with Fritzing - I don’t use PCB much; I’m mostly a breadboard man :wink:

Have you been creating this from scratch or adapting the original scour.py optimized svg output script? It should be possible to nobble it fairly easily to add the options we need.

I need to get coding on this soon. I think it should be possible to get an entire workflow going (I’ve dubbed it FritzInk)


#29

From scratch, I’d never heard of scour.py (although I will go have a look at it now :slight_smile: ). I only just discovered while reading answers on stackoverflow that Inkscape is apparantly written in python using lxm. I did see a reference to an Inkscape plug in to collapse redundant groups that I need to look at. I’m also finding out why people are resistant to changing to python 3 :slight_smile: I have (or had) pretty printing running and then move it in to the main script where it promptly broke because I hadn’t remembered to set pythin3 in cygwin so it was using python 2 . I’m so far having little luck in getting the pretty printed xml to write to a file (because its in a funny format because of a lxml limitation that just works on 2.7 but tosses type errors on 3. I was thinking that once I get the standalone scripts running looking at an Inkscape plugin would be a good bet, a one step process would be better (but it would likely preclude syntax checking of fpz files so maybe not :slight_smile: )

Peter


#30

Wow! Got the python script far enough last night to run it against the core pcb svg library (some 200+ files which took 5+ hours to complete under perl). It complained (with cause :slight_smile: ) about bad xml in 5 or 6 files (as did perl) but completes doing both the convert silkscreen from white to black (which is the only part perl was doing) and inlining style commands and prettyprinting the output file in less than a minute. I ow have a list of commands that are being (or sometimes not being :slight_smile: inherited so I can pick those out and cause them to be inlined as well now.


#31

That’s great progress! I am thinking I might try patching scour for the px and group issues and sending a pull request to the author. Latest Inkscape uses whatever scour you have installed in preference to it’s own, so doing that might effectively give us usable version of Save As Optimized SVG… Just need more time!!!


#32

I had a look at scour, but the python was way beyond my level. At this point I have a python file that will convert a single Inkscape svg in to something with inline styles and the stroke commands inherited and the px es removed from font-size commands so the gerber script will see them and another that processes the fpz file and pulls out the layer names and connector values. I’m now working on merging those two (and changing the svg processor to pull out the connections in the svg so I can warn about missing connectors or level names in the svgs). As well I managed to get some input on the subject from El-j by posting a bug report (that wasn’t really a bug report) on github in

where he supplied some pointers to work already underway in Fritzing which look interesting, although I’ve yet to make any sense out of travis-ci except that it tests something (what it tests or how isn’t clear to me :slight_smile: ). Along the way I’m learning github (at least sort of so far) and will eventually post the python there although I perhaps should try and post what I have so far sooner rather than later it sounds like. I’m just about to post a couple of real bug reports against parts. The convert silkscreen python script finds at least two fatal to Fritzing part errors in pcb and another 3 or 4 that aren’t legal xml but don’t break Fritizing types. So far schematic and breadboard look clean. In fact it just finished and all except pcb look to be clean xml wise.

Peter