Quantcast
Channel: fritzing forum - Latest posts
Viewing all 31451 articles
Browse latest View live

Nrf24l01Adapter parts help please!

$
0
0

You have been bitten by an Inkscape/Fritzing incompatibility (and there are a number of other problems.)

The color problem is that Fritzing is using the fill (green) in the fill attribute (circled in green on the right) Inkscape is using the style command value (black) circled in red on the right. The best cure (and what I did) is run the finished part through FritzingCheckPart.py which is available here:

among other things, it deletes inline parameters like the fill and moves the values in the style command to inline xml (because in some cases, Fritzing does not support style commands!) so both Inkscape and Fritzing are using the same parameters and thus what you see in Inkscape is what you see in Fritzing. Then I noticed the view box is too large because there is an unused path way to the side of the part, so I deleted that to reduce the size of the viewbox to only the part, as it should be.

Next the view box doesn’t start at 0 0 (which will cause grid offset issues in Fritzing) so in Inkscape do Edit->select all then Edit->resize page to selection to correct that.

As well the svg is missing the breadboard layerId (which will cause the part to not export as an image) so click Object->group to group the entire image and name the group breadboard. Next FritzingCheckPart.py warned that the drawing is dimensioned in px rather than inches which can (and does in this case!) cause scaling problems.

In this case this didn’t help, because the drawing is in a different dpi than my copy of Inkscape as we will see later but this is how the drawing should be dimensioned.

When I saved this breadboard svg, and made a part from it and loaded it in to Fritzing we see the scaling problem.

The top connector is a 6pin header dragged in the the sketch from core parts (circled in green) that is correctly aligned on the .1in boundaries. As we see the connector in the part (circled in red) is shorter indicating its scale is incorrect. To fix this I first selected connector1pin whose x coord is 0.219in then selected connector0pin whose x coord is 0.136in (and should be 0.119in to be on a 0.1in boundary.) That means the drawing needs to increase in scale by 120.4819277108434% to make the pins be on 0.1in boundaries. To do that set Inkscape like this:

lock height and width to scale together, change dimensions to percent (all are at present 100%) and enable scale stroke width when scaling (all circled in red above.) Now change the width to
120.4819277108434%

which rescales the drawing so the pins are on .1 in boundaries

connector0pin is now 0.164in in x

and connector1pin is now 0.264in in x as desired. However because of the rescale, the viewbox is now too small

so do Edit->select all, Edit->resize page to selection and then Object->group and rename the group to breadboard to create a correctly scaled svg with the layerId and save it as plain svg.

Now when I run the part through FritzingCheckPart and zip it to create

NRF24L01-BOv2.0-fixed.fzpz (64.3 KB)

the part is the correct scale in Fritzing (and the correct color!)

Peter


Download der aktuellen Version

$
0
0

You would be best to ask @KjellM (there should be an email address for him on your paypal receipt) as he is the one in charge of the servers. I doubt anyone else will be able to help.

Peter

via google translate

Am besten fragen Sie @KjellM (auf Ihrer Paypal-Quittung sollte eine E-Mail-Adresse für ihn angegeben sein), da er für die Server verantwortlich ist. Ich bezweifle, dass jemand anderes helfen kann.

Set picture on surface of pcb

$
0
0

What Fritzing version are you using? If it is 0.9.6 try downgrading to 0.9.4. There is a bug (which will be fixed in 0.9.7 which isn’t released yet) that is breaking some image loads on 0.9.6. The bug is that Fritzing doesn’t currently recognize numbers of the form

-6.16e-4

in the path d field, so an alternative (perhaps not practical!) is to change the path so it doesn’t have any such numbers only integers.

Peter

MCP2515 CAN Bus Modul AZ-Delivery

Bug to duplicate label

$
0
0

Mac and Linux shouldn’t be to terribly different. I’ll give another shot at it when I get to a decent stopping point on my current design. Some time will have marched by on the M1 stuff. I did manage to get a successful build of the Qt base but not qt creator I think. It was a pretty crazy build. Anyway - I’ll give another shot. Thanks.

Bug to duplicate label

$
0
0

You shouldn’t have to build QT from source (unless the installer won’t deal with a M1 which sounds new), the installer figures it out and installs (at least on Windows and Linux, I haven’t done Macs) as long as the compilers are already present, on Linux it is happy with gcc, Windows is more complex, you need to get the right configuration of Visual Studio to have QT find the tool chain. You can probably fix that if you know enough about QT, but I typically just rerun the install if I screw it up.

Peter

MCP2515 CAN Bus Modul AZ-Delivery

$
0
0

The link to eBay is unfortunately invalid. But there seem to be differences between the CAN-Bus-Module-Board-TJA1050 and mine.

MCP2515 CAN Bus Modul AZ-Delivery


Bug to duplicate label

$
0
0

I used Qt a decade ago or more but I forget the flow of things… is it the case that Qt is ultimately only responsible for converting described UI into source code that implements it?

In that case, you’re right that Qt doesn’t need to be M1 at all. My original goal in poking my head up around here was I wanted to see Fritzing move along the progression into M1/ARM land as I love the tool for maker projects. It’s lightweight, highly functional, and the most integrated experience I’ve had between a schematic, breadboard, and pcb.

Bug to duplicate label

$
0
0

I think that is true, as long as there is a tool chain available (and I think there is an ARM tool chain available in QT) then it should just work. I’m not anywhere near a QT expert though …

Peter

MCP2515 CAN Bus Modul AZ-Delivery

$
0
0

