@opera_night wrote:
Awhile back, I did some testing of Drawing app’s - my goal is/was to avoid Inkscape and find a robust app with simple user interface. The best two (IMO) are Boxy and Gravit. By far, Boxy is much cleaner.
Boxy is for Mac and Linux. Gravit is also excellent. Both have some minor ‘issues’ but are quickly improving.I’ve had some recent interaction with the designer of Boxy and an export for Fritzing is on their “Todo” list
Posts: 5
Participants: 2
@ginney54 wrote:
I’m a new user trying to find Omnigatherum parts but find it impossible to locate them to download. Any help would be appreciated. Greg
Posts: 2
Participants: 2
@kimkash wrote:
Hi all =]’
I’ve being Investigating FZ features for some time in order to learn how to create some artistic boards I have in mind and I stuck upon some annoying issue: I’d like to create custom soldermask that doesn’t necessarily related to other features of a part like copper connections placement and, for the life of me, couldn’t get it to work.
Let’s get technical:
This picture ( https ://imgur.com/a/JR6j3ZJ ) shows a regular image on PCB using the built-in part that lets you pick a picture and it’ll make it onto the PCB’s copper layer. Note that most of the Iron Man there is covered in soldermask. To the left you can see a part used as soldermask remover (after nights of digging the web and the forums on how to remove soldermask and countless attempts and edits to SVG files) that removes the whole soldermask effect from the area in question.The problem is that it is two different parts and therefore needs alignment and some other small problems arise.
Since this problem rose from a artistic demand, my ultimate favorable workflow would be something like this: working on some picture in AI, setting up the layers conveniently for FZ then creating a single part that will include complex copper and soldermask areas placement.I will note before I ask my questions that I viewed almost every available YouTube video I could lay my hands on and couldn’t find the answers, the forums were a lot more helpful but still couldn’t make it to the final stretch.
Since I’ve seen some advanced people around here knowing deeply how FZ works and analyzes the SVG’s we feed into him, here’s my questions:
1.) What layers does FZ actually process? what is the structure of the SVG should be like?
here’s a picture of an example SVG for PCB tab/layer/section found on FZ website as instructional material ( https://imgur.com/a/EXRuxJp ) - after opening several hundreds of part files submitted by the community, still haven’t seen dominant layer structure or grouping order. Some file had the copper1 layer inside 20-layer cascaded groups, some had none. No matter what I did in the ‘soldermask’ layer, it didn’t have any seen effect in FZ or Gerber exports.2.) I’d like to know which tags inside the SVG file is relevant to FZ and what they does. In this picture ( https://imgur.com/a/8LKNi6r ) you can an example file opened in Sublime and I don’t know what all the tags mean in the start of the file. For example, I did notice that I need to add " fill-rule=“evenodd” clip-rule=“evenodd” " to parts that I created to use as soldermask remover.
3.) I’ve notice that if the order of the layers is different, there are variations in the results after importing to FZ Parts Editor, for example if copper0 & copper1 is switched, it messes with the top layer in one case and not in the other, so- Is there any particular order all the various layers should be at?
I know I came in here and for my first post I’ve bombarded you with questions but I really desperate after all the digging…I’ve wanted to add files to prove my various points but since I’ve done hundreds of tests and Gerber exports very fast while I was working on it, it is very hard right to find specific files so if you guys would ask for files about specific incident, I will generate new files for your questions and post them for you to see.
Thank you so much, everyone!
Kimkash
Posts: 1
Participants: 1
@vanepp wrote:
It is possible by manual editing of the files (parts editor currently does not support this) to make parts with internal traces. One limitation is that the traces will not be solder masked (at present any copper in a part is not masked and that can’t be changed without a code change AFAIK). Another limitation (Inkscape rather than Fritzing this time) is that for through hole parts, you need to maintain two copies of the pcb svg, because for through hole pads there need to be two copies of pads both labelled connectorxpin and Inkscape doesn’t support this (on edit it will replace the duplicate name with created label breaking Fritzing). The work around I use is to name one of the pads connectorxpin and one connectorxpin_ in Inkscape, then before creating the part manually edit the pcb svg and do a global replace of pin_ with pin to create an appropriate svg for Fritzing. At present the FritzingCheckPart script also objects to this format, but I will probably (assuming I can figure out how to do it) correct that later. The basic trick here is to create copper0 and copper1 layers in the pcb svg that are at the root level rather than with copper0 as a child of copper1. This may not work forever as it is an older part compatibility mode and may be deleted in a future release. For a through hole pad, as noted there need to be two identical pads one in copper1 and one in copper0 with the same connector name (such as connector0pin) on both pads. With that in place you can now add traces to the appropriate group (copper0 for a trace on the bottom of the board and copper1 for a trace on the top of the board) by adding a line or rectangle to the svg. Unfortunately you have to manually route the traces one segment at a time (I created a part with only the pads, then did the routing in a Fritzing sketch and used the resulting pcb image to copy the necessary traces in to the part). One example of where this is useful is edge connectors (where you need different connections on the bottom and the top of the board), another is mid mount SMD parts (which have connections on both sides of the board). There are example parts for each of these cases in the Microbit part (which is mounting a through hole socket for an edge connector rather than the edge connector itself) available in:
and a HDMI mini connector part which is mid mount SMD at:
unzipping one or more of these parts will give you a working example of the necessary formats of the files. One thing to be aware of is the family name in the fzp file needs to be changed from a core part (such as the pin header if you cloned your part from a generic header). If you don’t, then when you change your part from top to bottom of the pcb in Inspector you may get an undesirable preprogrammed response such as your part being replaced by a pin header. In the through hole case the fzp file is configured as usual with the pcbView layer having the connector in both copper0 and copper1 (the changes being entirely in the pcb svg file). In the SMD case things are a bit more complex. In that case each pin needs to have the pcb layer modified so that there is only a layer id for the layer the pad is actually on in the pcb (i.e. only copper0 or copper1). If you make a mistake and specify the wrong layerId in the fzp file you will get the red rectangle in pcb view indicating the connectors are not correct until you insure that the fzp file and the svg file layerId match exactly. You can trouble shoot this by making connections to one pin at a time in a Fritzing sketch. When you hit a pin with the incorrect layerId, the trace will route to the middle of the part rather than the pad as it should. At that point check the svg and fzp file pcb layerId for that pin match (which they probably won’t) and correct them to match to correct the problem.
Peter
Posts: 1
Participants: 1
@vanepp wrote:
Here is an improved
Micro:bit part. This one has schematic and pcb as well as breadboard. Pcb uses an edge connector (because that is how the Micro:bit connects) to connect to the pcb.Microbit.fzpz (35.4 KB)
Peter
Posts: 1
Participants: 1
@BusDev wrote:
Hi,
Can someone tell me how to and what files from fritzing could be used or shared to order PCB for 3D printing.
will gerber files work ?
please suggest.
Thanks
Posts: 3
Participants: 3
@Petty wrote:
Hi
I’m a newbie Fritzing user. I have very basic questions related to schematics and using Fritzing software.
Is there any hidden connection like global labels. It’s hard and confusing to connect every single wire.Are there any shortcut key for move and rotate.
Best Regards.
Posts: 3
Participants: 3
@opera_night wrote:
I Discovered Some ‘Magic’ regarding making the Board’s SVG
Summary: A simple way to make the Board with Cutouts (and silkscreen) that appears to play well with Fritzing.
I read the SVG1.2 specification to better understand what Fritzing wants - Here’s my take on it:
After reading Fritzing info and importing & exporting many SVG’s into/from Fritzing to gain understanding, I discovered some ‘Magic’ that seems to work perfectly well, repeatedly!
Point 1:
Fritzing info suggests using a Layer called “boardoutline” for cutouts. However, no matter how it’s elements are crafted, differenced, subtracted or path’d, it never consistently worked (for me).Point 2:
Loading a very basic SVG (with my Hand-coded svg (noted in my replies to this post). ) worked fine. Then, exporting an SVG image from Fritzing, revealed the exported file gets updated to include a “boardoutline” layer.Point 3:
I created a new SVG (using Gravit) that has the recommended Layers (silkscreen, board and boardoutline).
I did NOT do any Boolean (diff, subtract…) or Pathing. I simply created the elements and exported as SVG.
Also included two silkscreen shapes.
NOTE: the one ‘Path’ item shown in the Layer panel is a ‘Freehand’ drawn Path (not an element converted into a Path).Loading the file into Fritzing for the PCB resulted in a ‘Magical’ outcome!
All elements intended as Cutouts worked including those with tiny features such as Rectangle-Width = 1px and Radius of 0.25px. Hard to believe!!!
Proximity to other elements no problems!! Silkscreen worked tooI want to underscore: No Paths, No Difference, No Subtraction…
In fact, it will work with only a board>boardoutline layer!Below shows the various elements in Gravit, Fritzing and the exported Gerber Contour file.
The Gerber with All the cutouts (and board shape) easily imported into CopperCam (for creating CNC Gcode).
[ADDED] Also shows up correctly in a Geber Viewer…
Posts: 7
Participants: 2
@tibricole wrote:
Hi,
Newbie with Fritzing, I was looking for how to make the pin’s name visible on the PCB?
(Just created a mystery componant, with two pins -input and output for example-, if their names are visible on the schematic, they are not visible on the board. So how to make them visible on the board?)Thank in advance for you help and advices
Posts: 2
Participants: 2
@tibricole wrote:
Hi,
First PCB Design and the hole’s pin color makes me some troible.
I’ve added a female pin header on the PCB, then duplicated it. All is right, but the hole pin’s color is note the same: green on one and red for the second one. (take a look at this screen shot https://servimg.com/view/19584250/243)
What does the hole pin’s color mean?
Thanks for your help
Posts: 2
Participants: 2
@opera_night wrote:
Posting this in it’s own ‘Post.’ For a good understanding of SVG - This Tutorial
Fritzing is designed to use SVG Tiny 1.2 - This Is Specification
Programs/Applications that manipulate drawing elements (such as Difference, Subtraction, etc) do it via code that acts on drawn lines/objects using a combination of methods. Some do better at it, some, not so good. Hence, all the various menu items seen in those app’s.
However, There are a few intrinsic manipulations that SVG can do: This Example will Subtract an Inner Box from an Outer Box. It is done by simply defining the corner points for the Outer Box in a Clockwise direction (Called ‘Winding’) and defining the Inner Box’s corner points CounterClockwise (called ‘Unwinding’). No Boolean, no fuss…
Example1 (image - I was not able to post the code):
The First “M” winds the outer box, the Second “M” unwinds (thus, an Intrinsic Difference).Example2:
Examples of items learned from the Tutorial - YES, Fritzing loads it without problems!
Posts: 1
Participants: 1
@vanepp wrote:
I recently needed to recover the svg for a board outline with only the fzz file. Because the source svg is in the fzz file. Since I had to do this I figured I document how to do it for other people.
un zip the .fzz file to get the .fz file which is standard xml so edit the fz file with a text editor.
search for the text ’ instance moduleIdRef=“BoardLogoImageModuleID” ’
select the data after ’ <property name=“shape” value=" ’ til ’ </svg> ’ and copy that text in to a new svg file.
You now have an svg file but is quoted, so you need to unquote it to create a svg file that a svg editor will accept it. So edit the file and do the following substitutions (these are for vi or vim)
:1,$s/"/"/g which substitutes all lines (there is currently only one line but later there will be lines) that is the 1.$ part. The s/ substitutes " to " the / ends the substitution, and the g causes substitution for all instances on the line. This should let you modify the command for your editor.
:1,$s/>/>/g to do the greater thans (>)
:1,$s/</</g to do the less thans. Then (otherwise the ones above screw up!)
:1,$s/
/\r/g to replace the quoted newlines with a new line
Now if you save the result you can feed it to an svg editor.
Peter
Posts: 1
Participants: 1
@spaceman1 wrote:
Hi
I am creating a PCB using the Fritzing software,
and the PCB Printing service that I use (not Fritzing Fab, but something in China),
enables me to add V-Cuts to the design.How do I do it with the software?
Thank you
Posts: 5
Participants: 3
@CABBAGE0896 wrote:
not being an E. engineer I’m not going to say something is wrong, but it appears capacitor C9 in the sample file (breadboard view) is flipped the wrong way, can someone verify this for me? Also, the wire on pin 21 (AREF) to the positive rail on the ATMEGA328 is troubling me. In several other breadboard examples (online) it is not there is this incorrect also? or perhaps optional? being just a hobbyist I cant be sure and with Digikey selling me all there non-working crap (I.C’s, PIC’s, crystals…) I have yet to get this circuit working properly.I Replaced ATMEGA328 from Digikey with Mouser’s and bootloaded just fine, Digikeys did not. All that remains to check/ (replace with Mouser parts) is the crystal and 22pf capacitors. this circuit seems to have a very generic setup across the board but mine doesn’t work. Faulty diagrams and faulty parts are all that’s left unchecked that’s why I’m here, to eliminate the faulty diagram, can anyone help? Thanks in advance for any responses.
Posts: 1
Participants: 1
@BusDev wrote:
Hello there,
I spent a good amount of time trying to custom design a pcb that has holes and notches cut out.
Tried with inkscape and all, following some tutorials, and have not been successful.Can someone please help me make this pcb as a fritzing part ? Thanks a bunch,
Regards,
Busdev
Posts: 5
Participants: 2
@vanepp wrote:
I’m helping fix up some parts for the FRC robot folks to get them included in core parts. I’m intending on posting the fixed up parts here (as being easier than on github) so the original author can review them, but any of you are welcome to comment as well. The original discussion is here on github:
Unrelated to this part, but of interest: I am currently playing with making my own shaft encoders (the AMT103 is around $35 Can on digikey). I first used the Honeywell HOA0901-011 which was about $15 at digikey, but is now obsolete and $20 from the single source on ebay. Then I found the “Velocimetry Motor 334 line AB phase Encoder” on Ebay for $2.50 ea (unfortunately I bough all that were available at this price, but there are still some in the $3.50 range, still cheap compared to the alternatives). This is a small motor (low torque) with a 2mm shaft, a 334 line optical disk that can be removed (with difficulty!) from the motor shaft and a sensor like the Honeywell part, with active drive and I suspect comparitors on chip on a flimsy pcb that is easy to detach from the motors. This is worth it just for the optical part (which has no part number unfortunately), the motor and encoder disk are a bonus! I’ll probably produce a small board to hold the sensors (I have 3 so far where I destroyed the original board trying to put wires on it
.) If you want cheap shaft encoders this is a good bet!
That said here is a copy of the first part that has been done, the AMT103 encoder part (in three forms, the original part, the probable final part and an alternative schematic version):
original part
AMT103-orig.fzpz (5.5 KB)
likely part
AMT103.fzpz (7.5 KB)
alternate schematic
AMT103-alt-sch.fzpz (6.0 KB)
all three have different moduleIds so you can load all three at the same time if you like. To make things easy without having to download anything, png images of a test sketch using all three parts:
fzp file:
Mostly ok, added reference file and fritzing version to the module line. Removed some unneeded properties and changed the varient from 6 to 1 (as this is the first version of this part). Added a description of the part from the data sheet so it will show up in inspector, added descriptions to each of the pin names so the data comes up when you hover over a pin in any view. Add a url for the part datasheet, added a 1 (for the varient number) to each of the file names (and renamed the files to match after I found a new Fritzing bug when I didn’t rename them the first time
. Removed the terminalId definitions from all connector’s breadboard layer line as the terminalIds are not in the svg. This doesn’t hurt anything, Fritzing ignores it but the parts check script complains and it isn’t correct.
Breadboard:
Breadboard was mostly ok, it lacked a layerId (which breaks svg export in Fritzing), needed to be rescaled (as did all the svgs) . I increased the height of the encoder to match the real part (it was a couple of mm short in the original) and copied (probably poorly
) the connector from the encoder datasheet to indicate that it is a shrouded connector. I reduced the pin size to make the individual pins stand out better. Removed unnecessary transforms (possible performance issue, transforms imply a matrix multiplication at every render.)
schematic:
Again rescale the svg, change the units from px to in (px can cause scaling problems a Fritzing will guess at the original resolution 72dpi or 90dpi, I don’t think it knows about the current 96dpi), inches or mm isn’t subject to guessing. Made an alternate schematic with a standard box outline (alt schematic), but it isn’t much smaller than the one with the outline of the encoder and I think the outline of the encoder one is clearer and so should be the choice. Again removed unneeded transforms and unneeded parameters in the xml to reduce size / increase performance. The main user visible change here is adding terminalIds to the pins which corrects the “line terminates in the middle of the pin” problem you see in the original part. Without a terminalId Fritzing uses the center of the pin which looks ugly. I think the size of the original encoder is an example of the scale problem, as both sets of xml should be identical, but the possible part one is set to inches so scales correctly.
pcb, again rescaled and removed transforms. Fairly major changes here. In practice I don’t think it is likely the encoder will be mounted on the PCB. The connector (from the data sheet) doesn’t look like it would fit in a PCB, it is expecting an AMP connector and wires. Thus I replaced the connections with a 5 pin .1 header (and adjusted the hole size to 0.038 in, standard for .1 connectors). I also followed the original developer’s recommendation and removed the text in pcb view. The theory is that if the user wants the labels on silkscreen in pcb, they can add them via the text function in Fritzing, but if they are in the part, the user would have to make a new part to remove them. For reasons I don’t understand, the original part silkscreen renders very poorly in the gerbers (the xml looked pretty normal to me so I don’t know why exactly), I didn’t poke further because I wasn’t planning on using it on the final part. If you see something you don’t like or something I missed, please post here so I can correct it. The final objective is to get this series of parts added to the core parts distribution.
Peter
Posts: 1
Participants: 1
@vazquezjm wrote:
I’m looking for a generic TO252 / DPAK part.
Specifically for AOD4185, but a generic will work for me.
Datasheet: http://aosmd.com/res/data_sheets/AOD4185.pdf
Posts: 2
Participants: 2
@NoodleDriver wrote:
PIC16F628
PIC16F628_V1.fzpz (7.2 KB)
PIC16F628_V2.fzpz (7.6 KB)
Posts: 1
Participants: 1
@vanepp wrote:
I’m (slowly) working on making some fixes to the parts factory code. As part of that I intend to fix the dual row header code which is currently broken in breadboard (it doesn’t generate a dual row header although it does in pcb). As part of finishing off the TM4C123GXL part I implemented a new layout in schematic which I intend on trying to make parts factory emit in the case of a dual row header:
in this schematic the two center 20 pin connectors are dual row (manually done on breadboard). The change is the two drawings after the pin labels which show a picture of the actual connector and associate the schematic pins with their physical connection on the header. It may be necessary (or desirable) to be able to select whether the extra picture is there or not. I’m putting this here to see if anyone sees a problem that I am not with doing this. Comments are welcome. If you want to see this in an actual sketch, download the new TM4C123GXL part I just posted, that is where this schematic came from.
Peter
Posts: 1
Participants: 1
.) If you want cheap shaft encoders this is a good bet!
