I´m currently in the progress to build my own component (which is missing in Fritzing; but might be useful for other as well). I already spend a lot of time, but the manual offered for building a own component seamed to lack a lot of details (I think i will build a blog post about all my findings once I´m ready here).
I use the “Arduino Micro Rev3” as a basis component for my own one. My component is similar has also multiple pins (exactly 32 pins) and is only a little bit bigger.
Questions I currently have in that version I build:
1.) The Arduino PCB Board is always in line with the grid. Means the solder points are always on a cross from the grid. Not sure if that is required, there is no documentation which outlined that. What did I need to change, so that my one acts similar?
2.) the width and height I entered in my graphic program (Adobe Illustrator) isn´t what later is shown in fritzing. My Illustrator Artboard is 22mm with and 42mm height but in fritzing this is shown as with 22.141 and heigh 39.9753 mm. What is wrong here?
I have the feeling that question 1 and 2 are in relation together.
It would be a great help if @vanepp could guide me so that get that fixed
P.S. For others which might find that component here and also useful please keep noted that its not a final working version yet! I will release one once ready
Assuming the manual is that on the Fritzing web site, yes it leaves much to be desired. Try these two sets of tutorials (which apply to current Fritizng versions, many of the others are for older versions.) I’d be interested in what is unclear (likely lots!) in mine, as no one has ever commented on it. I generally don’t use parts editor, but Old_Grey’s tutorials cover it.
Usually the pins should be on 0.1in boundaries in breadboard and schematic. Fritzing will pick a pin and align it to the grid, pins that don’t align to that on a 0.1in boundary will be off the grid (there are a few other things that will cause similar problems as well.)
While I don’t use Illustrator, but rather Inkscape, as far as I can see from the online manuals for Illustrator there is no way for the user to control what it does. For Fritzing that can cause scaling problems. Inkscape allows much more control of the output svgs. Although your breadboard svg appears to be correctly dimensioned in inches (as opposed to px which can cause scaling problems. The connectors in the breadboard svg are not on 0.1in boundaries however (this is Inkscape not Illustrator:
breadboard looks somewhat OK (better than the rendered version for sure. It is likely that the pins should be connectorxpin not connectorxpad (pad is typically SMD in pcb) and indeed the .fzp file indicates they should be defined as pins:
in all three views. The definitions in the .fzp file not matching those in the svgs will cause the problems you are seeing as the connectors are not correctly defined (which causes the red rectangles.) The schematic svg needs to start at 0 0 (I don’t know how to do that in Illustrator, in Inkscape Edit->select all then Edit->Resize drawing to selection will do it.) but it needs to be done. This will also cause offset problems in Fritzing.
As well your connectors are not correctly defined. The connector0pin looks correct, but connector0terminal is in the wrong place (it should be on the left end of connector0pin.)
I’m not sure why schematic is unhappy (probably pin definitions missing though) Pcb has the pins defined as pad when they need to be pin to match the .fzp file:
So, sorry it took so long, but I now switched from Illustrator to Inkscape and learning the new GUI wasn´t that easy and took longer then expected :-(.
The main issue I had was, that I started to use Illustrator rather Inkscape, which seamed not be a good option. As you already mentioned Inkscape has some options which Illustrator is missing. So most of my past questions where “how to do that via Illustrator” which no longer apply as I will now use Inkscape :-).
So if you could have a deeper look on v0.9 if that fits now that would be brilliant.
Questions so far:
Q1: Is mostly the PCB part… I can see a keepout, outline, soldermask, copper0, copper1, silkscreen in a reference file, however I´m not sure which layers I realy need. It looks like that its not widly documented in the forum here. If I do not need most of them to order a PCB board that would be OK for me. All I could found is that here: PCB component layer names - #2 by vanepp it seamed …
Q2: Most examples have a PIN0 while Fritzing starts always with pin1. So I need to start with pin0? It seamed to be easier for me to start with 1.
Q3: I´m not sure when to use a layer and when to use a group inside Inkscape. It looks like groups seamed to be the prefered way, however fritzing seamed to accept (sometimes) both.
Renamed PIN correctly to connector1pin and connector1terminal
Sorted Elements
Changed Schematic to start at 0 0 (Via Inkscape Edit->select all then Edit->Resize drawing to selection)
Fixed the Terminal Point and set that to W,N,S,E according to the needs
Added/fixed the terminal “point”
Fixed the RedBox
BreadBoard:
Fully rebuild in Inkscape
Is now 16 columns and 8 rows in size
Adjustments to the XML section from the SVG file, so that the connectors can be auto detected by Fritzing
Note: the need to start with ConnectorNummberText
silkscreen and copper1 for SMD parts, copper0 (as a child of copper1) for through hole. I’ve never seen the other layers used for anything and they may not be implemented.
Parts are supposed to start with connector0 (which usually equates to pin1.) It will work, just not be quite correct if you start at 1. The difference is likely C++ starting arrays at 0 instead of 1.
I never use layers. The Fritzing documentation mentions layers but they really mean group (it actually says that somewhere.) so groups are all you really need.
I ran HmIP-MOD-OC8_v0-9 through FritzingCheckPart.py and it flags a warning (because it won’t break anything) about no connector0
Connector0 doesn’t exist. Connectors should start at 0
and some errors (mostly about bus members)
Error 53: File
‘part.HmIP-MOD-OC8_1ed0c3cff7aa35a4e5bd1c4caa11b240_2.fzp.bak’
At line 549
Bus nodeMember connector60 does’t exist
Error 53: File
‘part.HmIP-MOD-OC8_1ed0c3cff7aa35a4e5bd1c4caa11b240_2.fzp.bak’
At line 553
Bus nodeMember connector33 does’t exist
Error 53: File
‘part.HmIP-MOD-OC8_1ed0c3cff7aa35a4e5bd1c4caa11b240_2.fzp.bak’
At line 554
…
and finally it doen’t approve of your pcb svg.:
Error 69: File
‘svg.pcb.HmIP-MOD-OC8_ed6b63f3d782d66014cd3cc2f43aea42_47_pcb.svg.bak’
At line 10
Found a drawing element before a layerId (or no layerId)
which looks to be correct. The first two groups here are not part of a layerId (copper or silkscreen) which depending on what is in them may cause problems. It looks like they are harmless, boardoutline I think will be ignored.
typically text isn’t included in pcb. The reason is if you don’t want the text you need to modify the part to remove it. If you do want text in a part you can add it in the sketch.
as well the board outline wants to move from where it is in to group silkscreen like this (incidentally I ungrouped silkscreen to remove all the transforms, typically I prefer no transforms, they sometimes cause problems usually when copper0 has a transform but copper1 does not.)
Here I ungrouped both copper layers and regrouped them (which removes the transforms), the preferred order is as shown here silkscreen, followed by copper1 with copper0 as a child of copper1. If silkscreen is last it will be the first thing selected in Fritzing which usually is not what you want.
Now on to the bus complaints. It is complaining about these definitions (which are likely left over from the part you cloned this from)
connector59 and 60 don’t exist in this part and connector19 is internally connected to connector32 which may not be what you wanted. If you don’t have any pins that need internal connections you can just delete the entire bus section.
Many thanks for all the answers, I have the feeling that I´m very close to my v1.0 now
Q1:
Ok, then I do not need to care about other layers. As I´m quite new to Fritzing I thought they might be useful and later one painful to add. I´m coming from a VERY old Eagle Autocad version (which is overrated for most of my PCB boards anyway), so there is a lot new stuff for me in Fritzing at the moment ;-).
Q2:
I see. In that case I will start as well with pin0. I saw that when I start with pin1, that fritzing automatically detect these and assign the pin to the SVG file. This isn´t working when starting with pin0. However as my component here might be picked up by somebody else to build something new (there are some other HmIP-MOD-* Modules), I will start as well by pin0 to avoid any design issues. Rule is rule
Q3:
Ok
Q4:
I saw as well numbers and a box inside the PCB Layer from the “Arduino Pro Mini v13” PCB. They match the view “Silkscreen Top”, so I thought that might be the view which can be later printed on the PCB board. Isn´t that the correct place for? My goal for component part is to build a bigger PCB board and order that online.
Q5:
The BUS option is quite new to me, didn´t read about that and the part editor didn´t showed a option to build them. But yes looks like its from the clone. However as in my part Pin 10,11,12 (and others) are all ground. I think it would correct to do a bus for all of them like I did in the attached version, isn´t it? Technically there is no difference in using ground on pin1 or 19, using the bus fritzing should automatically choose the best option or? The question here is now do I use here pin1 or pin0. I assume pin1 but I´m not totally sure.
Q6:
By the way, is there now a option to add new components directly into the fritzing version (maybe via forking the GitLab repro)? would be nice to see the parts growing inside the software itself and would be my way to get involved in the opensource project.
So based on your input (didn´t know about FritzingCheckPart.py, however using that on a Windows OS do not look so easy for me, didn´t got it working here) I build now v0.10:
It will work with text on the silkscreen layer in pcb (the text will appear on silkscreen on the pcb.) The problem is that if the user doesn’t want the printing on the pcb for any reason, with the text in the silkscreen layer in the pcb svg, they need to make a new part to remove the text. If the text isn’t in the part’s silkscreen layer in the part it can be added to the sketch (via core parts->pcb->text in Inspector) without needing to modify the part, and therefore that is the recommended way to make parts. As noted the text on silkscreen layer works fine though.
As long as all the ground pins on the board connect to each other internally to the board (which is normally but not always the case), then they should be in a bus in Fritzing.
To Fritzing all pins in a bus are the same so it will connect to the ground pin closest to the connection. One wrinkle is that in schematic (which is an abstract view) only one connection to a bus is allowed. That means if you do what I usually do and have schematic match breadboard (i.e multiple ground pins) sometimes Fritzing will not make a connection to a pin if there is another connection already made. One solution to this (which I don’t particularly like personally) is to overlay all the common pins like this:
Here all of pin/terminal 10, 11, 12 are in the same place (overlaid on pin 10) and thus will connect to a common point. As noted I don’t like this and don’t often do it.
Yes. If you clone the Fritzing-parts repo on github and add your part and make a pull request it will get added to core parts (assuming it passes QA!) in due course.
It is unfortunately not all that user friendly. While I normally use cygwin it should be possible (although I haven’t done it) to run it from a native python 3 install. You would probably need to use pip to add the lxml module though. That doesn’t make it much more friendly though, but I don’t know of a way to do that. Here is what FritzingCheckPart has to say about the new version (still some problems!)
In order, the pins don't start at 0 they start at 1 still. connector0terminal isn't actually used so it being a group (while incorrect) is irrelevant. The scale isn't as recommended. This will work fine (and thus is only a warning) but in Inkscape is also easy to fix (assuming Inkscape at least!)
then ungroup everything which will remove most transforms. Now Edit->select all, then check that the starting x and y are both 0 (do Edit->resize page to selection if not!), lock width to height, set dimensions to px (finest resolution) and record the current width value (163.200px in this case) and set scale stroke width (which I normally leave off.) like this:
on the way by I changed the name of connector0 from textpin0 to connector0pin (the renumber script is looking for connectorpin0 to start renumbering the pins!) Then do the same for all the rest of the pins to get this
note the first two pins are out of sequence (connector1pin is missing.) Now I save the svg in Inkscape and run (so far unpublished!) python script which renumbers the svg like this:
now the pins start at connector0pin and run sequentially to connector31pin as they should. We still need to change the other svgs and the .fzp file, but for now on to schematic. It has a variety of problems. Its scale is wrong
the pin is too long (0.2in instead of 0.1in and the color is wrong (#787878 insteadn of #555555), the text sizes look to be incorrect and the incorrect color as well. The easy fix to this is make a new schematic with Randy’s Inkscape extension available here:
start with a blank canvas (here I started from the schematic svg and deleted everything)
Here I set the height to 1.7inches because there are 16 connectors on left and right. A width of 0.8in is about correct and set the label from the original schematic as the new label name. Now switch to the connections tab and set our connections.
Here I set 16 connections on left and right sequential pin numbers and user defined labels as well as create terminalIds. Now hit apply and set the label names like this:
Here I copied the labels on the left from the original schematic svg. Once all the pin names are entered click finished to get to the other side like this (note that on the right side the pins start from the bottom not the top!)
and schematic is now complete ready for use.
In the original schematic the no schematic layerId is important because your part won’t export as an svg or other image type (it will be blank in the export!) that can be fixed by grouping the entire svg and naming the group schematic like this (or by using the new schematic svg which is what I will do!):
Here pin 23 is missing its terminalId and thus connects to the middle of the pin (which is incorrect!) pin 22 has a correct terminalId and is thus correct.
Now on to pcb. Again the scale is incorrect, so set it to 1000 as with breadboard. Then change the border outline stroke-width to 10, change textpin0 to connector0pin to establish pin0 for the renumber. As well change the pad radius from the current 27.5 to 29 to make the hole be 0.038in suitable for a 0.1in header(0.032in is probably too small!) for all pins (I will make this change in the svg with a text editor!) Also increase the size of the rectangle on connector0 to a stroke-width of 20 and height and width of 0.078in and set the x and y coord to be the same as connector0pin so the two are aligned.
As noted I deleted the text to allow for users that don’t want text on the silkscreen, you can add it back in if you choose. Then ran the script that renumbers the pins in the svg and pcb is done. Now on to the .fzp file.
First I changed the Fritzing version to 0.9.10, then deleted the connectors (because they have been renumbered) and replaced them with a set correctly sequenced generated by a script I have. Now I need to set the description fields and adjust the bus definitions to match the new pin numbering and add a label of “A” (for assembly) and we are done. Since the board silkscreen no longer has numbers you need to add them to the sketch like this:
The text is set by typing in inspector on the right, font size can be adjusted just below the text field. It means this must be done in every sketch though so you may want to leave them in silkscreen. One additional issue if you are not using FritzingCheckPart.py, one of the things it does is remove the px from font sizes. Inkscape adds them to be CSS compliant but Fritzing objects to them and will sometimes set the font size to 0 ( making the text unreadable) or a large value (making the text too large.) You can remove them by editing the svg with a text editor and doing a global replace of px with “” or use @just_randy 's new Inkscape extension which removes pxs Fritzing-Fix text but when I checked it doesn’t look like it has been released yet (I have a review copy), so you may need to ask him about it. Hope this helps.
Here is a part with the above changes made in it.
@vanepp, I´m currently building the PCB board based on the part you helped me to build. During that I discovered a strange behavior, maybe you can help me to explain why that happen?
What I did (see board attachment at the bottom):
I added a single female header to pin2 (reset) on the ardunio:
There are more problems than that. The most serious is that one of the pins in pcb has no radius (it is a ellipse) and thus won’t be drilled making the pcb unusable. I will post a fixed part in a while.
you are right I think that TX and RX seamed to be mixed as well. Lets move that to the topic: Bugs in Arduino Nano Every Fritzing part v6
So others might find that and its not in my thread … By the way I´m currently on the way to fix some of the issues I saw (because I need that in my PCB). Should take me a hour, then i will update the posting in the URL below with my version. Maybe you can do a quick check then.
To check bus connection groups, or problems with the same, left «select» click and hold on a connection. The pin will highlight in yellow, along with all connections that are in the same ‘net’. That net will include all connections that are explicitly wired, plus connections linked through one or more bus groups. Nets are followed through ratsnest wires as well.
For the screenshot below, I click on the connection at the blue circle. The connections in the green lasso show as connected, indicating that a bus exists.
I think that TX and RX seamed to be mixed as well. Lets move that to the topic: 