I was just editing my first reply, here is a corrected version of your part (not exactly correct yet but much better) and how I got there.

First I unzipped your fzb file to get

DC_DC_Converter_XL4016.fzb
’part.MPU-6050 GY-521_27d4eab32ad654bb2011bfb7d4e898dd_3.fzp’
‘part.Sensor Shield v5_bfaee848f06338d8b00dadc40aa01172_15.fzp’
part.xl4016_c78f89428dcf787d84bc8d8066ed2354_10.fzp
’svg.breadboard.MPU-6050 GY-521_5bd41e1b055f687022fb2f2e39366183_2_breadboard.svg’
‘svg.breadboard.Sensor Shield v5_5de0a662573cea8393973ba9d5686ea2_1_breadboard.svg’
svg.breadboard.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_breadboard.svg
’svg.icon.MPU-6050 GY-521_5bd41e1b055f687022fb2f2e39366183_2_icon.svg’
‘svg.icon.Sensor Shield v5_5de0a662573cea8393973ba9d5686ea2_1_icon.svg’
svg.icon.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_icon.svg
’svg.pcb.MPU-6050 GY-521_5bd41e1b055f687022fb2f2e39366183_2_pcb.svg’
‘svg.pcb.Sensor Shield v5_5de0a662573cea8393973ba9d5686ea2_1_pcb.svg’
svg.pcb.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_pcb.svg
’svg.schematic.MPU-6050 GY-521_5bd41e1b055f687022fb2f2e39366183_2_schematic.svg’
'svg.schematic.Sensor Shield v5_5de0a662573cea8393973ba9d5686ea2_1_schematic.svg’
svg.schematic.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_schematic.svg

then I edited the

part.xl4016_c78f89428dcf787d84bc8d8066ed2354_10.fzp

file which has incorrect values for the svg file names (which is why Fritzing hangs, because it can’t find the svgs).

Problems:

fzp filenames are incorrect, the referenced files don’t exist.

  <layers image="icon/xl4016_e051a9ea7b14f7f51eaa32f20e0976f6_2_icon.svg">

to

  <layers image="icon/xl4016_c78f89428dcf787d84bc8d8066ed2354_10_icon.svg">

then

  <layers image="breadboard/xl4016_e051a9ea7b14f7f51eaa32f20e0976f6_2_breadboard.svg">

to

  <layers image="breadboard/xl4016_c78f89428dcf787d84bc8d8066ed2354_10_breadboard.svg">

then

  <layers image="schematic/xl4016_e051a9ea7b14f7f51eaa32f20e0976f6_2_schematic.svg">

to

  <layers image="schematic/xl4016_c78f89428dcf787d84bc8d8066ed2354_10_schematic.svg">

then

  <layers image="pcb/xl4016_e051a9ea7b14f7f51eaa32f20e0976f6_2_pcb.svg">

to

  <layers image="pcb/xl4016_c78f89428dcf787d84bc8d8066ed2354_10_pcb.svg">

then change the 4

<connector name="IN-" id="connector1" type="female">

to

<connector name="IN-" id="connector1" type="male">

With that corrected, make a part by zipping

part.xl4016_c78f89428dcf787d84bc8d8066ed2354_10.fzp

svg.breadboard.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_breadboard.svg

svg.icon.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_icon.svg

svg.pcb.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_pcb.svg

svg.schematic.xl4016_c78f89428dcf787d84bc8d8066ed2354_10_schematic.svg

in to

DC_DC_Converter_XL4016.fzpz

to make a loadable part file (still has problems but should load now). Indeed the new file now loads. This is a sketch that includes the corrected part with some test connections to check the part:

xl4016Sketch.fzz (14.5 KB)

