Can I export my project?

beginners
1

Hello all.

I’m working on a project that I’m modelling in Fritzing both for the breadboard and PCB.

I’ve added some non-catalogue parts mostly thanks to vanepp (thanks again!).

What I want is to be able to send over what I have to them so that they can work on the project too, but sending the .fzz doesn’t do the trick, even when I send over the parts seperately.

Also I’d like a neat way of doing this so that I’m able to share it on GitHub publicly as part of the project I’m doing (all free and as a hobby). Where do we stand on me putting parts that aren’t in the catalogue on GitHub, is that a breach of copyright/IP?

Thanks, James.

2

Why not? The .fzz file will have all non core parts included in the .fzz file in the temp parts bin (exactly so it can be shared with someone that may not have the same custom parts.) They should be able to load it in to Fritzing and see exactly what you see. There is currently a probable bug that parts in the mine parts bin will be selected over parts in temp (which can cause problems if the part in temp is newer than the one in the mine parts bin) but that is the only limitation I know of.

AFAIK parts are under the creative commons license and thus can be shared on github without problem (certainly all of mine are.)

Peter

3

I found sending the whole ‘Fritzing’ folder over with the parts and .fzz worked, but the parts were missing when I just sent over the fzz to a friend.

4

Can you post the .fzz? The temp parts bin should have any parts not in core. It is possible that your friend needed to manually do a parts update to get the latest core parts (automatic update died on Win7 pre 0.9.4.) but that would be the only reason I know that a .fzz file shouldn’t have all the parts.

Peter

5

Ok, I sent off my .fzz to a windows user friend and it worked OK for them, but not for my linux user friend - it seems there’s a hard reference to the core parts library (as it’s saying it can’t find the files on the C Drive, which of course Linux doesn’t have).

Can this be raised as as bug with devs somehow please?

This is the error he gets when he opens the attached .fzz Door Pi.fzz (71.7 KB)

Unable to find the following 2 parts:

‘Camdenboss_CTB0158-2_5_08mm_pitch_90deg_terminals’
at
‘C:/Program Files/Fritzing/fritzing-parts/core/Camdenboss_CTB0158-2_5_08mm_pitch_90deg_terminals.fzp’
‘Camdenboss_CTB0158-8_5_08mm_pitch_90deg_terminals’
at
‘C:/Program Files/Fritzing/fritzing-parts/core/Camdenboss_CTB0158-8_5_08mm_pitch_90deg_terminals.fzp’

FYI The linux user is using v0.9.3

James.

6

Fritzing stores internally in the sketch file (for efficiency) the absolute path to the core parts being used. Which is why the “C:/Program Files/Fritzing/fritzing-parts/core/…” path in the error messages. However, normally, Fritzing also knows that the parts are from the core library, and updates that information when the sketch is opened.

I confirmed the symptoms on my linux system. I get that same error IF I just click on the link in the post, and tell the OS to open the document with Fritzing. However, if I choose to download (Save) the file, then run Fritzing and open the saved file, it works.

Strange. I wonder what is different with the way Fritzing opens documents directly from the web, as handed to it by Firefox? I even found the temporary downloaded file in /tmp/mozilla_… in the recent documents in Fritzing. Opening that worked too, so it was not an issue with the actual download.

I am running Fritzing 0.9.4.

I’d say it is a bug.

7

It ALSO appears to be a problem with those particular core parts. The way that Fritzing opens the core library when started from the command line avoids the issue, but when Fritzing is started from the GUI, it is unable to find those parts. Or any of the CamdenBoss parts. @vanepp see my added information for the bug report, and try running the …\fritzing-parts/core/Camdenboss_CTB0158*.fzp files through your latest parts checker, so see what it complains about. I ran the first of those through the older version I have. Plenty of complaints, but I do not know how IMPORTANT they are. Going to need a different environment to try to trace this one, since it only triggers when Fritzing is started from the GUI. Which is not what Qt Creator does.

