National Instruments hosts a very handy table for finding IPC 7351 equivalents to JEDEC and IEC package names.
I’m linking to a local PDF version for convenience.
One tiny megaphone
National Instruments hosts a very handy table for finding IPC 7351 equivalents to JEDEC and IEC package names.
I’m linking to a local PDF version for convenience.
The ps2pdf-d
script I developed earlier worked fine for getting PDF from KiCad‘s Eeschema using Postscript as an intermediate format, but it falls short with Pcbnew because there is no way in Pcbnew to make a Postscript file that merges layers. Using File > Plot, you can pretty easily get Postscript files of individual layers, but you can’t get a merge of, say, the top copper, top silkscreen, and drawing layers.
But you can do this with File > Print SVG. You’ll need to play around with the dialog to get the SVG you want, but it’s pretty simple. Thus, svg2pdf-d
was born:
#!/bin/bash # DESTRUCTIVELY convert all svg files in working directory to pdf. # Source file extension is case sensitive! # Requires inkscape. # Mithat Konar 2013 <http://mithatkonar.com> OPTIONS="" FILES=$(ls -1 *.svg) # There are two alternatives below for doing the conversion. #~ ## BEGIN ALT_1: #~ ## This approach isn't optimal because it restarts inkscape per #~ ## file. However the simplicity lends itself to porting (e.g., to #~ ## windows BAT. #~ for file in $FILES #~ do #~ base=$(basename $file .svg) #~ inkscape --without-gui ${OPTIONS} ${file} --export-pdf=${base}.pdf #~ done #~ ## END ALT_1 ## BEGIN ALT_2: ## This approach seems to be better because it starts one inkscape ## instance for all files, but it also involves a temp file. # Make a temp file to store batch commands. CMDFILE=$(mktemp) || { echo "Failed to create temp file"; exit 1; } # build up the list of commands for file in $FILES do base=$(basename $file .svg) echo "${file} --export-pdf=${base}.pdf" >> $CMDFILE done # Process commands in a batch. DISPLAY= inkscape ${OPTIONS} --shell < $CMDFILE rm -f $CMDFILE echo ## END ALT_2 # Delete old files. # Since inkscape exits with 0 even with errors, we need to explicitly check # for conversion before deleting originals. rv=0 for file in $FILES do base=$(basename $file .svg) if [[ -f ${base}.pdf ]]; then rm $file else echo "$file not converted." 1>&2 rv=1 fi done exit $rv
svg2pdf-d
requires Inkscape, which is not really that light. But it’s arguably something that should be in your FOSS toolkit anyway.
The Inkscape conversion used in svg2pdf-d
seems to work fine with the SVG files generated by Eeschema as well. I’m seeing only minor differences between the SVG→PDF versus PS→PDF conversions, and the SVG→PDF files appear to have truer color. So the SVG approach may be the better one in general.
I’ll add I have added this to the wiki after a bit more testing making significant revisions.
Update: Turns out SVG might be a better base than PostScript for this. See PDF output from KiCad in Linux from SVG.
I’ve tried to get decent PDF output from KiCad‘s Eeschema a few different ways, but what I’ve found to work most reliably is to first export to PostScript (File > Plot > Plot PostScript) and then use the ps2pdf
command from ghostscript to convert to PDF. (The Arch wiki has a good writeup on ps2pdf
.)
The biggest problems with this are:
To help with this, I use the script below. I drop a copy of it into the root of my KiCad projects and edit the OPTIONS as needed for the project. Then whenever I want PDFs of my schematics, I export PostScript from Eeschema and then click on this script in my file manager. Note that running this script will destroy any *.ps
files in the directory—that’s by design.
#!/bin/bash # DESTRUCTIVELY convert all postscript files # in working directory to PDF. # Requires ghostscript. # Mithat Konar 2013 [http://mithatkonar.com] OPTIONS="-dOptimize=true -sPAPERSIZE=11x17" FILES=$(ls -1 *.ps) for file in $FILES do ps2pdf $OPTIONS $file && rm $file done
I’ve not tried the script on any PostScript files other than those produced by Eeschema, but I’ve got no reason to think it won’t work on other PS files as well.
I just noticed that my Mercurial repository of some KiCad modules I made never made it to the Web. Took care of that just now. You can access the repository at https://bitbucket.org/mithat/kicad-modules-mfk/.
Note: This is a 2011 repost from the now mostly defunct Biro Technology blog. I’m reposting it because it’s good information that belongs here. (P.S. Added it to the wiki.)
I’ve been working a bit with KiCad lately and have run into a problem in PCBnew with “stitching” (i.e., adding vias between) filled zones on top and bottom layers. This is something you typically do if you have flooded the unused spaces on both top and bottom of your board with copper and have connected the floods to ground or some other reference.
The KiCad FAQ outlines a process for doing this, and it works fine until you refill (i.e., re-pour) the zones–or the DRC refills them for you. When the zones are refilled, the vias you added for stitching become isolated from the zones and end up as little pads floating in space.
The problem and a workaround was discussed in a recent thread on the kicad-users mailing list. I wanted to summarize here the workaround in a slightly less terse way:
You can repeat this as many times as you want to create different clusters of stitches. When you refill zones, the vias will retain the connectivity information and work as expected.
Since Olimex’s PCB prototype service is currently offline, I decided to try another provider for a project I’m working on. The one I settled on is OSH Park, and I have to say the online ordering process worked far more smoothly than I expected. I uploaded a *.zip file full of Gerbers exported directly from KiCad, and the system recognized everything perfectly. Here’s hoping the boards turn out equally fine.
One bit of advice: As near as I can tell, KiCad’s layer alignment targets only add extra square inches to your design for which you will be charged, so you may as well leave them off.
I recently delivered my first printed circuit board layout project using libre software. It’s an actively regulated, high current power supply for an audio equipment manufacturer, and it should be on the shelves in a month or so. The software used was KiCad (GPL2), though I did use FreeRouting (gratisware) to help route the board. I am quite happy with the results and the process. The work was done completely in Linux (Debian Wheezy, if you’re curious), proving that libre EDA–including the OS–is entirely possible.
Except for autorouting, the overall experience was comparable to working with my previous go-to package: the now-defunct WinQCad. While FreeRouting’s autorouter seems comparable to the best that other high-value EDA tools can presently offer, WinQCad’s was in a class of its own. FreeRouting still gets the job done, but it needs more hand-holding and prodding.
In addition to using it for PC layout, I am also using KiCad as a front-end schematic capture tool for SPICE simulations. Now that I’m over the worst of the learning curve, I’m really looking forward to doing more work in KiCad.