Ok i will redo it thanks

remove or move aside

~/Documents/Fritzing/parts
~/.config/Fritzing

neither of these get touched during an install as they contain the user’s sketches, but they sometimes become corrupted (usually by an interrupted parts update).

Peter

Hi all,
I have tried all suggestions including uninstalling Fritzing completely and anything related to it, including my circuits layouts & Parts from my Linux computer several times.

There must still be some hidden Fritzing files that I do not know about.

I then re-installed Fritzing but it still wont run.
Apart from Fritzing my computer is working perfectly.

It seems that I may have to try another PCB design program which I am reluctant to do as I believe that Fritzing is the best that I have used so far.

Syd

You do realize after purging the suggested files and redownloading on first run it may become unresponsive for many minutes while it updates the parts library. If a pop up comes up saying it is unresponsive just ignore it and DO NOT FORCE IT CLOSED. If you force it closed or kill it during this update you will break the install every time.

EDIT: also you never responded to my previous attempt to help where I asked you to start it from the command line to see if you get any errors and report back on the results from the terminal.

How are you installing Fritzing? If you are using one of the package managers an issue on github indicates at least one of them doesn’t have a dependency for the parts database (the fritzing-parts repo) which breaks the install. The recommended way to install is download the zip file from the Fritzing site, untar it and run Frizting from the install directory. It has an appropriate (if now outdated) parts database. Then as @sublimeartistry suggested above you need to wait while the parts database update takes place. If you want to use one of the app managers (which the linux folks suggest that you do) then make sure to load the fritzing parts package too in case it isn’t set as a dependency on fritzing.

Peter

One problem is the diode that should connect to pin 9 is floating (it ends before connecting anywhere on the IC). This also doesn’t indicate what you are using for a supply voltage, 5V won’t work the schematic suggests 12V but 9V may also be enough. At 5V the led voltage drops won’t light the leds. As @Old_Grey suggested uploading the fzz file would make life a lot easier (as well as indicating what the supply voltage is).

Peter

This is a small breakout, which is different from another already shared here. It has the the same chip, but different footprint and pinout. The silkscreen has the writing HMC5883L, but actually it is a QMC5883L (different I2C registers, etc.)

qmc5883l.jpg1208x1600 419 KB

This is a small breakout holding the u-blox NEO-6M GPS module. Serial interface plus a Pulse Per Second pin.

u-blox-neo-6m-gps.jpg1200x1600 294 KB

u-blox-NEO-6M-GPS_Breakout.fzpz (5.6 KB)

As Requested Here is the Fzz.file Also this is a 12v circuit and the schematic is on Talking Electronics . But i have uploaded that also for you to see … TC BB.fzz (26.0 KB)

You have two problems, there isn’t a connection between the grounds on the two breadboards and pin 9 isn’t connected to its associated diode. Either of those will cause problems if they are really there in the physical circuit. You also didn’t show a power source (I assume you have one) so I added a 9V battery as the power source. If you click on a pin in any view all the connections to that pin will light up yellow. Make sure all the connections that should light up do. You may also want to route the schematic and compare the result to the original (I did so but didn’t save it). The sketch below has the corrections.

TC BB_fixed.fzz (26.6 KB)

Peter

I am Unable to Open the TC BB_Fixed file it must be in a Zip file so it says .???

I just downloaded the fzz (to make sure nothing bad happened on the upload), started fritzing and did file->open and selected TC BB_fixed.fzz and it loads fine in 0.9.3b on Win7. Yes it is a zip file, most Fritzing files are.

Peter

It opens for me.

Another hint is the breadboard acts like a real BB, so you don’t need those orange wire links between diodes. If you look at a part that is put in the BB, eg LEDs, you will notice the whole row of holes turns to green dots, that is telling you they are all connected.
Also you can click on a green dot or bendpoint and everything connected will turn to yellow dots.