8

The major one on Camdenboss_CTB0158-9_5_08mm_pitch_90deg_terminals (the first I tried) is copper0 is mis spelled so pcb won’t work correctly, but that shouldn’t affect rendering.

Capture
Capture874×677 90.2 KB

the rest don’t have that particular error and nothing else that appears should be deadly. I just tried opening the file directly in fritzing with 0.9.4 in firefox (never thought of doing that before) and on Windows7 (my linux dev system doesn’t currently have a production Fritzing installed) it appears to work. One possible problem (which doesn’t appear to be happening here) is that Linux and MacOS are case sensitive to file names and Windows is not. So a different case between the fzp file and the svg file will cause a failure on Linux or macOS but not on Windows, but CheckPart checks for that and it isn’t flagging it. This is an odd one! I’ll continue poking at this.

Peter

9

You should be able to point at the debug Fritzing binary in the Qt build directory and start that from the gui I think. Then how to attach gdb to it to get a break point becomes the problem though.

Peter

10

Directly starting the 0.9.5 Fritzing in the debug build folder from file explorer worked fine. However opening the Door Pi.fzz sketch from that also worked. The same sequence failed with 0.9.4. Both running on Fedora 31 Workstation, one a real system, the other a VM.

Doing environment differences research …

Found the problem. In my normal environment, my command line run of Fritzing is scripted, pointing to an alternate source for the parts library (so I could switch around for testing core part creation). Running from the GUI does not get that parts library redirect, and the parts pulled in by/with the flatpak version of Fritzing is OLD, (Jun 9 2016) and not being updated automatically locally. The Camdenboss parts do not exist in that library, so the error message is perfectly correct.

@CuriousJames check with your linux user friend about the version and age of the parts library they are using. If they are using Fritzing 0.9.3, it could be the same version I had. Or if they are running Fritzing via flatpak, then they have the same lack of library updates problem.

The library (git repo) was sitting on a Detached HEAD branch for that date. Until I did a manual fetch, I could not even see any other branches. I could not convince git to get the repository into what seemed like a normal state. I ended up deleting that and manually cloning from github. After that, running from the GUI worked. The expected parts ARE in this copy of the parts library.

Just FYI, the path to that parts library folder (for flatpak and Fedora 31) is ~/.local/share/flatpak/app/org.fritzing.Fritzing/current/active/files/share/fritzing/parts
Or some variations. current and active are symbolic links that hide some version flatpak app updates.

The not updating issue is known. It is because of where Fritzing (the flatpak wrapper) stores the library. It is in the path for code, which is not allowed to be updated from inside the application. Which was one of the reasons for my script to use an alternate path, that I cloned from github manually. I seldom use the GUI to access Fritzing (except to open an occasion sketch from the forum), so had forgotten about the limitations. I should take some time, dig deeper, to see if I can automatically pass that library override when starting from the GUI. I think that is possible in the desktop file that the application uses. Have not has a real reason to go play there before.

A quick check shows the desktop file at ~.local/share/flatpak/app/org.fritzing.Fritzing/current/active/export/bin/org.fritzing.Fritzing. Adding the parameter there seems to have fixed the problem. At least until a flatpak update replaces it on me.

Long winded description to say the error messages are correct, because the local copy of the parts library was ancient.

11

They’re using 0.9.4 on their linux system (XUbuntu 19.10) they don’t know which parts library they’re using, sorry!

12

Depending how that was installed, there is a good chance that Fritzing does not have enough privileges to update the parts library, so they would have the same base parts library version that I did for the flatpak install. There are work arounds. The parts library can be installed separately (manually), then Fritzing can be told to use that instead of the default. That is the way my run from terminal script works. The same can be done for running from the GUI, by added parameters to the desktop file. I am not an linux expert, and the details can vary depending on the specific flavour of linux, and how Fritzing was installed.