Ah, yes I had misunderstood what the issue is. I was expecting the pads to be on both sides of the board. All the cases I’ve seen have had symmetrical pads, so I expect you are correct if the pad is non-symmetrical that the bottom one will be a mirror image of the top and need more adjustment if that isn’t what you want.

Peter

True, because the lack of tutorials regarding how to use Inkscape for svg creation and making those work perfectly on Fritzing which is what we are discussing right now.

I haven’t seen any part made by you since I just go ahead and try to make my own parts design while sticking as much as I can to the real looking in order to obtain a high quality part and accomplish user needs.

I haven’t done anything like IC since I want to produce the same looking PCB of real parts. As you can see, the three current parts done by myself have been 2 little modules and one big board (LinkIt One).

I feel like pin label assignment is way better achieve through svg id renaming instead of doing it on Fritzing editor. The first way does let me edit the piece, move things around and such stuff, then just load it on editor and it automatically assign them for you.

It is my personal thought since I had problems while trying to import the pieces due to generated temp files every time I load a new breadboard svg file that gets stored on fritzing folder.

I hadn’t idea of these tutorial

I have the same opinion about Fritzing strongest feature so far.

I don’t want to sound rude but it seems that we don’t have a common agreement on how to make the process of the parties friendlier and the best possible for this.

As I can see, the learning curve has been different for many of us, but seems to be some who are in favor of making the pieces work with the grid of the program, others looking for a piece as accurate as possible (in measures) to the real one and finally, some that only want the piece to be functional no matter what else.

I really didn’t found an Eagle file for my current pieces and just downloaded eagle in order to check an Arduino Ethernet Shield 2 size (today), but I do rather prefer making the pieces good looking and sticking into Fritzing grid (doesn’t matter if pin / headers doesn’t match real positioning) if its cost me like 2 days or more (which is my current average).

Great! So you guys are gonna do some kind of “Part creation guidelines” along with this new API client?

Yes and if you put copper1 inside copper0 then it allows it to be on both sides without the possibility of being wrong. So I think it would be best if your script did check for it just in case a part has a non-symmetrical pad.

Oh, the name got me a bit confused until I read your clarification.

It’s great so see the developers of this software around these forums (I am newbie here).

I knew there was going on something different after looking at Fritzing Github group.

Yeah without mention the documentation regarding to how to contribute is a bit harder for newbies.

To the point, as I haven’t had got time to download the Qt software and dig into fritzing code (besides already forking the repo) because I got distracted making parts, it is great to see some Fritzing development.

I do have some basic to intermediate knowledge on Javascript at the Front-End, but haven’t done anything on the Back-End. I only have done the Codecademy course of React Part 1 but I would like to help on Fritzing development. I am not software / programming engineer but love programming stuff and could be awesome to contribute to this. You can find me on GitHub with the same username KingDarBoja.

How much knowledge is need, that’s my doubt.

You do not need to be making an ic to use the generic IC as a starting point. It allows you to assign the pins in a pop up by clicking edit pin labels in the inspector after you set the number of pins you want on your new part. You then have a completed schematic. Then once that is done you create your BB and PCB svgs and go into the parts editor and upload the new image for each view and assign the pins which already have the correct labels because you labels them when it was still an ic.

Also if you use the editor you should never ever ever open the Fritzing parts folder. You use the editor to export and import SVG images. You never have to open the fzp files or unzip fzpz files at all. If you edit the files Fritzing creates when making parts you are likely to run into these corruption issues and complaints of parts already existing etc.

I do not tend to upload a lot of the parts I create unless someone comes along asking for one that I already have. All of my parts are created for making PCBs and I have ZERO interest in Breadboard. I work almost exclusively with SMD parts so all of my parts are usually little green adapter boards or ICs in BB view and even sometimes just a copy of the PCB svg which is useless for BB view.

Even though I sound against a standard I feel a set of guidelines for creating BB svgs would be very useful for those interested in using Fritzing for the Breadboard view. It just doesn’t happen to be me since I use it for PCBs and making parts for PCB creation is easy as pie Generate Schematic using mystery part or generic IC, change the labels, create PCB svg, change PCB svg in the editor and assign the PCB pins. Done and off to the board shop.

This tactic sounds interesting to me but I feel like schematic view is going to have too many pins that have the same function like multiple GND, VCC, 5V, etc. Since I am more focused on microcontroller boards parts like Arduino ones, I feel like making my own schematic should be better done without that ammount of pin connectors and instead opt for staking and hiding them.