I take everything back!!! Thank you, this is exactly the right thing! thanks

PS2 gamepad port

Diary of a Mac M1 build

$
0
0

I gave a new shot at building Fritzing on a mac and specifically on an M1 ARM processor. My first attempt went down in flames as I had embarked on building Qt from scratch as a prereq. But as @vanepp pointed out, that isn’t likely required to be an ARM build since it’s only instrumental in creating the UI source and facilitating the build if you do the build from Qt Creator. So, I went the download approach for Qt and got the x64 standard Qt items.

Once I got Qt installed, I grabbed boost 1.76 and libgit 0.28.5 per the instructions. And I built the libgit .a library in arm64 without issue.

In the fritzing-app/ folder I did modify the phoenix.pro file to have:

    CONFIG += arm64 

in place of x86_64

I ran Qt Creator and loaded phoenix.pro and eventually found the arguments section to place the “-f” and “-parts” and “-db” arguments into and kicked off a build.

I received over 250 warnings (dunno if that’s normal but wow…) and then I received 6 errors that killed the build. See the screeshot for the errors. Anyone have any knowledge they’d like to impart on me for what I can do to ferret out the remaining issues? I feel like I might be close to a success but maybe that’s overlay optimistic. :slight_smile:

clang: error: no such file or directory: '/usr/lib/libz.dylib'
clang: error: no such file or directory: '/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation'
clang: error: no such file or directory: '/System/Library/Frameworks/Carbon.framework/Carbon'
clang: error: no such file or directory: '/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit'
clang: error: no such file or directory: '/System/Library/Frameworks/Security.framework/Versions/A/Security'
make[1]: *** [../release64/Fritzing.app/Contents/MacOS/Fritzing] Error 1

I did rid the first issue of missing libz.dylib by commenting out the line and making sure -lz was included (which it was in the prior line) per google results.

    LIBS += -lz
    #    LIBS += /usr/lib/libz.dylib

Then I tried to rid myself of the missing /System framework errors and may have wound myself into a rathole. I tried commenting them out and wound up with a complaint about missing /System/Library/Frameworks/Security.framework/Versions/A/Security but no other complaints. And so I then tried FINDING the frameworks like Carbon that I had commented out and looked in /Applications/Xcode.app/Contents/ and found all of them. Great. So I changed the paths of them to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Carbon.framework/Carbon but it didn’t like it until I specifically called out the suffix of “.tbd” and then it was happy to link including my own call-out to the Security one. But somehow the compilation still wants to add in its own hardwired version of the Security framework in /System despite me adding my own. So this starts to make me think I’m just beating on the problem with a hammer rather than knowing what I’m doing on this topic.

I’m unable to tell if this is because I’m on Big Sur or if its more because of M1/ARM64.

I think the other route I’ll give a shot at is compiling through xcode rather than Qt Creator.

Diary of a Mac M1 build

$
0
0

Status update - After banging on Makefile.Release for a bit and realizing it was building in x86_64 rather than arm64 ; and then finding it wouldn’t link because libgit2 was also compiled with x86_64, I rebuilt libgit2 for arm64 and got a successful build of Fritzing.

Phew.

I ran it the first time with the -f, -parts, and -db flags and got a ton of stdout “noise” and the program stopped a few seconds later. This might be normal on the first run from what I gathered about the -db initialization. So I re-ran it without the -db and it friggin’ ran. I’m pretty shocked.

I’ve gotta get my notes together tomorrow on what I changed. And then I’ll need some advice on how to do it properly without the use of a sledgehammer but instead inside of phoenix.pro which I gave up on … and certainly the libgit2 piece I can facilitate a change in the docs with a “-D” option for cmake. But anyway - there’s a nice Sunday night success. I’d probably try to nail all this down tonight but I’ve got a rotten headache and this success is making it bearable. :slight_smile:

'night.
–robobob

Nrf24l01Adapter parts help please!

$
0
0

thank for this part and help I am use an online svg editor :slight_smile:


Servo connector (male and female)

$
0
0

I need connectors (plugs) for RC hobby servos. I cannot find them in the library, at least not in the way I want (I found one where the view is in the direct of the pins; I rather look for a view normal to it). But I am 100% sure they exist. Can anyone point me in the right direction?
Best reagrds,
Andreas

Nrf24l01Adapter parts help please!

$
0
0

Then you need to see if it will let you control the parameters of the svg as Inkscape does. From the documentation (I don’t have Illustrator), I can’t see a way to do this in Illustrator they seem to believe they know best on the svg parameters which can be a problem. Inkscape has its faults, but it is free and flexible enough to do what Fritzing needs. Good luck!

Peter

Servo connector (male and female)

$
0
0

I expect we need a spec sheet or a picture of what you want. Normally servo connections are indicated by a 3 pin 0.1in header like this:

These two are standard generic headers modified to have the servo pins labeled in schematic (a normal generic header has no labels.)

Peter

Servo connector (male and female)

$
0
0

Thank you for your answer. I was already afraid to be not specific enough. I already found the connectors that you describe. I rather search for something like in the following picture (so a different view of the same connector):
Servo_connector

Servo connector (male and female)

$
0
0

It is easy enough to make one, but it is unclear where the wires go. Are you looking for something like this (although this is a motor not a servo)

capture

There are 4 of these intended to attach to a driver card for the MicroBit (the wires are in a different place to allow the connection, which is why there are 4.) Unfortunately the wires aren’t movable so it is less than flexible.

Peter

Viewing all 31451 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>