If you download this and load it in to Fritzing you will get a sketch that contains the new part in the temp bin. If you right click on the xl4016 part in the temp bin and select “export part” it will export the new part as an fzpz file. Over all this is an excellent first part, most things are fine. However in schematic view you will see the rats nest lines are connecting to the center of the pin rather than the end as they should be . That is caused by the terminalId being either missing (in which case it will default to the middle of the pin) or in the wrong place (I think it is in the wrong place in this case as it doesn’t seem to be missing. When I exported the gerber from PCB view, the size of the holes on you board are .028in and should be .038in to connect to .1 in header pins. I’ll now make another part that corrects all the things the part script finds wrong and post a correct part so you can see what changes I have made.

Peter

Woah! That was a fast fix. Thanks for pointing out the problem, I am newbie exporting even following the export tutorial wasn’t enough to do it correctly.

Now about the “pin” connection, it is supposed to be a “Screw Terminal Wiring Connector” (I think it is the name of the blue thing), that shouldn’t be soldered right into the PCB but for aesthetic reason, I placed the holes to help with PCB design. Not sure if you get the idea.

I will take into account your tips (you should do a tutorial?) when finishing the other part I am doing (Arduino Mega Shield 2.0) and check if everything is ok.

Once you get through the parts creation learning curve (which took me around a year) making parts becomes reasonably easy and fast.

Here is how I would make this part. The changes are

Made a new part (so both can be loaded in to Fritzing at the same time) with parts editor.

rescale the parts to the standard (optional, it will work fine without doing this, but it is desirable to have all parts at one scale).

breadboard

ungroup everything

rescale

move the connectors to be on .1 in grid (doesn’t match real life exactly probably but keeps the wires straight). Select all and group name the group breadboard. Without the breadboard group exporting the part as a svg doesn’t work.

Schematic

ungroup everything

rescale

reduce the size of the item to be on .2 inch centers (.1 in centers is the usual spacing for most parts though)
add 4 .01in rectangles as the terminalId as they were indeed missing and place them on the end of the pins (parts editor can do this as well). Select all group and name the group schematic to set the correct layerId.

pcb ungroup everything

rescale

group the connectors in to copper1/copper0 group

group silkscreen in to group silkscreen (the original was silkscreen_2 and thus didn’t show up in the gerbers).

fzp file:

removed the terminalId from the breadboard definitions (as they aren’t in the svg) not really necessary but neater.

Ran the part file through the parts check script to remove font-size px values and check for no errors Then zip them all to create this fzpz file.

DC_DC_XL4016_fixed.fzpz (13.7 KB)

which you should be able to load in to the same sketch as the one I posted earlier to see what changed (not that much ).

I did although it probably needs updating with some of the things I have learned since:

I’m assuming Old_Grey’s videos are the tutorials you are currently using (which may be more useful than mine as well ), if not they are available here:

Peter

The willing to help part is the most important. At the moment I’m mostly ignorant of what I’m doing as well but I have the advantage of being retired and thus have time to do what interests me so I can allocate the time to learn and do things. That is a lot harder for folks still working I expect that is the problem the original developers have, Fritzing got this far as a funded research project, open source is a lot harder/ slower as the time isn’t funded.

Peter

Hiya all,

I am a beginner and have a large RC Crane project on my desk. I have the idea of how I want to achieve the mechanisation of the telescopic boom.
it involves 3 sets of stepper motors
1_ 2 x micro steppers ; to control the retraction of a locking pin, the motors work simultaneously in parallel
2_ 2 x micro steppers ; to control locking pins to pick up the boom section, the motors work simultaneously in parallel
3_ 1 x nema 8 ; to control the carrier that hitches to the boom section and moves it.

I need to select hardware to control these motors. I have a big easy driver but for some reason I can’t get it to work. the motors work when connected directly to my mega board but not to the driver. (sparkfun).

I would like it to be a simple set up. there is only one endstop which is for the nema 8.

I intend to control the motors based on distance to travel.

The RC component I intend to build too. idea is to use a touch screen interface to select boom sections and the location I want them to travel to.

any hardware suggestions for the drivers?

many thanks

Hiya all,

I am new to the world of arduino. I have a project on my desk which is getting a few people excited. I am learning reasonably well but so much more to go.

I have been 3d printing for quite a few years and run an ultimaker 2+ and Ultimaker 3.

I am looking forward to getting to grips with arduino tech as this will ads so much more to my projects.

hope to learn loads from here

kind regards

Rebekah Anderson

A quick look at the bigeasy says it should be easy to use. When you say “doesn’t work” that does that mean? Nothing at all happens with the motors? I’d check the state of the enable and sleep pins. If enable is high the fets are off and nothing will happen, if sleep is low same thing (fets are off, motor does nothing). If you post the Fritzing sketch of your hook up I expect one of us would point out any problems we see.

Edit: reading further down the data on the board there is also a current limiting pot, if that is set to less current than your motor needs to operate that would also cause no operation very likely.

edit2: I got this information from the Sparkfun hookup guide available here

https://learn.sparkfun.com/tutorials/big-easy-driver-hookup-guide

which may help you out. Generally Sparkfun has excellent tutorials (and often Fritzing parts) for their stuff.

Peter

Once you get through the parts creation learning curve (which took me around a year) making parts becomes reasonably easy and fast.

That’s a lot of time and experience for this, which is great as I saw the fixed model (pretty good indeed). I followed this tutorial and looks like I found another one made by SparkFun, which looks way better. Thanks for sharing the Tutorial Series, I would take a look at it as soon as I can.

Here is how I would make this part.

Wait, I didn’t understood the rescale part since I didn’t found a standard about parts sizing.
The connector was a good tip, I didn’t noticed it. The rest of thing probably are explained on the video, right?

Being a newbie is harder but glad to see your tips (and making effort for fixing this).

I have some questions:
When downloading custom parts, should I save them inside Documents/Fritzing/bin folder or just load them from my download folder and let the program handle it?

Also, there is a guide to add the proper description / labels for this new part? Because I used the default IC and slighty changed some stuff to make it fit (like as etiquette, category, etc).

For last, shall we upload it on github fritzing parts at core or different folder?

We seriously need a updated guide.

Cheers!

You said you currently updating / fixing the current broken parts, do you have any log regarding that? Since I can’t find the part list getting fixed on github (so weird) and hence, it would slow down the ones willing to help.

We should start organizing that issue first while other folks learn about the C++ code inside the program.

These two tutorials look to be for a previous Fritzing version. The new parts editor is both quite different (although the underlying parts are much the same) and not finished. The two tutorial sets I mentioned are for version 0.9.3b (the current release).

The part you started from was scaled at .75 the parts standard available here:

specifies a scale where 1px = 1 thou (which works out to a scale of 10.41667 in Inkscape. I wouldn’t worry to much about this, I automatically do it on any part I fix up so the scale is corrected if someone clones the part. A scale of .75 will work just fine it just isn’t preferable.

True, it all has a fair learning curve, but at the same time it is the only package I am aware of that has breadboard view which makes documenting a project build out of modules from Ebay possible. That alone is worth it to me to improve fritzing (and its fun ).

I tend to keep a copy of any parts I download or make in a directory separate from the Fritzing one (although they are usually also in there). If you hit a bug as with your original post Fritzing will hang and corrupt the user database. That means you need to delete it and potentially restore all the parts (or keep a backup of the directory) to avoid that. I have a fix for this particular problem but it isn’t fully tested yet.

Unfortunatly no not that I’m aware of. Most of the information I have has been passed down from other folks in this forum. You are correct we need better documentation for almost everything, but we have no one (so far) with the knowledge and time to write any.

That at least is documented (although I’ve so far only done this a time or two, mostly I have been posting here in the forums) other than how to replace a part with a new version and obsolete the old one which is listed as TBD (To Be Done) …

Peter

My usual method of finding broken parts to fix involves running my parts checking script against the core parts directory in Fritzing (it can be set to process all the parts in a directory and produce a list of the errors it finds, on core it is several megabytes of text ). Many parts show errors. I’ve got most of the raspberry PI parts fixed up (the Zero is the only one currently in core because unlike the others it had an incorrect PCB that was causing problems, the rest are just not quite standard). Some of them (the Sparkfun wireless card, Sparkfun pushbuttons) I have found while fixing parts that folks are having trouble with. One or more of the Arduino parts are causing errors during the database load in development and startup (but aren’t breaking Fritzing) they are probably next on my list. I also have a lot of parts I have made for people and posted in here but not done the work to get in to core. At the moment I’m trying to get (and document!) a development environment up and running to be able to install a new version of Fritzing with the bugs I’ve fixed on Windows so I can run them and test if they really work or are going to break something else. At the moment I think that is the most valuable thing I can do since that documentation may help others start development (which is the #1 thing we need). After that the parts checking script could use some more work as well.

Peter

The part you started from was scaled at .75 the parts standard available here:

Didn’t found the standard file on that wiki, where I should look into?

Also gonna share it on github if everything is ok Even though you slightly moved the “+” symbol on the screw blue connector. Could I try to fix it or let it go as it is?

I tend to keep a copy of any parts I download or make in a directory separate from the Fritzing one (although they are usually also in there). If you hit a bug as with your original post Fritzing will hang and corrupt the user database. That means you need to delete it and potentially restore all the parts (or keep a backup of the directory) to avoid that. I have a fix for this particular problem but it isn’t fully tested yet.

Makes sense, although if It is bugged, I would just need to delete it from my parts only, right? When I did the first export, the program zipped all the other user parts that I just imported into the same .fzbz, so If it is a common issue, should be fixed asap (Just saying).

Unfortunatly no not that I’m aware of. Most of the information I have has been passed down from other folks in this forum. You are correct we need better documentation for almost everything, but we have no one (so far) with the knowledge and time to write any.

We could start from part creation tutorial and move into standard guidelines and then more expert stuff, what you think?

When I click (in Firefox) on the posted link the document

2.1 Part file format

which describes the format of the xml that makes up a part comes up. It may be that you are expecting some other type of document, but this one describes how a part must look (this is what the parts check script checks for in a part).

Since I didn’t try and move it that is most likely an artifact of a translate being removed during ungrouping. You should be able to move it to where you want though. If you are using Inkscape for svg editing you may want to download the python check script from here:

as Inkscape adds px to all the font sizes which Fritzing objects to and the script will remove them for you. You can also edit the svg with a text editor (which is what I used to do before writing the script) and do a global replace of px with “”.

Unfortunatly it’s not that easy. When the part doesn’t load there is code missing to check the return code. The result of that is that Fritzing seg faults and dies, but it has already saved the fact it was loading the part and when you restart it will try and load it again. Because the part isn’t there it will complain about the absence of the part, but it also won’t let you delete it because it isn’t completely present. So the only fix is to delete the user directories that contain all you sketches. That is why this is the first bug I fixed because it annoys me .

It looks to me like you exported the entire mine parts bin rather than a single part (and it may have not exported properly at that). That isn’t necessarily a bug, since I think exporting an entire bin is allowed (I’ve not done it though). Normally to make a new part I’ll select the part I want to start from (often a generic IC or a header) then right click on the part, select edit part (new parts editor), change the metadata to match the new part then file->save as new part which creates the new part in the mine parts bin (and trips bug #2 because this new part won’t be deleted when you exit Fritzing even if you tell it to not save the parts). From there I click on the new part in the mine parts bin and right click export part to export the .fzpz file of the new part (not an .fzbz as you have which exports a bin)

We could do all those things if we could find someone interested and capable of doing them. The problem so far has been to find such a person or persons (as they need to have done parts creation enough to be familiar with what is needed), as noted I’d rather fix the bugs that annoy me at the moment and hopefully encourage more people to fix some of the bugs and then finish the parts editor.

Peter

hiya,
did put the meter on the enable pin and it did register voltage so I assume it’s high.
check: meter neg on gnd and pos on pin.

I used the example sketch which compiled and uploaded fine. I’ll have another look at it. am sure it should work but not sure why it isn’t.

still quite new to this so will try tonight.

Bex

which describes the format of the xml that makes up a part comes up. It may be that you are expecting some other type of document, but this one describes how a part must look (this is what the parts check script checks for in a part).

Yeah, I expected another kind of document like the Graphic standard, which I supposed is out of date, right?

Since I didn’t try and move it that is most likely an artifact of a translate being removed during ungrouping. You should be able to move it to where you want though.

I tried to reopen the fixed breadboard .svg file and guess what? The object layers were way too different of my original .AI file (Bigger, not same pattern). Looks like you converted all the layers using Inkscape, which makes harder (a lot!) importing .svg from Adobe Illustrator since svg export features can’t hanlde inkscape labels.

Comparison

minevsyour.PNG879x439 30.9 KB

as Inkscape adds px to all the font sizes which Fritzing objects to and the script will remove them for you. You can also edit the svg with a text editor (which is what I used to do before writing the script) and do a global replace of px with “”.

I will download and install Inkscape in order to test such feature with the other part currently on my board (the arduino mega shield v2.0).

Hi, please could i ask you

1. why my part is normal colour in part editor but in red colour in normal fritzing.
2. why wires jump from pins to center when i set them.
   fritzing 1.PNG1366x768 96.6 KB
   
   thank you !!

As you likely don’t need the enable or sleep pins I’d put a wire from the enable pin to ground (to make sure its low) or connect it to a Arduino output pin and set that low (but not both as that may damage the Arduino) and connect sleep to +5V with a 1K ohm resistor to make sure it is high. If it still doesn’t work you could check the voltages on the motor connections. If it isn’t stepping they should be stable and should be either ground (or close to it) or the motor supply voltage (possibly 12V?), if it is less than the supply voltage you are probably looking at current limiting and need to first check the wiring to make sure you don’t have a short and then increase the current limiting pot as the tutorial indicates until the driver is supplying enough current to run the motor.

Peter

Your part has an error in its connectors. If you post the .fzpz file of the part show above via the upload icon (7th from the left in the reply tool bar) I’ll have a look at whats wrong. You could also load the part in the parts editor and check all the connections are correctly set.

Peter

No the graphics standard hasn’t changed a lot as far as I know and is at least mostly fine. The parts file document is a mix of a specification document and notes on known issues and problems that can occur.

Ah, I’ve not used Illustrator, but I’m somewhat surprised there is such a difference. I’d guess the translates that I removed are the cause of the size change because scaling is one of the things that translates do. I saved the files from Inkscape as plain svg (which is supposed to remove most of the Inkscape specific labels) but I guess that isn’t enough. There is a forum item with a bunch of tips on using Inkscape that may be useful to you as you fight with Inkscape (although being used to Illustrator may help a lot, I was new to svg editors entirely when I started).

Peter

There it it is thank you for your help . I appreciate it

IODAG3E.fzpz (277.5 KB)