I’ve exported the pcb view of a part (which has holes which are actually too small for practical use) and can’t find a way to import the svg back in?!
I’m guessing that the export doesn’t actually include the required bits, but I can’t even find an import option?! I mean, IN the parts editor. For instance, PCB view.
Parts Editor, PCB view, File menu, Load image for view
is what you asked.
A sketch pcb view export is as you say probably not the correct starting point. Instead, open the existing part in parts editor, PCB view, File menu, export as svg. Editing that to change hole sizes, then loading that back should work.
If the small holes are mounting holes, you can probably just drag a hole part into the sketch, and place it over the too small hole. And ignore warnings from Design Rule Check about being to close to an edge.
Thanks ‘Load image for view’ is what I was looking for. Who would think of looking in the file menu!
I did, in fact, export from the pcb view as image, svg. Hmmm. Now it overlays on the old svg. Hmmm. Can’t seem to delete the original?
Maybe using the ‘Show in folder’ function from PCB view in the editor and editing that svg is the correct solution?
Ok, so I went and ‘did that’, using Show in folder and editing the indicated SVG that way. That worked! Thanks for the tips!
It is worth pointing out that all the svg editors I am aware of do things (like adding px to font sizes for CSS compliance) that Fritzing that will break in Fritzing. Your best bet is to run edited svgs (or better yet the entire part) through FritizngCheckPart.py to correct that. FritzingCheckPart can be found in this parts making tutorial.
Part creation howto part 1 breadboard and pcb
Peter
Thanks for the tip. I will try the script, but it doesn’t appear to be linked in the Part creation how-to?
In any case, examing the edited part in the editor, the changes are correctly read and the part behaves as you expect (ie. exporting a project to gerbers yields correct gerbers). But, I literally only adjusted 4 pad/holes and saved. Perhaps it’s less tricky with an existing, properly formatted svg?
That depends on the tool. Inkscape for example tends to add a bunch of extra elements on save. Depending on the options used. The extra ‘stuff’ is valid svg, but can confuse Fritzing which uses the ‘tiny’ subset of svg.
The check part tool will find and remove most of the extras. I typically modify svg files with just a text editor. Or use special options on save from Inkscape, then verify the result in a text editor and/or using FritzingCheckPart.
The reference to FritzingCheckPart is in the testing section here
Peter
Hmm. Ok, I tried that script and it produces only error messages. I checked gerbers exported with the modified part and they are correct. They are practically (it’s less than a mm change per pad * 4) indistinguishable. I’ll have to look at the script, but it doesn’t seem to generate useful information vis. the actual production. I could upload the svg in question, I suppose.
Shit. that script modifies the file? I see there is a .bak file. checking is one thing. writing is another. sigh. EDIT. I painstainkingly reverted the changed files, did a gerber export and compared again. The part is fine without the intervention of the script.
Yes check part modifies the files (thus the backup files) as it needs to to correct errors. Best bet is to upload the .fzpz file (upload is 7th icon from the left in the reply menu) for the part which will allow me to run the part through check part and explain the errors and what they will do. It is entirely possible that the script is pointing out errors that exist in the original part that may indeed cause problems but they may not be obvious.
Peter
I should have READ the script. I was expecting it to CHECK and not to write! That was a nasty surprise since I had to rename 3 files by hand and move the changed files out of the way. That script should be considered ‘destructive’.
EDIT: the part in question is attached. first the svg I modified and then the part
That point has been brought up before, but since a relatively few people use it I haven’t been motivated to make the necessary changes yet.
Peter
Ok, understood, but I don’t approve. And then, I maintain a lot of software that needs refactoring (I have a lot of users) so I should not be throwing any stones in glass houses.
It’ll take a bit of time, but I will have boards produced with this part and I’ll report here if it worked. Judging from the gerbers, though, looks good.
If the gerbers are correct, things are probably fine. The errors reported are all internal to Fritzing and usually cause problems there. The only gerber one I can think of is pads as ellipses which won’t generate holes in the gerbers which does not show up in the Fritzing pcb view!
Peter
The output contains numerous errors that I haven’t got to the bottom of yet.
An example:
Key -inkscape-font-specification
value ‘Droid Sans, Normal’ is invalid and has been deleted
That is simply a valid CSS font name. it has nothing to do with inkscape, per se. And is ignored by fritzing as far as I can tell.
The error files which gave me pause:
Error 64: File
‘/home/mwa/Documents/Fritzing/parts/user/tactile-switch-12mm_nocap_roboteach_es_1.fzp.bak’Connector0 doesn’t exist when it must to stay in sequence
and
Error 77: File
‘/home/mwa/Documents/Fritzing/parts/user/…/svg/user/schematic/tactile-> switch-12mm_roboteach_es_1.svg.bak’
At line 26terminalId connector1terminal can’t be a path as it won’t work.
The first error doesn’t seem to be an error(the sequence is unchanged from one svg to the next) and the second error I’m uncertain of. In any case connector1terminal is a path which correctly produces a pad and hole.
Key -inkscape-font-specification
value ‘Droid Sans, Normal’ is invalid and has been deleted
It is a valid font value, but not for Fritzing. Fritzing will replace it with Droid Sans as it doesn’t accept Droid Sans Normal. Normally nothing much will happen.
Error 64: File
‘/home/mwa/Documents/Fritzing/parts/user/tactile-switch-12mm_nocap_roboteach_es_1.fzp.bak’
Connector0 doesn’t exist when it must to stay in sequence
Fritzing parts should start at connector0 and increase in sequence. It will work if they don’t but it is incorrect.
Error 77: File
‘/home/mwa/Documents/Fritzing/parts/user/…/svg/user/schematic/tactile-> switch-12mm_roboteach_es_1.svg.bak’
At line 26
terminalId connector1terminal can’t be a path as it won’t work.
This one causes a real error. In schematic view if you connect a wire to the pin and move the wire to an angle it will connect in the middle of the pin rather than the end of the pin (which the terminalId identifies.) It won’t have any effect on the gerbers though.
Peter
Ah, ok, it may be as they were labeled connector1pin through connector4pin.
Ok, I never move the wires to angles other than 90/180. Turning the part doesn’t seem to have this effect.
I use the part in several projects, so I’ll revisit it on the next production run. Thanks!