Welcome to Fritzing parts creation hell , over all not bad, but there are a few problems one of them (gerber generation) fatal.
I have fixed up both parts as new parts (varient2) so you can load both parts at once and made a test sketch in which I will point out the problems.

test_Sketch.fzz (37.6 KB)

The comments below refer to this sketch (which contains both parts). Breadboard is by and large good as is, I chose to redo the scaling to make it match that recommended in the parts format document, but that isn’t user visible. I also changed the scale of the part from being width * height in px to width * height in inches, again no visible change but is more usual. The three data pins on both parts are connected to three pin headers and the power to single pin headers (doesn’t matter here but does in schematic). If we now switch to schematic, we start to see appearance problems (which don’t affect the operation of the part). You will see the wires connecting to your part are ending in the middle of the pin, that is because you don’t have the connectorxterminal rectangles defined in the schematic svg (they are in the fzp file). On this part (the GY273) you will see the order of the pins differs between breadboard and schematic, again an appearance issue, not functional. Pcb view in fritzing looks fine, but when you generate gerbers (such as to cut a pcb) things are fatally wrong. This is the gerbv (a gerber viewer) output of the pcb view as a gerber:

test_Sketch_silkTop.png1168x672 20.3 KB

The part on the left in each pair is my corrected version, your two from the original parts are scaled incorrectly and don’t connect correctly (likely because of translates in the pcb svg although I didn’t check). While both new parts will be in the temp bin of the test sketch above, I will upload a copy of the fixed parts to both these parts so people coming along later can just grab the corrected part. If when you look at the svgs of the new part you can’t figure out what I did, feel free to ask, the more people making parts the better as far as I’m concerned

GY273-QMC5883L_fixed.fzpz (7.0 KB)

Peter

And a fixed up version of this one as well …

u-blox NEO-6M GPS Breakout_fixed.fzpz (5.6 KB)

Peter

Hi Peter, thank you for your review! I will make some investigation, because I don’t understand well how to evidence the problem in Fritzing. I use perhaps an old version (0.9.3b on a GNU/Linux Debian stable), and I can load the part nicely, and I can connect with other parts on the breadboard an on the PCB. But I must admit that the original SVGs come from a Python script that I wrote, which generates the SVG from some lines of Python code. I was tired by Inkscape which generates a SGV nightmare, full of warnings and glitches when imported in Fritzing!

As you can see from the screenshot below, in my Fritzing the size error is not visible

Screenshot_20181030_154921.png877x529 75.6 KB

Unfortunately so far .9.3b is the latest version. Development has stalled …

Interesting! I still use Inkscape, but I have a python script (available on github) that post processes the output from Inkscape to clean up some of the stuff Fritzing doesn’t like and I’m currently working on making it do even more. The base problem is Inkscape is trying to be an svg editor, and Fritzing has limitations (for instance not liking the px on the end of a font-size that the CSS standard calls for.) The best solution I think is to post process the svg output to make it compatible with Fritzing. I’d like to be able to pre compile translates so that we don’t have to process them at every render, but I think that is going to be complex. For now I’m looking to automatically remove tspan from the svgs, as that is currently causing problems in Qt (and there are some in parts in core parts) which is currently blocking building Fritzing from source to fix the libgit2 problem on Windows).

Yes, this is an unfortunate fritzing quirk that I have been bit by before ), so I automatically output gerbers when checking a part and make sure the two agree. The Qt render that renders the pcb view is more capable than the code (which I think is partly an external to the Qt package) that produces the gebers, so in some cases, as here, it looks fine in Fritzing but not when displayed as a gerber. This is undesirable because the PCB production houses create the pcb from the gerber, not from fritzing. The gerber output code has trouble with inheritance for instance and it won’t inherit the stroke width from a higher group as one example I have hit (my python script in lines inherited values in the pcb svg to avoid this issue). I think it also has problems with translates sometimes (or perhaps all the time ), I tend to like to remove translates from parts both for usability and performance reasons (I expect translates in parts have to slow Fritzing down although I don’t have proof yet.)

