It may come sooner than you think. El-j has been pretty good about processing the pull requests for parts as long as the pull request is correct (which I expect this one will be).
Peter
↧
Error in s1133 photodiode part
↧
Eagle2Fritzing on Windows
I need an example since I don’t have idea of board names besides arduino ones 
Oh sorry! I forgot to upload the result files here: Arduino_Ethernet_Shield_V2.fzpz (22.2 KB)
Just unzip it since it has schematic + pcb + breadboard view.
As far I know, this is the most updated script available at Github.
↧
↧
Eagle2Fritzing on Windows
I was mainly thinking of something like a big IC part, like maybe a Atmega 2560 chip. The problem I keep seeing on most parts is that there will be pads on pads on id pins on more id pins etc.
So you’re saying that the Eagle2FZ makes a svg, and then you load that into your part, and when you export it it has nodes on nodes ad infinitum.
↧
Error in s1133 photodiode part
There is a problem with that one in that the silk in PCB is white, and that makes it hard to identify in the icons in Insp when you hover over the part. I usually click on the silkscreen group in the XML dialogue of INK and hold shift and click on the blackest square on the bottom colour toolbar.
Sorry if I’m a bit picky.
What the distance been pins supposed to be because I’m getting 180mil.
It’s the convention to put the sq pad next to the marker.
↧
rotary encoder parts
hello guys,
thanks for your clarifications. Unfortunately, none of the components in the library match the correct one for my needs. the distance between the holes and also the fixing legs are different. I found the component datasheet but I am not able to create a component. Thank you for your availability.
↧
↧
Eagle2Fritzing on Windows
Thanks, I’ll have a look and see (I’m a bit slow right now because I had an eye operation last Monday) and my vision is a bit impacted as I recover.
As I said I’ve not used or looked at the eagle script (I only actually downloaded eagle to get a footprint of something a few months ago) so I’m repeating (from memory as well 
) what I remember hearing from others many months ago. I think the adafruit version is considered the most up to date. I don’t know if that is the version on the Fritzing repo or if there is a newer one on adafruit’s repo somewhere. Looking at file timestamps may be a way to tell, as may be searching for eagle or eagle to fritzing here in the forums.
No not exactly. My impression (without having used it) is that eagle to fritzing generates a full fzpz file from the eagle input (which may or may not have dup connectors). When I’m making a new part because I’m lousy at breadboard, I tend to find a part that will do what I want that someone more skilled has made and use copy/paste in Inkscape to copy the part of the svg I want in to my new part. When doing that if the part I copied has connectors, they will get copied in with their current connector id (typically with a -number such as -3) on the end. They are typically the same as the existing connectors in the svg (assuming I started from something with connectors). I think that is a more likely source of such issues that the script (although I could of course be wrong). An example would be a good thing so we know where the issue is coming from.
Peter
↧
Error in s1133 photodiode part
The parts check script will correct this as it checks the part (one of several modifications it does make to the svgs), but it looks to be done already in @sublimeartistry 's part.
Me too! This part has a few more problems: missing terminal Id definitions in schematic for one (which results in wires connecting to the middle of the pin in schematic). The svgs are scaled wrong too. If we are going to update this in core I’d rather see the update done entirely correctly so it doesn’t have to be redo later … We should find the data sheet and verify the entire part in my opinion before doing an update to core.
Peter
↧
Error in s1133 photodiode part
I downloaded it again and the PCB is still white for me. So long as the script fixeds it and it gets uploaded to Git black.
Just noticed silk is under copper too.
↧
Error in s1133 photodiode part
This is a result of using the parts editor. It doesn’t care what color you use it changes them for you. I think it was an attempt to make things more consistent.
This again is a result of how the editor does things. I would also think it is a sign of how they would like parts made as it was the direction they were going. If they are trying to make a new Web tech version of Fritzing with a parts editor being first thing I would think it would be similar to the current one. It would be safe to say all of this information is in the the API docs.
↧
↧
Error in s1133 photodiode part
So far I just switched connector pin / terminal in schematic view and pushed to github repository so the part still working without any rescale / color changes on pcb in order to keep it simple.
↧
Error in s1133 photodiode part
My fault, I was looking at the svg after I had run it through the script. The one posted is indeed white in silk when I re unpacked it.
Sounds like the upload without that is already done …
I don’t agree and the parts format document is ambiguous:
“The terminalId attribute is optional. Each connector takes up a certain area in a part (in the example above, it’s a rectangle), but a wire will actually attach to a connector at a single point within the connector’s area. This point of attachment is called a terminal point. The default terminal point is the center of the connector area. If you want the terminal point elsewhere, the terminalId attribute points to yet another element in the SVG file. Here is the SVG element for the terminalId attribute “connector0terminal” in breadboard view:”
TerminalId is indeed optional, as it says, if you omit it, then the wire connects to the center of the pin. In breadboard that is often fine as the pin is square and the center is where the connection should be. In schematic I think it is less fine as the pin is usually .1in long by 10 thou wide which means the wire will connect .05 in from the end of the pin which to me looks ugly. The n/s/e/w setting for terminal in parts editor will set this correctly and sets the terminalId so I think it can be argued either way. Most (but certainly not all, although I think that is an oversight rather than intention) of the parts in core have terminalId in schematic at the appropriate end of the pin. My script warns (but doesn’t error because it is optional) if that is not the case. I’d like to see us come to a consensus of what we would like to see (and I’d like to see terminal on the end of the pin as is possible now) and lobby and/or help make that true of the new design if it proceeds.
In fact in this case there seems to be an error in your uploaded part. For this the diode on the right (p1) is the one from core and the one on the left (p2) is your new part. The original is what I would say is correct in schematic. Yours lacks the terminalIds (which the original obviously has although I didn’t check the svg). As well your pins appear to be offset from the .1in grid by .05in. That should mean the part submitted to github should have schematic correct, but not the scale nor silkscreen being black but neither of those are vital.
Peter
↧
Error in s1133 photodiode part
That would be my fault for not setting them to the ends. Just because I don’t usually edit schematics and I simply did what I do for PCB images. I would agree that having them at the ends is nicer and has been an issue on a few things I made in the past like Nixie tube schematics which did not exist in Fritzing.
The silkscreen color would have been updated to black if I had exported the SVG and reimported it but since I only changed the pins it stayed white.
↧
rotary encoder parts
I think (note the weasel word ) this will do what you want. It is basically the alps encoder from core with the switch added (and a variety of other things such as rescaling, breadboard, schematic and pcb modified to add the switch). I assumed the original pads were the correct size for the alps parts because the layout was similar (if missing the switch terminals). Before ordering boards with this pcb footprint, print out a copy and check alignment and hole size against the real part (I don’t have one to do that with). Note the called for square holes for the mounting pins are round holes in this case as Fritzing (AFAIK) doesn’t do square holes.
Rotary Encoder ec11e.fzpz (9.7 KB)
Peter
↧
↧
Changing the color of LED
Actually ,the led color is changed by the led color in the luamirnare. There are two(Tunable white) or four (RGB/W) different group LED , change each one output current will change mixture of color.
↧
Changing the color of LED
I figure it out. You must use the “inspector” to be able to change the color of the LED.
↧
Fritzing2Web - looking for contributors
I followed the first install procedure in the readme.md on Win7pro:
Try and install it on Windows.
Use the first method so install yarn
Use the first method (the installer)
First install Node.js from
download node-v8.10.0-x64.msi
run the installer to install it.
Appears to have installed correctly.
back to
Download yarn-1.5.1.msi
run the installer to install it.
install git for dos from
Git-2.15.1.2-64-bit.exe
and install it.
In my case I installed gnu make from
http://gnuwin32.sourceforge.net/packages/make.htm
(your make should do the same I expect)
make-3.81.exe
and added it to my windows path (which it doesn’t do by itself) then in a git command prompt (because the code wants git to be available). Then I changed in to the repository directory in the git cmd window and I ran
from a command prompt?
yarn add fritzing/fritzing-parts-api-client-js
then the make test that @paulvollmer suggested above that I run. That creates this error:
C:\Users\Owner\fritzing-parts-api-client-js>make test
FAIL test\index.test.js
● Test suite failed to run
TypeError: C:/Users/Owner/fritzing-parts-api-client-js/src/index.js: Cannot
read property ‘some’ of undefined
at VisitState.onEnter (node_modules/istanbul-lib-instrument/dist/visitor.j
s:141:72)
at VisitState.wrappedEntry (node_modules/istanbul-lib-instrument/dist/visi
tor.js:336:14)
at NodePath._call (node_modules/babel-traverse/lib/path/context.js:76:18)
at NodePath.call (node_modules/babel-traverse/lib/path/context.js:48:17)
at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:105:12)
at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js
:150:16)
at TraversalContext.visitSingle (node_modules/babel-traverse/lib/context.j
s:108:19)
at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:192:
19)
at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17
)
at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
----------|----------|----------|----------|----------|-------------------|
| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s |
|---|---|---|---|---|---|
| All files | 0 | 0 | 0 | 0 | |
| ---------- | ---------- | ---------- | ---------- | ---------- | ------------------- |
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 7.285s
Ran all test suites.
make: *** [test] Error 1
C:\Users\Owner\fritzing-parts-api-client-js>
Hopefully that will mean something to him (it doesn’t to me other than it isn’t happy about something ).
Peter
↧
rotary encoder parts
This should help…
First, recognize that dimensionally, decimal places of 0.1, 0.2… up to about 0.5 mean very little when placing components on a pcb as the pins are flexible enough and the holes are large enough.
Second, the outer dimensions of 11.0 to 12.5 are fairly irrelevant unless you’re trying to squeeze a square peg into a round hole, so to speak.
Meaning, ‘ballpark’ dimensions have been good enough for me and stuff I have flying in outer space for the past 40 yrs…
Having said that, attached is what I use for all of my 12mm (approx dim) encoders (ALPS, BOURNS, PANASONIC… many others). Some of the actual encoders are 11mm, some 13mm… But, the pin spacing is what is important and the ones I use are all within about 0.5mm of each other.
Attached is a file of what I use as a baseline and will work for you. Sure, you can move the pins&holes if you must but, there’s no need… The screenshot is from actual part in a circuit on my desk…
enc_Baseline.fzz (1.5 KB)
↧
↧
rotary encoder parts
Thanks! I’ll compare this with my current footprint and see if I need to make changes. Having a footprint that someone has used is a big help!
Peter
↧
rotary encoder parts
Thought I’d challenge myself and try making a Part.
It’s not as easy/simple as it should be but, I think I have some success…
Attached file is for the baseline geometry that should work with/for a typical 12mm (+/- 1 or 2 mm) with typical pin spacing.
I used the ALPs RGB led Encoder as a starting point.
I did not spend much time dolling it up/tweaking and customizing the metafile…
But, I did export it for production use and brought it into CopperCam (I use it for CNC milling PCB’s). Seems to be okay!
Encoder.fzpz (10.7 KB)
↧
rotary encoder parts
Your part has a number of issues, the most serious being hole sizes. The part has these (in the gerber):
INCH
T100C0.082677
T101C0.043307
The first being the two mounting holes and the second being the
5 pin holes. Neither seem to be standard drill sizes, the first will probably round up to .0860 and the second to .0520 (being slightly larger than the standard .042 used on the 1n4001 diode for instance). They are also quite different from those in the enc_Baseline.fzz file which are:
M48
INCH
T1C0.125000
T100C0.039370
T101C0.038000
Which are 1/4 inch for the mounting holes and .038 ( the standard hole size for .1 square posts) for three of the pin holes and .039 (which I expect should be .038 like the first three) for the two switch positions. As well since schematic (and possibly breadboard too, I didn’t check it) has pins assigned incorrectly you are getting the red square indicating pins not assigned in pcb view in Fritzing. If you can confirm which set of hole sizes is correct I can substitute your pcb view (from either the fzz file or the fzpz file) in to pcb view on my part to get one with a tested footprint.
Peter
↧