EDIT EDIT
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.
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
true
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.
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.
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.
Get another good svg and just Group copper0 and rename that new group copper1.
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.
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 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.