What I mean is that every time I load a new svg to any view, the program creates the same prefix part (for each view) with a different id. But probably I am doing something wrong when trying to export as I see there are two export options on Fritzing.

As note, I use spanish fritzing version and the current translation is awful as hell!

Still gonna try your suggestion if I get a non-microcontroller board.

This is my main purpose for using Fritzing

This is what it does but you shouldn’t ever be opening those folders so you shouldn’t know they exist. If you want just the SVG to edit you should open the parts editor, go to the view you want to export and then go to the file menu and export as SVG. You can then import it after you make changes in the same way. No need to ever open the fritzing folders.

Yes in the parts bin area the first export is export the entire bin and the one near the bottom is export part. I am sure the translation is the source of this issue.

Exporting from parts editor doesn’t work, it generates a empty .svg file I am using Windows OS in case it is a bug.

You are right, noticed it yesterday while doing some part fixes. Just an example of how things are awful for most users.

Is this a file you have created or edited the SVG manually? I find those files break things. Try exporting something from the first section of the core parts like a resistor SVG to see if it works. If it doesn’t work that is a serious bug since it is the same svg exporter used to export screen shots and svg files for home etching.

edit: missed adding the quote for context …

While obviously since I’m not them and I don’t know for sure I would expect that is a lower priority for limited time than making the code work. That may be an area where we of less skill in code development can help if we choose to. If you are familiar with how parts go together you can likely document it and the developers likely don’t need the documentation and are focused on developing the code. Manpower willing to donate time is what Fritzing needs most. There is more than enough work for anyone willing to help.

This one is actually a bug in parts editor (which I have a fix for). If you edit a part, click export as new part then export the new part from the mine parts bin and exit Fritzing, it will not actually delete the part created by parts editor. If you then try and reload the exported fzpz file (without doing anything to it outside of Fritzing) you will get the “already a part with that name” error (even though there is no such part showing in the bin that you could delete). When parts editor creates the new part, it currently does not register the files with the main window that will delete the files when you say don’t save on exit. Since parts editor doesn’t delete the files and mainwindow.cpp doesn’t know about them, the files stay in the bin and you can no longer load that part again until you manually remove them (which you can’t do from fritzing because internally they aren’t completely there). That said, I think this is now a dead end and effort should go in to the new project. Reading between the lines (and from stuff I’ve seen elsewhere, and thus maybe incorrect ), I think Qt in the new project is being replaced by html5. The reason I think that is there is a white paper on the Qt site about why Qt is better than html5 which tells me that at least some of the Qt functionality is available in html5. As noted, I’m ignorant and could be wrong here.

No, schematic must have the same number of pins as bb and pcb views or the part won’t work. You can (as you did in the linkone board) stack the pins on top of each other (which I don’t like) but you must have all the pins for the part to work correctly (unless you do some manual editing in the fzp file and know what you are doing). This is what causes the part to be entirely red when loaded, pins now assigned. That is usually how I start a new part, by editing either the generic IC and changing it to the number of pins I need or doing the same with a generic header. Then all the necessary connectors for the part are in the xml and I can edit the svg and put the pins where I need them.

Yes it is likely a bug. I must have discovered that long ago and put it on the list and forgotten it. To export a part from parts editor I edit the part then save it as a new part (which puts it in the mine parts bin with the bug noted above) and then right click on the part in the parts bin and click export part which writes the fzpz file to the file of my choice outside Fritzing. I then unzip that modify the svgs and reload the part (after deleting the left over files from the bug in the user directory) to Fritzing to check it.

Peter

I think there is also a time optimization scenario, ie put your time where it best accelerates FZ.

If it’s a part that a lot of people are going to need then yes make it perfect. If it’s a part no one will want short-cut the complicated time consuming BB view.

I made this GM MAP sensor, and since hardly anyone will want it I just got a pic and ‘Trace to Bitmap’ in INK and added some contacts. For the 10 people that download it it will do just fine.

I think this technique is great it is just to bad that they are not allowed in Frtzing core parts because of how much larger the files are compared to SVG files.

The size of the BB svg is dependant on how many scans you select in Trace to Bitmap - I think it creates 1 path per scan -, so maybe that can be optimised to cut it down.

I can’t see there ever being a proper situation where you would export a part and then import the same part. If you just exported the SVG you want to edit and then import the edited SVG this would never happen. Again this is a situation where trying to not use the editor provided to you to edit the files causes more problems.