Peter

Hi Peter! It seems that my parts were misinterpreted by the gerbers creator because I used the SVG viewBox property with a misure unit (mm), where instead it is preferable to use an unitless number (if I understand well).
I fixed my Python script, so now it seems that the breadboard, PCB and gerber view is OK. Please, can you check the new part that I attach here?
The actual breakouts are sold with the holes, no soldered pin headers. So I think that I should mark them as female in the connector tab. Is that right? On the actual PCB I wish to have the copper circles for soldering a pin-header female connector…

Here it is another part designed by me, this time with the units of measure only in the width and height properties:

GYBMEP_BME-BMP280_Breakout.fzpz (6.0 KB)

That shouldn’t be correct (my corrected version uses “in” as the width and height units). Dimensionless will leave Fritzing to guess at the dpi setting and it sometimes gets it wrong. Safest is to have the width and height in “in” or as you did in “mm” as then the dpi is defined and Fritzing won’t guess. I can have a look at the original later, I expect there is a translate in there that the gerber is screwing up.

No, female in the connector def causes the connection to not auto connect in breadboard. It is meant to be used when a set of pins will all connect to the same row on the breaboard (Which would short) as with the 6 pins on the end of an Arduino pro mini. Most of the time pins should be male. That parameter is somewhat misleading as it only applies in breadboard view and isn’t about which type of connector it is (although it sounds like it should be ).

That is easy enough to do, it just needs to be a standard pad with (assuming the desired 1/100 scale in viewbox where 1px = 1 thou in) a stroke-width of 20 and a hole diameter of .078 in. This gives a .038 hole in the pad which fits a .1 header pin.

The check script is fairly unhappy with this The ones below marked Warning won’t usually break Fritzing but the ones marked Error usually will make the part malfunction.
This starts with the fzpz file unzipped in to a directory which gives these files:

(this happens to be under cygwin on Windows, but it works
fine on linux as long as you have python3 and lxml loaded).

Formatting from the cut and paste is running a bit funny here but it should be understandable. In a bit I’ll have a look and point out what it is complaining about and how to fix it. Unfortunately the error messages assume that you understand the format of the fzp file so they can be less than entirely clear. The first bit details what the script changed in the input svg to fix up Inkscape issues and is mostly for information about what changed (I usually ignore it unless I want to verify the changes). Then come the warnings which won’t usually cause the part to not work but are abnormal, and then the Errors which will cause the part to not work.
The terminalId missing in schematicView (likely an error) warning is indicating you don’t have a terminalId in the fzp file which means in schematic the connection will be to the middle of the pin which is usually incorrect (but will work, just look ugly, thus a warning).
$ ls

part.GYBMEP_BME_BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp
svg.breadboard.GYBMEP_BMEB_MP280_991354af0812478a25ae9516313ed379_17_breadboard.svg
svg.icon.GYBMEP_BME_BMP280_991354af0812478a25ae9516313ed379_17_icon.svg
svg.pcb.GYBMEP_BME_BMP280_991354af0812478a25ae9516313ed379_17_pcb.svg
svg.schematic.GYBMEP_BME_BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg

$ FritzingCheckPart.py part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp
File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 39

Modified 4: File
‘svg.breadboard.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_breadboard.svg.bak’
At line 5

ReferenceFile

‘GYBMEP_BME-BMP280_breadboard.svg’

doesn’t match input file

‘GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_breadboard.svg’

Corrected

Modified 4: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 14

ReferenceFile

‘GY_Schaltplan.svg’

doesn’t match input file

‘GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg’

Corrected

Modified 4: File
‘svg.pcb.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_pcb.svg.bak’
At line 5

ReferenceFile

‘GYBMEP_BME-BMP280_pcb.svg’

doesn’t match input file

‘GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_pcb.svg’

Corrected

Warning 6: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 2

ReferenceFile name

‘SparkFun_BME280_Breakout.fzp’

Doesn’t match fzp filename

‘GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp’

