I have just installed 7.0.2.
To understand the problem I decided to arrange for having two V7 configurations.
Running with default configuration (KiCad libraries) I found in library 2N3904 and it really when used with SOT23 has B and E swapped.
Now I understand how it could have happened but from what you said:
it looks that you noticed and corrected the problem so even it could have happened I don’t understand how it happened to you. If you corrected it than you should not get PCBs with error.
Do you see _AKL suffix in the missing footprint library error dialog? You are not even using official transistor symbol, it’s from Alternate Kicad Library.
I didn’t mean you do not check datasheets. I meant I do always check the datasheet and my footprints, since the manufacturer can assign 123 or 132 number to the pins.
This statement is wrong for sot-23: there is not a sot-23 part with the pins as they should be. This is not a Kicad problem but common to all EDA (well, to all manufacturers). My first wrong pinout was made using OrCad standard footprints. Their numbering was different from the one of the manufacturer.
Around 1999 we decided that PCBs will be designed by my wife. She’s a mathematician, not an electronic. One of product to be designed wa 8 current loops controlled from COM port (even COM has no power we made to power that device from COM). You were able to connect up to 7 extension devices (each with 8 current loops) so you could serve up to 64 current loops from one COM port (all powered from this one COM). Each loop with 4kV isolation and up to 1200m length.
When she designed 4 loops on right PCB side I said that next 4 loops (at left side) should be symmetrical. I mean than if at right + is up and - is down than at lefty also + should be up and - down.
She made a mirrored copy of those loops. Protel had nothing against it and seeing no DRC errors I also didn’t noticed the problem. I don’t remember how many such PCBs we got. We had to assemble transistors and transoptors upside down.
Piotr seems to have gone even further than I did. But it was enough to try to find a 2N3904 in Digikey and Mouser and some google images. They are all TO packages, so 2N3904 comes in that kind of package by definition and can’t have the SOT package. No wonder it went wrong when you changed the footprint.
If you (tormy) wonder how the same footprint you already tried can now be correct, it was exactly as was told: the symbol is different. The footprint has always the same pad numbers but in the view above shows dynamically the attached symbol’s pin names.
One valid finding from this “issue” is that MMBT3904 symbol in the official libraries, has a wrong datasheet. This will be fixed soon ( i am guessing here ).
Other than that, it is a working ( trouble free ) part based on this.
2N3904S is not in the official libraries, and its datasheet doesn’t seem to follow IPC numbering.
(Not that the ds i linked above does, but at least they didn’t have any confusing numbers in there…)
Now you’re showing datasheet for 2N3904S. It’s easy to admit you found one with SOT, but still it’s not MMBT3904 which was in your first datasheet and which is in the KiCad library – without error. 2N3904 is also correct in the library. There just isn’t a wrong symbol or footprint among these in the KiCad libraries.
You can’t just take one symbol or footprint pin numbering from a datasheet describing a specific part and apply it to another part.
This we agree on, although it’s not caused by KiCad. I hope everyone reading this thread will remember to double check the datasheets, symbols and footprints they are using. The situation with transistors is like that, whatever EDA or library you are using.
I am using 7.0.2 and when I type ‘2N3904’ into the filter at the add symbol box I get a single option and that is for a TO-92 package, nothing else and it is correct. If I type in ‘3904’ without the ‘2N’ then I get a list with 7 entries comprising of ‘2N3904’ and 6 others, when I highlight the ‘2N3904’ I am again shown a TO-92 package with pin 2 as the base and all is well, now if I move to the variant ‘MMBT3904’ I see a symbol with pin 1 as the base and a SOT-23 package so I go to a datasheet for the device at Mouser and find that pin 1 is indeed the base in this package again all is well. The only part of this that could possibly cause confusion is the fact that KICAD offers the same Datasheet address for both devices which I guess could catch out the young players. In summary ‘2N3904’ gives me 1 symbol and footprint which are correct and ‘3904’ gives me a choice of packages and I select ‘MMBT3904’ from the list and I get 1 symbol and a SMD SOT-23 footprint that is correct but I check this stuff again at layout time…just thought I would add to the confusion and give you my take on it
Ever since I started to shift from metal TO-18 to plastic TO-92, more than 40 years ago, I have been occasionally caught out by erratic pin numbering between brands of what should have been the same device.
You learn to check and check again
According to the Fairchild datasheet the symbol and the footprint are correct. You still seem to fail to understand that the KEC datasheet is for 2N3904S exclusively, not for MMBT3904. I said MMBT3904 in the KiCad libraries is correct, you say it’s wrong because 2N3904S datasheet has the pins in different order. Why do you insist mixing data from different parts? That was your original mistake which lead to a faulty board: you took a symbol for 2N3904 and attached a MMBT3904 compatible footprint to it. Why you suppose that 2N3904S footprint (which yet another different part!) and MMBT3904 footprint should be identical as for the pin order?
