Power LED 10W rgb


Well I got the working MAX part and put the non-working LED svg in PCB view and made that a part, and it works properly. It must be something else.

Why does this svg work when added to the 1st LED above
svg.pcb.Power_LED_10W_rgb_6pin_f0d42002552ba45725e2649f28c52769_3_pcb.fzz (3.7 KB)
but not this svg
svg.pcb.Power_LED_10W_rgb_6pin_366e8c0869ef437e9b4b014d2bb2dcec_3_pcb.fzz (5.4 KB)
I swapped copper0 with copper1 the same on both.
The one that is bigger, ie the 2nd one, has a lot more garbage, where as the 1st 1 is clean.

The guy changed the part on me. The old part I downloaded I swapped the copper#'s and it didn’t work. I just imported a fresh copy and it is correct right out of the box. Maybe he didn’t save it plain svg.
This is the original part I got - Power LED 10W rgb 6pin.fzpz (14.0 KB)
Got paid out and it wasn’t my fault. :slightly_smiling_face:
The question is how do you do a part check on the format.


Checking the format is easy, the part I’m having trouble with is figuring out what the issue is. The first version of this part (as I recall anyway) had pads on both sides of the board because it had copper0 under copper1. Which I maintain is incorrect for a SMD part. I believe the OP corrected that and replaced the part. I have yet to see an example of a part with only copper1 that works incorrectly, followed by a part that works correctly with both layers present. The example in the other thread, as noted, only has copper1 and is said to work correctly so something other than having two copper layers is going on but I don’t know what. The supposed non working version is no longer present to compare (or figure out what is wrong about it) as far as I can see.



Damn, I didn’t notice that the new part works correctly but only has copper1. The thing that gets me it doesn’t “single layer” error in FZ.

This is the original part form 28th Jan.

I swapped copper’s on this one and it didn’t work, but now that I look at other test parts I made from it, and whatever I changed, made some of them work with 2 copper’s.

The MAX part has 2 copper’s, 0 in 1, and that works.


Yes, but it has only copper1 in the fzp file on the pads. It also has


in the fzp file (although that doesn’t appear to make any difference that I have seen). Unfortunately the Max part with only copper1 works identically to the one with copper1 and copper0 so I’m not seeing a purpose in the extra copper0, there may be one, but I haven’t seen a demonstration of any difference yet and don’t know how to create one. The extra copper0 layer may eliminate the no copper0 message (I rarely see it because I standardly test with .1 headers which are two sided). I’m not saying there isn’t a problem here somewheres only that I have not so far seen an example of what ever the issue is. Without that we can’t tell what is fixing the issue. It doesn’t appear to me that adding copper0 to an SMD part fixes anything.
This sketch has the original (copper1/copper0) max part and a new one I created with only copper1 in the pcb svg (and silkscreen above the coppers). It behaves identically to the dual layer part as far as I can see.

test Sketch.fzz (26 KB)



Yeah you’re right. Even your single copper1 part doesn’t error when I edit it.

I made a lot of LED’s and some work and some don’t - I’ve forgotten what I did - , but when I went back and checked, all the one’s that do work are the new single copper1 svg’s.

The only thing that annoyed me about the single copper’s was the error when editing, but now I’m not getting errors. I wonder why FZ doesn’t care in this case.


The excess garbage (likely from an Inkscape save as Inkscape as it appears to be their namespace crap which does god knows what) is the only obvious difference, other than one having copper0 and the other not. I.d suggest start with the working one without the crap and add copper0 to it and see what happens. If that works, then it is the extra garbage causing trouble somewhere.



You piece of garbage. :slightly_smiling_face:

I got the clean svg with only copper1. I rename that group copper0. I select that copper0 in XML Editor in Ink and press Group. I rename that group copper1. And it doesn’t work. :rage:

Get another good svg and just Group copper0 and rename that new group copper1. :face_with_symbols_over_mouth:

copper in copper doesn’t work.


Yet it does sometimes, as in the max part. I don’t think its useful but at least sometimes it works. Unfortunately we aren’t any further ahead in figuring out what doesn’t work and why.



Now we’re in trouble. :slightly_smiling_face: From the Wiki

Through-hole vs. SMD parts
In Fritzing, through-hole parts are defined as those which use both copper0 and copper1 layers; SMD parts use only the copper1 layer. By “use” I mean use in the FZP for and , and as element ids in the associated pcb view svg file. If an SMD part is placed onto the bottom layer in Fritzing, the layer is dynamically updated to copper0. Some older THT parts use only the copper0 layer; this is no longer correct, however Fritzing will treat these parts as if both copper0 and copper1 were specified. Note that it is very important that if you specify layers in the FZP, you have matching layers in the relevant SVG (more on this below).