Warning 11: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 49

Type female is not male (it usually should be)

Warning 14: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 56

terminalId missing in schematicView (likely an error)

Warning 14: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 71

terminalId missing in schematicView (likely an error)

Warning 14: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 86

terminalId missing in schematicView (likely an error)

Warning 14: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 101

terminalId missing in schematicView (likely an error)

Warning 23: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 144

Key -inkscape-font-specification
value ‘DroidSans, Normal’ is invalid and has been deleted

Warning 20: File
‘svg.pcb.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_pcb.svg.bak’
At line 81

copper1 layer should be at the top, not under group copper0

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 112

Bus nodeMember connector8 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 113

Bus nodeMember connector11 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 116

Bus nodeMember connector9 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 117

Bus nodeMember connector13 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 120

Bus nodeMember connector7 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 121

Bus nodeMember connector14 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 124

Bus nodeMember connector6 does’t exist

Error 53: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’
At line 125

Bus nodeMember connector15 does’t exist

Error 64: File
‘part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp.bak’

Connector0 doesn’t exist when it must to stay in sequence

Error 69: File
‘svg.breadboard.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_breadboard.svg.bak’
At line 9

Found a drawing element before a layerId (or no layerId)

Error 77: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 26

terminalId connector4terminal can’t be a g as it won’t work.

Error 77: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 47

terminalId connector3terminal can’t be a g as it won’t work.

Error 77: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 89

terminalId connector5terminal can’t be a g as it won’t work.

Error 77: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 110

terminalId connector2terminal can’t be a g as it won’t work.

Error 77: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 131

terminalId connector1terminal can’t be a g as it won’t work.

Error 69: File
‘svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg.bak’
At line 142

Found a drawing element before a layerId (or no layerId)

Peter

Another fairly long post of the issues

fpz file:

part.GYBMEP_BME-BMP280_5736cf44ad4cd56ca6e39a45222a2cb2_26.fzp

Connectors should start at 0 not 1 and be in sequence (which they are)

    <schematicView>
      <p svgId="connector2pin" layer="schematic"/>

needs to be replaced with

    <schematicView>
      <p layer="schematic" svgId="connector1pin" terminalId="connector1terminal"/>

to define the terminalIds for all pins in schematic

type should be male (as they aren’t in conflict with other pins)

The bus section needs to be removed as it isn’t used: In this case as there are no pins in use that are in the bus definition it won’t hurt anything, but neither does it do anything except take up space and processor cycles.

< buses>
< bus id=“sdi/sda”>
…
< /bus>
< /buses>

replaced by

< buses />

(note the two blanks in this need to be removed, without them the forum takes this as formatting commands and doesn’t display them) as you don’t need any buses.

bb svg svg.breadboard.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_breadboard.svg

