search

fritzing / fritzing-parts

Electronic components for use in the Fritzing app (aka the parts library)
http://fritzing.org/parts
Other
511 stars 359 forks source link

Calliope Mini Rev 1.3 #176

Closed HaraldRau closed 5 years ago

HaraldRau commented 5 years ago

Fritzing crashed by routing the part "Calliope Mini Rev 1.3" from nightlyParts. I use LINUX with a portable installation! The application window closes with the error message: Segmentation fault (core dumped)

The graphics for the breadboard has a serious error. At the short PIN header is one PIN too much. Not 6 PIN but 5 PIN are correct. calliope

The names of the PINs do not correspond to the official documentation.

I try the following:

  1. I extend my part to the missing connections.
  2. I use the version "Calliope Mini Rev 1.3" from the NightlyParts.
  3. I am putting this version up for discussion here!

I hope i can help to fix the Part.

vanepp commented 5 years ago

Sorry for the late response, I checked a couple of hours before you posted then forgot to do so again. The sketch autorroutes fine or at least as fine as autoroute ever works, it uses silly routes and has added two vias that aren't needed, but it works. Do you have a recent sketch where autoroute doesn't work? If so could you upload it for me? I'd be interested in seeing what it is unhappy with. I haven't seen any sketch where autoroute didn't work for me. The script finds no problems wth your latest part (it corrected reference Ids, but that's normal). Could you measure across widest points on your board in x and y please? As I said all three (eagle, el-j's eagle to fritzing part and ours) disagree as to size. I need to figure out which of them if any match a real board. I may be misreading the sizes in Eagle as I haven't used it much, but we need to make our pcb match the real board. As to the banana plugs, I expect you are going to want to leave at least the holes in place to be able to use as mounting screws to support your shield even if you don't want to connect to them (and I would make it at least possible for the shield to connect to them by installing metal spacers, but that is your choice).

Peter

HaraldRau commented 5 years ago

That's how I measured: From outside to outside, that's better for the caliper. 20190304_073413

47,5 mm Bananaplug r=10 mm

To leave the holes of the banana plug to use as mounting would be great.

The broken auto-route was with the version from 28.02.19. Here the component and the sketch.

Calliope Mini V 1.3.fzpz.zip test_Sketch.fzz.zip

The Part from yesterday (Calliope Mini experimentell.fzpz.zip) was O.K.!

vanepp commented 5 years ago

Easily fixed. Your board area is too small and it is trying to route outside the board which causes the crash. Your original:

broken_pcb

and the settings in Inspector (bottom right window)

bad-setting

A corrected copy that autoroutes correctly

good-pcb

and the Inspector settings needed to change it:

good-setting

edit: to get the pcb data in Inspector you need to click on the grey area to select it!

You need to change shape width and height to be large enough to contain the entire board ( I used 100mm by 100mm) and then drag the grey area until the entire board is contained within the grey area. I expect autorouter is looking at the far side banana connectors that are outside the board area and that is why it crashes. Thanks for the board measurements, I'll use them to try and get a properly scaled pcb together with the header pins correctly aligned.

Peter

HaraldRau commented 5 years ago

Ah, I understand the problem. Of course, when I did not have any banana plugs, Fritzing could route.

If I want to have a small shield with small dimensions, there must not be any banana plugs on the board.

It is a good idea to insert the holes in the "silkscreen" and not in "copper"

HaraldRau commented 5 years ago

OK. the problem is solved, what is left to do now?

I still have a problem, I made a mistake in the definition of the bus.

bildschirmfoto_2019-03-04_16-57-50

Which version of the Fritzing Part should I fix the bus for?

HaraldRau commented 5 years ago

I repaired the bus for the scheme.

I have an editor open

vanepp commented 5 years ago

"OK. the problem is solved, what is left to do now?"

I need to figure out how to scale pcb correctly. I just swapped disks to get to my Eagle installation and measured the .1 header connector (which I know the dimensions of) in the eagle drawing. That verified that the numbers I'm reading appear to be correct (the size I read from Eagle for the header matches to the number of pins * 2.54mm). That means I'd reading Eagle correctly. With that done I measured the outside of the same 2 ears that you did, and Eagle gets 47.69mm edge to edge which looks to match the 47.5mm that you measured on the real board (the small difference is likely how I'm measuring). With that in hand now I need to correct the pcb svg to match the real board and get the connectors positioned correctly. For changing the fzp file I'd suggest using the most full featured board (one of the ones with the banana plugs present) as that is what should go in to the Fritzing Calliope part. You should make a new part for the smaller shield I expect, we want the Fritzing part to have everything that is on the board available. I'll try and get the pcb svg straightened out.

Peter

HaraldRau commented 5 years ago

Here is the version without connected banana plugs, but with the PADs. The bus is corrected and only the PIN header is connected to the PCB. This makes it possible to realize small boards with a width of 50 mm! The board version is 1.3, so with 6 PIN on the top header. Calliope_Mini_V_1_3_only_PCB_PIN_Header.fzpz.zip

vanepp commented 5 years ago

OK, if you are good with the 6 pin header (when your boards only have five), I'd like to add the mic connector which looks to be also an addition in version 1.3 and add back in the connections for the banana pads so the final part matches the 1.3 configuration. I have managed to figure out the svg problem. The eagletofritzing program wrote the svg at 72dpi, so neither Inkscape version will load it correctly (being 90 and 96 dpi). However there is an article on the Inkscape site on how to correct for this and I have jus succeeded getting the original nightly parts pcb svg properly scaled with dimensions in inches (to avoid the dpi problem). It currently has small pad sizes and lacks the pads for the banana plugs and has pin numbers that don't match ours nor the audio connector. I will now use the Eagle file to correctly place the banana plugs and hopefully the audio connector and change the pin numbers and we should be good to go I think (we will need a change for the new audio connector, but that is minor.)

edit: Looks like this will take a while. I got the P0 pad correctly aligned from the measurements from Eagle, but when I did what I thought was the same procedure on P1, its position is wrong (this was last night) so now, this morning I have to figure out what went wrong and correct it, but it looks like it will work if somewhat slowly.

Peter

vanepp commented 5 years ago

OK, I think we are now there. I think this part works correctly and has the correct scale. I have made a number of changes to your part above: Breadboard, rescaled to match the new pcb which in turn matches the physical board. Changed the position of the connectors to match pcb. This appears to have started from an older version that had paths for the text, so changed the paths to text again (saving 150+k in size in the breadboard svg) and removed transforms from the connectors. Schematic: again an old copy, so swapped 3v3 and Vin connections so Vin is beside the motor pins. Added a connection for Bat+ as it is not directly 3.3V, but goes through a MOSFET probably to a regulator to isolate it from the USB connection, so it needs its own pin (I left Bat- grouped in ground). Again removed translates on the pins. Pcb: rescaled so its size is correct (at least I hope so!), added the pads for the banana connectors because they are there on the board and available if someone wants to use them. Omitting them leaves the chance for unexpected short circuits if someone routes traces on a shield under the pads without realizing the pads are there. I think all that remains now is for you to print out a copy of the pcb layer, preferably on an overhead projector transparency at 1 to 1 scale and try the result on a real board to make sure the scale is correct and the connector align with a real board. If that checks then you should be able to submit this part to nightly-build. Note there appears to be a bug in Fritzing where if you connect to all connectors, in order to complete routing in pcb you need to route connections to c17/rx, scl/c19 and sda/c18 from the connectors that don't appear in pcb to the connections that do appear. I assume this is to do with the signals being bused but can't find a way around it. Here is the part based on your Calliope_Mini_V_1_3_only_PCB_PIN_Header.fzpz.zip part above with the listed changes:

Calliope_Mini_V_1_3_only_PCB_PIN_Header-fixed.fzpz.zip

and the test sketch I used to test it:

test-Sketch.fzz.zip

Peter

HaraldRau commented 5 years ago

The result is excellent. The Sketch work perfect an the part look very nice.

The original hides exactly the printout from the PCB. I do not have Calliope with 6-pin, but it looks exactly like the original. I will buy one myself next. 20190306_174004 20190306_174017

Should I copy the files now in the branch nghtly-Part and do git push? Do I have to overwrite the version of @el-j or do I copy the part additionally?

Can I downgrade the Version to Calliope Mini V 0.1? [5-PIN-Header in Breadboard and Scheme] Must i open a new issue for this work?

vanepp commented 5 years ago

You need to clone a copy of the parts repo (or nightly-Part but I think in this case they will be the same) then in your fork of nightly parts, copy the files in to place. Then git push your version to nightly parts and git will take care of overwriting @el-j 's version of the part. To make a V 0.1 version of the part you need to take the current part and edit it in parts editor to change the metadata to say this is the V0.1 version (with one less pin) and create a new moduleId and file names so it doesn't conflict with the file names and moduleId of the 1.3 part (you can do this with a text editor but parts editor is probably easier). When that is done, save as a new part (file->save as new part) and export the new part by right clicking on it in the mine parts bin and clicking export part. Now you have an fzpz file with a new moduleId and can change the files to remove the 6th pin. Once that is done you can edit the svgs in the new part to remove the 6th pin and save it. Then you can just do the same push of your new part to the repo and all should be well. One complication is due to a bug in Fritzing, when you try to load your new part back in to Fritzing after the change, you will get an error that the part already exists in Fritzing. To clear that you either (if you have no sketches that aren't backed up) clear the user directories which on linux are in

~/Documents/Fritzing/

or if you have sketches you want to keep, take a backup of that directory (a good idea anyway) and then find and delete the files (left by the parts editor, which is a bug) in

~/Documents/Fritzing/parts/user for the fzp file (I think this is all you need to delete if not do the svgs too)

the svgs are in

~/Documents/Fritzing/parts/svg/core/breadboard/ (and icon, pcb and schematic for those svgs).

Peter

HaraldRau commented 5 years ago

Well, I want to document every step to make any mistakes!

The filename are terribly! Can i rename the Filenames and edit the xlm-file *.fzp to the new filename of the other for files?

mv part.Calliope_mini_18e1f312913c8c9c43b618584bd40d02_9.fzp Calliope_mini_V_1_3.fzp

HaraldRau commented 5 years ago

git status

Auf Branch nightlyParts Ihr Branch ist auf demselben Stand wie 'origin/nightlyParts'.

Unversionierte Dateien: (benutzen Sie "git add ...", um die Änderungen zum Commit vorzumerken)

Calliope_mini_5.fzp ../svg/core/breadboard/Calliope_mini_5.svg ../svg/core/icon/Calliope_mini_5.svg ../svg/core/pcb/Calliope_mini_5.svg ../svg/core/schematic/Calliope_mini_5.svg

nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien (benutzen Sie "git add" zum Versionieren)

I will remove the Calliope_mini_5 this is a old Test-Version!

git status

Auf Branch nightlyParts Ihr Branch ist auf demselben Stand wie 'origin/nightlyParts'.

nichts zu committen, Arbeitsverzeichnis unverändert

It's O.K. and clear!

HaraldRau commented 5 years ago

I will rename the files tomorrow

mv part.Calliope_mini_18e1f312913c8c9c43b618584bd40d02_9.fzp Calliope_mini_V_1_3.fzp mv svg.breadboard.Calliope_mini_b12db4639f98ca3b508ddb853213c9a7_9_breadboard.svg Calliope_mini_V_1_3.svg for the other files in his folder /breadboard /icon /pcb /schematic

The i edit the four <layers image="...."> to the new filename and edit the referenceFile=Calliope_mini_V_1_3.svg

...but I'll do it tomorrow. Today a "Hefeweizen" waits for me in the fridge!

HaraldRau commented 5 years ago

I now move the renamed files to the respective folder! Calliope_mini_V_1_3_breadboard.svg Calliope_mini_V_1_3.fzp Calliope_mini_V_1_3_icon.svg Calliope_mini_V_1_3_pcb.svg Calliope_mini_V_1_3_schematic.svg

I test in Fritzing the Part -> Metadata are wrong! Edit Metadata an rebuild database in Fritzing! Part look O.K!

Testsketch work without errors!

I will try do git add! git add core/Calliope_mini_V_1_3.fzp .... git status neue Datei: core/Calliope_mini_V_1_3.fzp neue Datei: svg/core/breadboard/Calliope_mini_V_1_3_breadboard.svg neue Datei: svg/core/icon/Calliope_mini_V_1_3_icon.svg neue Datei: svg/core/pcb/Calliope_mini_V_1_3_pcb.svg neue Datei: svg/core/schematic/Calliope_mini_V_1_3_schematic.svg

git commit -m "Aenderungen an Calliope Rev 1.3 von Peter van Epp"

Error:

*** Bitte geben Sie an, wer Sie sind.

Führen Sie

git config --global user.email "you@example.com" git config --global user.name "Your Name"

aus, um das als Ihre standardmäßige Identität zu setzen. Lassen Sie die Option "--global" weg, um die Identität nur für dieses Repository zu setzen.

fatal: Konnte die E-Mail-Adresse nicht automatisch erkennen ('hara@Inspiron-N5110.(none)' erhalten)

I wait for your comment before i will do git push

HaraldRau commented 5 years ago

git config user.email "harald.rau@fietsmeter.de" git commit -m "Aenderungen an Calliope Rev 1.3 von Peter van Epp"

[nightlyParts 28ebbfca] Aenderungen an Calliope Rev 1.3 von Peter van Epp 5 files changed, 11038 insertions(+) create mode 100644 core/Calliope_mini_V_1_3.fzp create mode 100644 svg/core/breadboard/Calliope_mini_V_1_3_breadboard.svg create mode 100644 svg/core/icon/Calliope_mini_V_1_3_icon.svg create mode 100644 svg/core/pcb/Calliope_mini_V_1_3_pcb.svg create mode 100644 svg/core/schematic/Calliope_mini_V_1_3_schematic.svg git push

Username for 'https://github.com': harald.rau@fietsmeter.de Password for 'https://harald.rau@fietsmeter.de@github.com': remote: Permission to fritzing/fritzing-parts.git denied to HaraldRau. fatal: unable to access 'https://github.com/fritzing/fritzing-parts.git/': The requested URL returned error: 403

I dont no, what is wrong?

vanepp commented 5 years ago

"The filename are terribly! Can i rename the Filenames and edit the xlm-file *.fzp to the new filename of the other for files?"

Sorry for the late response, I see you discovered that you can rename the files. The only thing to watch for is the names and moduleId can't be the same as something already in core.

"

Username for 'https://github.com': harald.rau@fietsmeter.de
Password for 'https://harald.rau@fietsmeter.de@github.com':
remote: Permission to fritzing/fritzing-parts.git denied to HaraldRau.
fatal: unable to access 'https://github.com/fritzing/fritzing-parts.git/': The requested URL returned error: 403

I dont no, what is wrong?"

I'm far from an expert in github, but it looks to me like you are tryiing to do the push to the fritzing-parts repository. You can't do that directly as you don't have permission on the repository. What you need to do is fork (the fork button is on the top right of the repo page) a copy of the frtizing-parts repository in to your github account. You then make the changes in that repository via a push from your machine (as you did above but to your fork which you have write access to on github). Once that is done then you log on to github (it may be possible from your desktop but if so I don't know how) and in your repository of fritzing-parts first you click on the branch button (top left of the screen) and change from master to nightly-parts as the repository you want to make the pull request to , thenyou click the new pull request button (top left right beside the branch selector). That will make a pull request to @el-j to merge your change in to nightly-parts and it should be all automatic from there. I managed to do something wrong the last time I did this (and didn't write down what I did when it worked either!) and managed to get to a point where I couldn't make pull requests any more. Hopefully with one change that won't happen to you.

Peter

HaraldRau commented 5 years ago

I'm also very far from a Expert, i will follow your instructions and build a fork from the nightly-Part repository!

Thank you and have a nice Weekend!

HaraldRau commented 5 years ago

Hi Peter, can you have a look at my pull request. I can not say, if everything is alright?

https://github.com/fritzing/fritzing-parts/pulls

I think if everything is O.K., then I close the tread?

vanepp commented 5 years ago

The pull request looks to have been made. I think I'd wait on closing the issue until the request is accepted just in case there are further problem of some kind.

Peter

HaraldRau commented 5 years ago

Well, that's how I do it!