You can’t win.
I got the bad svg from the 1st old LED that doesn’t work and put it in the good/working MAX part, and it works fine.

I put the working svg from the MAX into the OLD non-working LED, and it doesn’t work.
I put the working svg from the MAX into the NEW working LED, and it doesn’t work.

It’s like it’s a lottery.


It may be bugs with the translation from old to new code. That is what I’m trying to determine here, if there is an issue is it a bug, wrong formatting or what. It may be a bug where something isn’t being set and whatever value it had (which may be random) controls what happens. If we can find a test case that fails at least semi regularly it is possible (if not necessarily easy) to trace what is happening in the code and try and find the cause.



I’ve got so many combinations of parts I can’t remember what they are, so I think I’m going to delete them all and start again, but this time write down the combinations - bad memory -.


I never have to edit FPP files or do any work with a text editor. You simply create SVG without additional elements and tags, and then use the editor to assign things. This is part built up by old standards, but with the new unclear standards used by its editor it is complete and does not have time…
مشاوره روانشناسی مشاوره خانواده تلفنی


If that works for you, use it. There are a number of cases where it doesn’t work, because parts editor was not finished when development stopped. Bendable legs is one, eliminating unused views is another, fixing people’s broken parts is a third. This particular discussion is mostly moot at this point, because the only person with actual data about the issue has chosen to not participate any more. Old_Grey is trying to recreate an example that breaks so we can see if it is a bug or not. He may or may not succeed.



Hello, I don’t know what you guys are fighting of,
but since it was a power LED, from my experience the part maybe need a big heat pad for heat distribution?
although the user can easily add a pad for that :\


It isn’t to do with the part directly, but rather the internal format in Fritzing. In SMD parts they typically (and to the part standard) have only a copper1 layer. It is alleged that this is incorrect that they should have both layers. The person that stated this has decided to not participate anymore and Old_Grey is trying to recreate the problem. I’m not entirely clear on what the problem is, but it is supposed to be to do with putitng an SMD part on the bottom of a board being incorrectly swapped if it is non symetrical. I haven’t been able to reproduce it, but I don’t do boards all that often either.



That’s his usual MO, ie leave a hint, so it is to be expected. I suspect no one knows why, it was probably just a part that worked and was always used as an origin part.

What a mess. Spent 2 hours trying to delete a FZ file all over Win, so that FZ would stop giving the “part already in FZ” msg, and in the end had to hack the file and change the XML file name.

I only just started and another weird thing happened.
You put old(non-working) LED in PCB and added copper fill, and the short-cut undo Ctrl+Z works.
Select Bottom in Insp for the LED part and copper fill, and Ctrl+Z doesn’t work. But Edit/Undo does.
Clear the PCB and select View from Below and drag the part and copper fill, and Ctrl+Z works again.

The way you put a part on the PCB makes and Ctrl+Z not work, even though Edit/Undo always works.


These are the combinations
MAX is the MAX PCB svg - copper1 with copper0 inside
Bsvg is the bad svg from the old LED - copper0 with copper1 inside
Gsvg is the good svg from the new LED - copper1 only

Old LED - orig - not working
Old LED + MAX - not working
Old LED + Gsvg - working

MAX LED - orig - working
MAX LED + Bsvg - working
MAX LED + Gsvg - working

New LED - orig - working
New LED + MAX - working
New LED + Bsvg - working

The Old LED is the most confusing, because the Bsvg and MAX don’t work, but the Gsvg works.

I don’t know if it matters - probably not -, but all 20 pin svgs were changed to 6 pin parts


So a single side svg with copper1 only works every time, but parts with both coppers fail sometimes. Unfortunately this doesn’t address the original reported problem where a part with only copper1 is reputed to not work on the bottom of the board correctly. I’ve never been able to make one fail that way, but we all know that doesn’t mean much. An example of that failure is what I’m interested in seeing because I haven’t seen one yet.



That’s what I was thinking, ie copper1 only, is safe. The other thing is the good parts - maybe they have a better .fzp/XML file - don’t mind double copper. There is some sort of interaction, we just don’t know what it is.

I don’t know why I’m not getting single copper error msgs with this part, because I used to get lots when I was playing with parts in the old days - they might have all been THT -. Maybe there is something in the .fzp/XML that tells it it’s ok to have single copper.

EDIT - I wonder if the script will fix that bad orig LED. :slightly_smiling_face: