You can’t really win assigning pins either way. If you have a lot of pins it’s a lot of work doing it in the actual svg phase, yet if you do it in FZ Edit and you have to mod a svg after the pins are assigned, everything is buried so deep in groups it’s hell to go back in and change stuff. If they could solve the multiple superfluous groups problem FZ Edit would be way quicker.
↧
Standardization of Fritzing part design
↧
InvenSense MPU6050 (GY521)
In the PCB view VCC doesn’t have a round connector on the square one.
↧
↧
Standardization of Fritzing part design
You just press “ctrl shift g” in Inkscape until it is ungrouped back to the named groups (ie. copper0, silkscreen). It gets rid of the groups and preserves the pin assignments.
↧
Standardization of Fritzing part design
It is a bit tricky because it deselects the group in the XML dialogue so it looks like nothing is selected, but thankfully it stays selected in the drawing so it groups back in one shot.
↧
Soldermask on vias
I was getting tired of repeating the steps above after every little change I made to my files so I decided to see if I could modify Fritzing to export gerbers with the vias tented. It turned out to be a trivial change. I have created a branch with tented vias. https://github.com/Intrinsically-Sublime/fritzing-app/tree/Tented_Vias
To use it you would have to compile the source so it is not as easy as downloading and for most people the steps in my post above will likely be easier. I will make a pull request to to the main repo but it may not be excepted and even if it does get excepted it may be a long time before we get a binary release.
↧
↧
InvenSense MPU6050 (GY521)
In case @Old_Grey 's comment isn’t clear the parts check script has this to say (and is correct, there is no hole being generated for pin1 in the gerber as only the square is present, it needs a circular pad just like all the rest under the square to generate the hole):
Error 74: File
’svg.pcb.MPU6050_GY521_782354e339f672575bb20992ece4ab1b_9_pcb.svg.bak’
At line 65
Connector connector0pin has no radius no hole will be generated
Peter
↧
InvenSense MPU6050 (GY521)
Thanks, I just came back to home and will fix this as soon as I can. Good catch 
↧
Standardization of Fritzing part design
I think at this point, since the current code base seems to be pretty much dead, our best bet is to decide how we would like things to be in future and try and try and influence (preferably by helping develop 
) the new code base being proposed.
Peter
↧
InvenSense MPU6050 (GY521)
Does the part checker fix problems, or just reports them?
↧
↧
Standardization of Fritzing part design
Agreed, especially on the board / shield parts like the arduino ones. I haven’t finished mine because there are tons of them and I do rather prefer pin assignment through svg labels.
Well, I will keep an eye on the new JS API since I know how to code on javascript but also keep practicing on parts creation since it is fun (and rewarding).
↧
InvenSense MPU6050 (GY521)
Just reports them, its up to you to find and fix them (at least most of the time, for some things like reference file names it does correct things).
Peter
↧
Standardization of Fritzing part design
That is a good plan. I think the new version should still use (or at least use) current parts so new parts will work on both the current version and the new version. As far as I can see the Qt code is probably a dead issue and we should be focusing on the new code (I still haven’t yet figured out how to run it).
Peter
↧
Standardization of Fritzing part design
I’m fairly sure it is just an API that allows you to use Java to access Fritzing parts. It currently doesn’t really do anything on its own as far as I understand it.
It seems more of an idea by someone more familiar with Java than with C++ and QT trying to get people involved in porting Fritzing to web technologies. Like tens of thousands of projects on Github it may not go anywhere.
I myself will be concentrating my efforts on the current Fritzing application as it works and if we abandon it you will only ensure it dies.
↧
↧
InvenSense MPU6050 (GY521)
Fixed version. Everything has been tested again on Fritzing
InvenSense_MPU6050.fzpz (18.6 KB)
↧
Standardization of Fritzing part design
That is very possible, as I know next to nothing about javascript (which, thank god, is different than java which is a performance pig due to garbage collection). From what I see of the stuff I needed to install, looks to be light weight (and therefore in theory fast, in practice we will see) but it is implied that this is a parts viewer of some kind and its extremely possible I just don’t know what I’m doing. I guess we will see if the folks writing it reply to the various posts. The code snippet in the readme.md file appears to make a server of some kind (a similar one I found on stackoverflow creates a server that outputs a “Hello World” web page successfully), but for me the code snippet errors out before starting, possibly due to something I’m not doing so I have some feeling it may do something if I knew how or you could be correct.
I think concentrating on fixing up the parts repository is worth doing and there is certainly lots to clean up about that. It is much less clear to me that there is much purpose in trying to improve the Qt based code as it looks like (as it has for some time) development interest in that code base has died. I’m an outsider and a relatively new user, el-j as far as I know was a key member of the original team and I expect he has a lot better idea than any of us of the chance of the Qt code going forward and it doesn’t seem that he sees much chance of that from his posts. I guess time will tell.
Peter
↧
InvenSense MPU6050 (GY521)
Mostly fine, a couple of nits: the holes are .040 rather than the standard .038 for a .1 header pin. Either should do (I think .040 may round up to .042 or thereabouts though but I’m not sure). You can fix that in Ink (assuming 10.4667 scale and 20 thou stroke width) by changing the hole diameter in the tool bar from .080in to .078in height and width. That will move the center of the circle (which you don’t want) so in xml editor note the new radius value (and make sure it is r not rx and ry which makes an ellipse) and undo your change so the pad goes back to the correct position. Now in xml editor change the radius to the value for a .038 hole you discovered above. Changing the radius (rather than the diameter) leaves the center x/y position intact and changes just the diameter of the circle so you don’t have to move the x/y coords of every pin. Repeat this for all 8 pins. The second nit is you have eliminated the square on pin1 in pcb. If you add a square with height/width the same as the circular pad on top of the pad and aligned to the x/y coords of the pad you have the square will come back as it is currently in breadboard (and I assume on the real board).
edit: a look at the pcb svg says I’m wrong (as is the original maker). The stroke width is set to 17 and needs to be reset to 20, the diameter is .074 (r 28.5) and a stroke-width 20 part needs a radius of 29 to make a correct .038 hole in the correct position.
Peter
↧
Standardization of Fritzing part design
From El-j’s other post they say.
followed by
The API is important and what the program will be built upon but it is far from a interactive program. He does say they have built a parts viewer using the API and the following post by paulvollmer says if you want to try it out to contact them and they will add you to the hidden private repo so you can alpha test it before it goes public.
↧
↧
InvenSense MPU6050 (GY521)
In which view?
So I only have to change things at PCB?
EDIT: InvenSense_MPU6050.fzpz (19.2 KB)
Okay it is done, I will stop making changes to this part xD
Also, here is a reworked version of ultrasonic sensor HC-SR04 that was made by Richard. I hope I renamed it like the current one so it gets overwritten when uploading to github.
HC-SR04 Ultrasonic Distance Sensor.fzpz (51.8 KB)
↧
InvenSense MPU6050 (GY521)
Unfortunately no to both. The part is still incorrect. From the gerber drill file obtained by exporting the pcb to gerber file->export->for production->extended gerber, in my case Untitled Sketch_drill.txt:
; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T100C0.037000
T101C0.040000
%
T100
X014222Y008222
X014222Y010222
X014222Y007222
X014222Y011222
X014222Y012222
X014222Y009222
X014222Y013222
T101
X014222Y014222
T00
M30
we see a number of problems: the hole size is .037 (not .038) for 6 of the holes, one hole is .040 making pcb incorrect. Switching to svg.pcb.MPU6050_GY521_782354e339f672575bb20992ece4ab1b_9_pcb.svg (the pcb svg in your part) there are also a number of problems: The first group g58 has a translate. In pcb translates get tricky in that the values are supposed to be inherited but that doesn’t appear to always happen. The safe way is to eliminate all the translates in pcb. The next problem is that pads don’t have my corrected parameters (I’d guess because of the translates being used to change the coordinate space to approximate the correct values because they are almost right). I don’t see why one pad is .040 instead of 0.037, but my guess again will be translate somehow. As I said the r wants to be 29 not 28.5 and stroke-width wants to be 20 (with no translates) which should produce the correct size holes of 0.38. So in Inkscape xml editor I selected the top group (g58) and then hit shift-cntrl-g to ungroup until there were no groups left. The left me with pin0 with a stroke-width of 17.x and the rest at 20.x and the radiuses at 28.5. Using xml editor to change the radius to 29 and the stroke-width to 20 and then regrouping silkscreen (including the text) and copper1/copper0 should produce the correct pcb svg. The different stroke width on pin0 will be why the one pin was a different size (and indeed appears to be caused by the translates).
I’ll look this one over in a bit. Unfortunately like many things in Fritzing, replacing an existing part is complex (there are special undocumented anywhere I am aware of commands in the fzp file for doing this). What usually happens is that el-j (the parts maintainer) manually does this because he knows how and at least I don’t which is why there can be a delay in getting a part added and sometimes a part will be rejected as it can’t be converted
edit: Again a number of problems: Schematic and pcb aren’t scaled to 10…41667, schematic pins aren’t aligned on .1 boundaries (they are a little high, possibly an artifact of the original not having height/width specifed in inches but rather px and being misscaled). Pcb doesn’t have an outline of the size of the complete board in silkscreen and the connector holes are 0.030in and should probably 0.038 for .1in header pins which is typically what these boards come with.
Peter
↧
InvenSense MPU6050 (GY521)
I don’t know about this only one size(0.038") for every hole thing. If you look up 5 different manufacturers datasheet for pin header you get 5 different hole recommendations, and even then when it gets sent to manufacture the PCB production house picks the nearest drill size anyway. That being said if we only use 1 hole and ring size for every pad it would make things easier.
↧