Yes the latest version that I replaced has the schematic svg modified (not completely, so it looks a little odd in Inkscape but works fine in Fritzing) to match what the code is substituting, so the part now appears correct in schematic in Fritzing. That only affected schematic, not the footprint. So long as you print out the footprint at 1:1 scale and check it against a real part to make sure it is correct, and verify the gerber output with a gerber viewer, your board should be fine. Feel free to upload your final .fzz file and I can check it over (not having the part I can’t verify the footprint though.)
To be honest, when I know what I’m doing (simple square boards) fritzing works great.
I tried KiCad nad hate the thing, and lets not ever mention eagle
BTW the kitsune badge is a project for my electronics book I’m writing and a giveaway for my novel I’m writing.
I came to Fritzing by way of Geda (developer infighting , blocking progress), then Kicad (Eagle wasn’t in the running because it was commercial not open source, which turns out to be a good move, because it was sold to Autocad and now appears to be dying.) Fritzing was mentioned on the Kicad site (or maybe by CERN who was supporting both?) and I never looked back . Fritzing does what I want. That said, when your board needs get too complex for Fritzing you need to look at one of the more full featured packages, although with development restarting perhaps Fritzing will make progress.
I have probably just figured out how to correctly fix the “editable pin labels”>true issue. The problem is likely they need to know where the pin label is to substitute the text. That is currently done by substituting a known svg (which has problems when the input svg doesn’t match a dip outline such as headers.) A solution to that is to require the pin labels in the schematic svg to have a specific label such as connector0pinlabel, if you want to set editable pin labels to true. If such a label does not exist, revert to the current code and substitute the svg (which may be wrong, but is now anyway.) If the label exists, then the code modifies the text in that existing label, without otherwise modifying the schematic svg (which is my desired outcome!) If one of the labels in the part doesn’t exist, output an error message that the part is misconfigured and the label can’t be changed. This needs a code change, but does not break backwards compatibility. I suspect with enough thought we can usually find a way to add functionality without breaking backwards compatibility.
No branches. I remember running in to this before but I don;'t remember how to get the branch tags. I’ll try switching to that branch on github and cloning that first.
I came to Fritzing after struggling with Eagle (YUK!) and (at that time) KiCad’s early version.
I agree, Fritzing does most everything. However, KiCad has come a long, long way and now, for me, it’s as easy as Fritzing.
The best part though, is it has easy-to-use embedded Footprint tools and the Edge_Cuts layer (with it’s drawing tools) can handle every PCB shape, including cutouts I made.
Footprints can include externally-drawn .STEP models.
Don’t want to dissuade Fritzing users. Fritzing works well enough.
A web search for git checkout branch from origin got the answer as the first result. But that assumed knowing that origin was what remote was called by default.
I suspect your previous problems with getting updates from the master have similar simple solutions. Things get easier when you know the right words to use when asking the question. I suspect the word master is part of the problem. As you saw, master is the name of a branch. But the context I saw in your older post indicated you actually meant getting updates from the official fritzing-parts library repository. Searching for upstream in the question probably gets closer. I have some notes. Going away now to dig that out
The bottom pads will be soldered to a base pcb and the selector will be soldered 45 degree to the other switches.
S4 has @vanepp 4020 package design he made (thank you mate)
this pcb is only part of a controller for video editing.
Just need to work out how to edit the cherry key part to remove the bottom 6 pins. @opera_night why does the ziff socket look strange?
got the correct branch down. That said I don’t understand why cloning the repo doesn’t get the branches, that would seem to me to be an obvious feature. As to the three way sync, it has to be very common (clone a repository on github, clone that writable repo locally, then make a pull request and resync them all. All the examples I can find are for a remote to/from a single local, not to a “my remote” on github and then the master. Kjell suggested a bunch of fetch all --remote --upstream (don’t remember the exact syntax) commands but even with them my writable repository on github ends up several commits ahead and several commits behind fritzing-parts development. For instance now my fritzing-parts repo says
This branch is 4 commits ahead, 9 commits behind fritzing:develop.
when the two (I think) should be in sync. The only way I have found to get it in sync is to destroy my clone and re clone it. That is obviously wrong, but I can’t figure out how to do it, nor find any tutorial that explains how to do that exact thing (as I said all the ones I have found are local to a single remote, none with a write permissioned clone in the middle.) This is what keeps me from pushing parts to core most of the time, it is just too much hassle. With your repo in hand I’m just making a test sketch of the original part so I can substitute in your repo and see what happens.
In all the svgs the Units should be in inches (in) not px. Px causes Fritzing to guess at the original resolution which it may or may not have gotten right this time. The result is that the scale may be incorrect making the pads the wrong size:
Actually, I edit in AI, with mm unit.
And, yes, while editing core svg, AI detects the values as “mm”, and I have to converted them to mil-inch manually…!!
Check the gerber output with a gerber viewer. There are a number of bugs (Kjell fixed 5 in the development version which isn’t yet released, a few months ago) in gerber output relating to paths. If you upload the .fzz file (7th icon from the left in the reply menu) I’ll have a look. If that is the problem you need to experiment with the paths to get it to output correctly.
From the wording in your post, I’ll start by clarifying what actually happens in those steps. Forking fritzing/fritzing-parts takes a snapshot copy of the repository and puts in your own github accounts (vanepp/fritzing-parts). Cloning that snapshot to your local machine makes another copy, but maintains a link back to github (the remote) about where the copy came from, and where to send (push) information back to. That is the origin remote that git remote (or git remote -v) will show. The cloned repository on your local machine does not start out knowing anything about the fritzing/fritzing-parts repository. It has no path to get there. There is no (automatic) process to get any changes from fritzing/fritzing-parts into either vanepp/fritzing-parts or your local working repository. To get updates from fritzing/fritzing-parts, you first need to add that as another remote to your local clone.
In that, upstream is whatever name you want to use to reference that repository. upstream is just a convention for the parent of the origin repository. The fetch commands gather some information about the remote, and add it to the local repository. Now, git remote «-v» will show both remotes, and git branch -r will show branches that existing in each remote repository.
Getting synchronized (caught up) with the changes data in the master branch of fritzing/fritzing-parts takes a few steps. If you have changes in the master branch of your local copy, additional work may be needed to merge the 2 of them. The basic steps are:
The fetch just makes sure the local information is current about the remote repository. Checkout makes the master branch active in the local repository. If you only been using the master branch, it will already be active. merge says to actually get the changes in the upstream remote, master branch, and add them to your local copy. push then sends those changes to the origin remote. Or where ever the local master branch is configured to push them.
If you have changes in your local master branch that are not in upstream, you could get conflicts that require manual intervention to get the merge to complete. That is a whole other topic. The way to avoid the problem before it can even start, is to NOT make any changes in the local master branch. Instead, do any work in a separate project specific working (and probably temporary) branch. Like the 8x8_led_matrix branch I pointed you to for the parts. To do that
That creates a new «projectName» branch locally based on what is currently in the (local) master branch, and tells git that it is to be synchronized with the same branch name on the origin remote. When git push is used. Linking the local branch with the remote could be done later, but if the intent is to push it up to github, in preparation for a sending a pull request to fritzing/fritzing-parts, might as well do it when the branch is created.
There are multiple branches in fritzing/fritzing-parts, and probably in vanepp/fritzing-parts. Each of which can be brough up to date (somewhat) similarly. If you already have the branch in your local clone,
will synchronize «branchName» in upstream, origin, and the local repository. If «branchName» exists in upstream and origin, but not locally, replace the checkout with
git checkout --track origin/«branchName»
If «branchName» exists in upstream, but not in origin or locally, change checkout to
git checkout --track upstream/«branchName»
That should provide the basic commands needed for the common situations.
Cloning a repository (without extra arguments) gets the data about the branches, or at least a link that can get them, but only pulls the data for the master branch. Or actually the main branch as configured on the remote repository. What I provided first time, was how to tell git that we are interested in another branch once the initial clone is done.
Yes. See notes above. Handled one branch at a time, not for the whole repository.
That happens all the time. The “4 commits ahead” are the changes you did locally, committed, and pushed back to github (origin), but have not (yet) been merged (you did a pull request right?) with upstream. The “9 commits behind fritzing:develop” are because of someone else changes that have been merged into the github repository, after you did the fork (or after the last time it was synchronized).
From that, I assume you are working with the “develop” branch. If you use the separate working branch I suggest above, that sort of message can be totally ignored. The branch can just be deleted (from local and vanepp/fritzing-parts) once the pull request has been completed. Instead, just resync the develop branch, that does not have any of your local commits in it, and create another project branch from that for the next batch.
If there are no conflicting changes between your “4 commits ahead” and the other “9 commits behind”, you can get rid of the 9 commits behind by doing a merge. Assuming upstream is stetup
I expect that to break all over the place, especially in PCB view. The original idea was to exercise my new parts a bit, and check for anything I missed, and the part checker did not complain about. I did not put the cleaned svg files back in the repository. The hand crafted svg files I used are fairly clean, and structured with a few comments. From other posts, you/Fritzing have had issues with transforms. I use them (sparingly) so that some blocks of svg can be directly cloned when the same thing appears in multiple locations, or to provide an offset so that the coordinates are simple multiples of 0.1 inch.
you are working with the “develop” branch. If you use the separate working branch I suggest above, that sort of message can be totally ignored. The branch can just be deleted (from local and vanepp/fritzing-parts) once the pull request has been completed. Instead, just resync the develop branch, that does not have any of your local commits in it, and create another project branch from that for the next batch.