Also for Fritzing to recognize changes in the parts bins you must restart Fritzing and it will ask if you want to save the changes. I am not sure it this solves the issue created by reimporting an existing part that you have just deleted but it may. But again if you didn’t create the problem by trying to circumvent the editors function you wouldn’t need a work around. If I want to replace a part I will just change the SVGs and metadata of that part or create a new part and then delete the old.

Sorry if I sound negative, that is not my intent and everyone should continue doing things the way they are most comfortable as that is what I advocate. People should be able to work the way they are most productive rather than be forced to do things as someone else says it should be done.

While it isn’t why I do it usually, backup is one. Exporting the part saves a copy in a directory not controlled by Fritzing which means I can restore Fritzing from a clean install then import the new parts from my backup if I need to. Another reason would be too many parts cluttering up the bins, so export the ones you aren’t using right now. If export doesn’t have a use then it shouldn’t exist. Given that it exists it should not corrupt the Fritzing state in such a way that you can not do anything except manually clear files. As I said I have a fix that registers the part files with the file deletion mechanism which does cause the files to be deleted if you say yes delete the files and will then let you reload it as it should, so I think it really is a bug.

Nope. The sequence is edit the part, save as new part, export part, shutdown Fritzing. At this point the shutdown asks if you want to save the new mine parts. Answer no don’t save the parts and it will not in fact remove the files in the user directory for the new part, it will remove the part in the database I believe as it is not in the mine parts bin on reload. When you restart Fritzing and try and load the part you will get the “part already exists” message because the files exist in the My Documents directory, but since Fritzing doesn’t have the part in the database you can’t delete it (because Fritzing doesn’t know it exists to delete I think because some of the references, just not all of them have been deleted). As I said this isn’t to do with editing the files outside only exporting a part and not saving the mine parts bin copy. I suspect if you say yes save the part, on reload you will be able to delete it successfully because the reload will populate the database correctly (but I can’t say that I’ve tried this either).

Peter

It asks if you want to save the changes to the bin not to save the parts. If you say no then you are telling it not to save the changes which include things like deleting parts. You need to say yes so it saves the changes.

But you also say reasons for exporting files is to as backup and in that case you would not have the issue of it saying they are already exist because you are restoring things.

You also mention the clutter but for that you create new bins and sort your parts in bins. At that point you export entire bins to backup your parts and make restoring easier.

But my point was more that it is your actions that create the issue. If you didn’t save as a new part, export, delete and try and import again it wouldn’t be an issue and you may not even be aware the possibility of creating un-importable parts existed. If you simply used the editor as intended this bug would only come up maybe once a year at most. I can’t say I have had the issue except when you have edited one of my files manually and gave it back and it wasn’t importable. If you had imported the part, made changes in the editor, saved the changes and exported it Fritzing would have advanced the unique number (it does this every time you save the part in the editor) and that would allow it to be imported. But since you unzipped it, made changes and rezipped the file it was incompatible.

Sorry if that feels a little personal. It was not my intent to make anyone feel bad I just get frustrated seeing people making their lives harder when they could avoid the issues in the first place.

With some effort I have (I think) managed to install fritzing-parts-api-client-js on my windows box, but when I hit the Usage section, I’m not sure where the listed code should be run. Running it from the git command prompt where I did the install doesn’t work. Could you point me at where I should be expecting to run this please? I’m logging my install steps and if you don’t mind (and assuming I get something running) will post it here for others to try out too. As well the issues portion of the repository isn’t working (or I don’t know how to use the template, either is possible). I was going to raise the issue that the link to the fritzing-parts-server (https://github.com/fritzing/fritzing-parts-api-client-js/blob/master/fritzing.github.io/fritzing-parts) currently 404s but the issues page wouldn’t accept an issue (at least from me as vanepp on github) or as I said I got the template filled in wrong (not sure which) as I’m not that familiar with github. Its also possible that it is supposed to be accessed by the app and that is why the 404 from a web browser.

Peter

Good night Fritzing forums!

I have completely reworked an old but common sensor module for Arduino projects, the MPU6050 (GY-521 Breakout board) which is basically an accelerometer plus gyroscope for robotics and such stuff.

I made it since I wanted to improved an old fritzing version available here to be more appealing at breadboard and pcb design.

Made from scratch in like 4 hours

InvenSense_MPU6050.fzpz (18.6 KB)

Thanks didn’t notice that. It worked.

So for THT it’s copper0 inside copper1, and SMD copper1 inside copper0.