Scale is incorrect. The desired one (from the parts file format document at

https://github.com/fritzing/fritzing-app/wiki/2.1-Part-file-format

is 1000 dpi:

"For example, many Fritzing files use inches as units, and use 1000 dpi as the basis for the viewBox. So you might see something like

< svg width=‘0.46684in’ height=‘0.20306in’ viewBox=‘0 0 466.84 203.06’ >"

basiclly the view box should be 100 times the height and width (when the width is in inches (giving 1px = 1 thousandth of an inch).

I correct this in Inkscape by

edit select all

record the coord values in the tool bar

x 0.000 y -0.000 w 39.685 h 52.913

edit->preferences->behavior->transforms->Scale stroke width

ticked (I usually want it unticked)

Then in

File->document properties-> page

Scale x 0.26458

Custom size Units is mm

xml editor first element

height 14.00mm

width 10.50mm

viewBox 0 0 10.50 14.00

Change units to inches and height and width change:

height 0.55118108in

width 0.41338584in

now change the scale to 10.41667

edit->select all (the drawing has more or less disappeared)

x 0.000 y 51.569 w 1.008 h 1.344 px

change that back to

x 0.000 y -0.000 w 39.685 h 52.913

and the drawing will be rescaled to the appropiate scale

height 0.55118108in

width 0.41338584in

viewBox 0 0 413.38596 551.18125

(basically 100h and 100width)

If the lines are too thin, you probaly forgot to enable Scale stroke width

Now on to the svg itself:

line 13 layerId is incorrect

<g
id=“pcb”

should be

<g
id=“breadboard”

as the layerId defined in the fzp file. I prefer to ungroup everything at this point as that removes most of the transforms (not polygons though!) and the many useless groups the file exporter added. Now you can move elements around without
Inkscape using transforms. At the end of it all edit->select all and group and name the resulting group breadboard. I would probably show the terminals as pads with a hole in the center, but as is will work fine.

ids copper0 and copper1 are not needed here only the pcb svg, won’t hurt anything but take up space.

pcb svg svg.pcb.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_pcb.svg

Inkscape

edit-> select all

The starting coords aren’t 0 but x -0.945 -0.945

meaning some of the drawing is outside the view box and will be truncated on import. So first

File->document properties->Resize page to content

to adjust the view box.

then rescale as above Units in 0 0 41.575 54.803

ungroup everything then rescale it.

untick Scale stroke width

Now select connector1pin

set the stroke width to 20 (it was 19.xxxx)

The rescale has turned the circle in to an ellipse

so in xml editor set both rx and ry to 29 (this doesn’t move the center of the pad as changing the diameter in the tool bar does).

This sets the pad to 0.078 in w and h with a 20 stroke width. Drilled hole size is

dia (w or h) - 2 * stroke width = 78 - 40 = .038in,

the correct hole size for a .1 square pin instead of the 0.040551 hole the gerber

Untitled Sketch_drill.txt

file specifies for your original part. Note the text still has transforms even after the ungroup. Normally I delete the translate and then move the text back in to the correct position because as noted I think translates are likely a performance problem. I usually use a stroke-width of 10 for the silkscreen lines but the current 20 will certainly work (now the view box has been adjusted so it won’t truncate). Now you re group copper1/copper0 and silkscreen and you are done. On to schematic file

svg.schematic.GYBMEP_BME-BMP280_991354af0812478a25ae9516313ed379_17_schematic.svg

Needs rescaling. Needss a schematic layerId by edit select all, group and name the group id schematic (to match the layerId in the fzp file). Needs 4 rectangles (I prefer h .01 in w .01 in style fill:none;stroke-width:0) then the id changed to connector1terminal and moved to the end of the pin line
where the connection should terminate. Repeat for the other 3 pins (and preferably renumber them to start at 0!). I prefer to make schematic symbols as small as possible, with the pin line being 10thou in (which is more or less the size used on most other components in core). We really need to create some guide lines for part creation but so far time and interest have been lacking. As a style issue I would probably rotate GND and VCC 90 degrees so all the labels read the same way for neatness. I might try and make the rectangle smaller to allow more parts on a single sheet, but with the internal printing the box pretty much needs to be the size it is. Now having pretty much finished with this part, lets look at the original pcb that is the wrong size. So open

/cygdrive/d/fritzing_backup/imported_parts/u-blox-NEO-6M-GPS_Breakout

vi svg.pcb.NE0-6M-GPS_Breakout_a27f9494c4f434a4b065bc26ebc5fc06_11_pcb.svg

Ah, illumination strikes. I see that you defined the view box in mm rather than dimensionless, yes that is probably incorrect and may well be the cause of your problem. That will likely have gone away when I rescaled the original which is why it didn’t bite me. Another check to add to the FritzingCheckPart script (this is usually how I find new features ).

svg xmlns=“http://www.w3.org/2000/svg” viewBox=“0 0 24.00mm 36.00mm” height=“36.00mm” width=“24.00mm”

because while there are transforms in silkscreen (which may or may not cause problems, I think it was not correctly showing the text in the original) it shouldn’t have affected the copper side (which has no transforms).

Peter