Is there any history about why some parts use “breadboard” and others use “breadboardbreadboard” for the breadboard layer id?
I found 3 core parts where the fzp layer does not match the svg id, and was wondering if there is any reason change it one way or the other.
I guess it’s a typo.
It’s hard to say because the programmers left years ago and didn’t document every feature, that’s why we are discovering things 4 years latter.
Here is a vid that shows even more groups that aren’t documented, and I was wondering if these were features that never got added.
I’ve seen the keepout and soldermask groups before, as well as the keepout element in fzp part definition. Also, a google search got an interesting hit for a forum post that is not accessible. The preview content says:
Fritzing how do i use < keepout> < soldermask> < outline> in …
Hi Gijs, these are not supported in part definitions at the moment, as we did not find them to be necessary. Keepout and soldermask are automatically generated by the gerber export. If you want to define your own PCB shape, then you can create a boardoutline, as described in the custom PCB shape tutorial.
Where this started though, was standard layerId properties that link the part definitions to the svg ids. Those are not always fixed values. pcb layers have specific meanings, so they are not flexible. The breadboardView and schematicView layer names, by convention are “breadboard” and “schematic”, but as far as I can tell, any value can be used, as long as the layerId attribute value in the fzp file matches the id attribute value in the svg. Initially I thought that “breadboardbreadboard” was another convention used for the actual breadboard parts. That is where I first encountered it. But I see other parts using that breadboardView layer name as well.
And it is not good when they do NOT match. The parts actually seem to look and work fine in Fritzing, but they are blank boxes when exported as svg. I do not know what gerber export would do.
I am just looking for a hint about whether the layerId in the fzp should be changed, or the id in the svg file.
I think you are stuck like I was 5 years ago when I started with FZ and tried to make parts - there was NO one around to ask back then either -, and have to trail and error it until it works. I didn’t even know what electronics was above wiring cars, and had never heard of vector graphics, so it was months of trail and error because I knew so little I didn’t even know what anything could do. Basically I just opened parts, tried to copy them, and see what happened.
We had a discussion a few years back - there was only 3 of us - about using a fixed part making standard. Vanepp wanted rules, the other guy said “if it worked it’s good enough” and didn’t want rules, and I said parts probably should be made to a set of rules and approved before they could be added. My argument was that when I tried Kicad at the same time as I started with FZ, the first part I downloaded from the web was wrong, ie, home made and not checked, like all small EDAs. But a few years ago KC introduced part checking and an approval system, and now it’s much better, ie, more professional. And that’s when Vanepp made the part checking program.
Definitely with you and vanepp on this. That ‘good enough’ is the problem with the parts I was looking at from another thread. They work, as long as you only use them in the view. They break if you attempt to export as svg. And those are core parts.
I have a head start on where you started from. I have no EDA background, but worked with (self taught) general electronics and troubleshooting 50 years ago (radio and TV). Then moved to computer programing, which included working with (civil) cadd systems. Plenty of vector graphics in that. I am aware of the lack of information and history, but tossed this out in case someone around had heard something in the past. If there are rules, I’ll follow them, otherwise make it work.
Consistency really helps when trying to learn from what already exists. Copying something to use as a template that you have no way of knowing is broken to start with is real frustrating.
You know way more than me. 
Back then I didn’t know what a pullup was, so I didn’t know what to ask because I didn’t know what was possible. I did Mech Eng, but primarily metal fab, running an abrasive blasting shop, and then automotive machining. All I wanted to do was clean my injectors, but got sucked into electronics 6 years ago when I found an Arduino programmable EFI. I learnt stuff by reading and watching all of the EEVblog videos - electronic videos are my entertainment thesedays -.
If I listed all the problems with FZ I would cry 
, but the main reason I wanted parts checked and approved was that I saw so many people send off PCB’s to be made, only to be disappointed when parts didn’t fit. Also editing svg’s with different XML’s formats on each one was a PITA, because you had to figure out each one differently. Even with all it’s problems I still like FZ - it just looks better than the rest -, and because I know how to get around problems with it it’s not a problem for me.
Mechanical is my weak area. I know a lot of concepts, but no good with implementation.
Now that the new website has rolled out, there will be more time again to focus on the app and the parts themselfes. We have also been working on a new parts editor, which already has verification and syntax checks in mind. Checks written in python should be easy to integrate.
It will also warn and highlight for orphaned connectors, one of the most common issues with new created parts I have seen so far. Also, the editor will use the same rendering engine as Fritzing (QtSVG)
Fritzing does a lot to compensate for glitches in the part files, with “easy of use” in mind. Unfortunately, those glitches show then in other parts, like the export, so I think this approach is not consequential enough.
Besides this parts editor, I am also thinking about a feature on the website, where you could upload parts and have them checked. This could be a lightweight check against the most common issues. Or it could go as far as a review process for integrating parts to core.
breadboardbreadboard (along with a postfix of moduleId on the moduleId and the family as breadboard) triggers the breadboard code (always bottom layer, no pcb or schematic) and that is probably the only place it should be used. At some time the breadboardbreadboard got used in a core part and now gets copied. As long as the moduleId and family aren’t there it doesn’t appear to trigger any of the breadboard specific code though. I change it to the more standard breadboard when I edit parts (if the part isn’t a breadboard.)
Peter
Ah! That explains why I saw it initially in breadboard family parts.
Some of that breadboard functionality gets triggered just with the just the family name. That was how I got some breadboard only adapters to work correctly. To allow a 2 row 0.1inch spacing header to be plugged into the breadboard like a 300mil dip. Perfect for breadboarding with esp32 and other boards with a 2 row header, without running individual wires to the pins.
We likely need to check the source and see what combinations trigger code and advise against using those combinations in non breadboard parts. As I recall the arduinos are one coere part that uses breadboardbreadboard as the layerId for a non breadboard part there are likely others as well.
Peter
I am working on a python script that will scan for those combinations. Look at both .fzp and .svg layer/id and family.
I added a comment on the use of the breadboardbreadboard id in the Part file format. See https://github.com/fritzing/fritzing-app/wiki/2.1-Part-file-format in section " More SVG topics".
I directly copy paste the comment from Vanepp. I hope that you do not mind!
Should we indicate that there are several predefined layers ids and when you should use them? I have the feeling that they are not properly described in the document.
Not at all 
, more documentation is better!
Peter