more parts and autorouter problems
Hi;
Actually there's a couple of parts that I'm still having trouble with. I've dug into them some more, both with and without editing the style=... items. Still no go. I'll email save-as-sharable project files shortly.
The first is a DB9 connector. In PCB view, only 5 of the 9 pins show, with a weird offset. I'm doing something a bit new -- 2 "pins" are actually mounting holes and not electrically. I'd like them there so they'll be part of PCB fabrication. Moving them from copper0 group to silkscreen group (and making them white) didn't change anything. I also noticed that in the inkscape-generated file connector4 had stroke-miterlimit and stroke-dash elements. Editing these out, no change -- only 4 pins show in PCB view with weird offset to the red routing rectangles.
The second is a MAX232 IC. I used the core library 16-pin narrow dip for the PCB view. When in breadboard view, connecting a wire to pin 1 (counting from 0) results in the wire jumping to pin 10 (counting from zero). In PCB view, pins 1 and 10 are routed together. I've taken the breadboard, schematic, and pcb SVGs apart and put them back together several times, still can't find what's up.
beers, Don
Hi Don,
In the max232 case, in the fzp file, in the connector 1 element, you have:
p layer="breadboard" svgId="connector1pin" terminalId="connector10terminal"
See the "1" and the "10"? Change the "10" to a "1".
I'm not seeing the pcb view problem with max232.
Note also that Fritzing is giving me an error when it tries to load the level converter part.
I see the problem with the DB9 part, but I'm not sure what the cause is yet.
- j
Hi Donrob,
The db9 problem has to do with transforms inside elements--there's a bug in the way Fritzing deals with these. For now, the workaround is more hand-editing. Open up the pcb svg file, and for each of the nine circle elements (connector0 - connector8), create a new g element surrounding the circle element, and move the transform attribute out of the circle element and into the g element.
Here's an example for connector8 (angle brackets changed because the forum post formatter gets confused):
{g transform="matrix(-0.99999997,0,0,-0.99999997,545.39581,878.44291)" } {circle cx="70" cy="470" fill="none" stroke="#ffbf00" stroke-width="11" r="24" id="connector8pin" /} {/g}
- j
Hi Jonathan;
Thanks-a-heap for your perserverance. The edits of your last 2 posts did the trick. SVG appears to be a real pain. But once SVG's happy Fritzing is a true joy.
The problem with the MAX232 chip still has me a bit puzzled. Through both Inkscape and a text editor I've quadruple-checked the breadboard, schematic and even library PCB views can't find any pin/terminal 1/10 labeling or coordinate problems. Yet it surely ended up in the fzp file exactly as you described. I can send you my original .svg's if you want to dig into it. But it's probably not worth the time, especially if ICs will be included in the Parts-O-Matic sometime soon.
cheers, Don
Since I wasn't able to replicate it, do you want to send me an image of the MAX232 pcb problem you're having?
ICs will be coming in the next release.
- j
Hi;
If ICs will be in Parts-o-matic next release I wouldn't spend any time trying to track this one down. I went through a lot of iterations and may have had a "1pin 10terminal" error in one of my early iterations. After this bout of editing I realized that removing a part from from the "mine" bin still leaves .svg and .fzp files in the various directories. What's the best way to totally nuke a part? Just manually delete all the respective files?
cheers, Don
If you have parts or bins you've created that you want to keep, yes, manually delete the individual fzp and svg files. If you want to blow everything away, delete the local fritzing folder (i.e. on xp that's in "C:Documents and Settings[username]Application Data".
- j
Hi;
Rember my DB9 problem (see the above posts). The manual edits fixed the PCB view and auto router. But when double-checking before posting to the projects page, I found a couple of problems. Ya gotta love SVG ;-)
With an export-etch-pdf, in the .pdf all of the pads except the square part of pin 1 are shifted. 'Same transform problem?
With an export-etch-svg, in the .svg all of the pads except the square for pin one are simply missing.
I'm emailing the files to info@fritzing.
SVG is fine; it's what Inkscape and Illustrator do to it.... The transforms are definitely part of the problem. I'll email you back a "flattened" version of the pcb image for the db9. There's some other issue with the big circles (which are actually SVG paths) that I haven't figured out yet.
And there's a copper rect way up in the left corner of the db9 pcb image--I think it's outside of the viewbox--is that intentional?
And note, both the fzp files you sent are missing the silkscreen layer element (shown below), which means that what's on the silkscreen layer is being treated as copper.
[pcbView]
[layers image="..."]
[layer layerId="copper0"/]
[layer layerId="silkscreen"/]
[/layers]
[/pcbView]
Closer, but not quite there. I tried the flattened.db9 file you sent. The Fritzing views all remain fine. In the export-etch-pcb file the traces now properly connect to the pads. But the pads are shifted with respect to the large mounting holes. Is this the problem with big circles you mentioned?
The copper rectangle should be over pin 1, identifying it as pin 1. It's ok in my original svg file. Transforms seem to be a real pain.
Silkscreen elements are showing up just fine on this end in pcb view and parts editor. I double checked and there's two groups in my .svg; copper0 and silkscreen. Is something getting lost in translation by parts editor or share as sharable? They shouldn't be in the export-etch-pdf file since that's for etching not silkscreening.
I'll email all my original .svg files, plus the .pdf to info@fritzing.org.
thanks for all the hard work, Don
Yes, your S-V-G's have both copper0 and silkscreen elements but your F-Z-P doesn't--the snippet of xml above is for your F-Z-P file.
Hi Don,
Found and fixed the bug that was messing up the mounting holes, and Fritzing can also now deal with the transforms. In other words, the fzz file you sent previously, "sharableRS232.fzz", in the email "DBP problem files", is now exporting correctly (or at least I don't see any obvious problems).
If you're building Fritzing from source, the fixes are checked in, otherwise you'll have to wait for the next release.
- j
Post a Reply
Please login to post a reply.
