Eeschema messing with IC values and footprints - Page 1
Forum section: electronics / general

author: ebastler
author_rank: Super Contributor
timestamp: April 10, 2021, 05:09:22 pm
content: I have run into a very annoying KiCad bug multiple times now, and am surprised that I cannot find any references to it via Google. Have others encountered this? Am I doing something wrong?It happens while I am entering a new schematic. At some point, apparently when I add a new type of IC for the first time, Eeschma messes up multiple other ICs which are already in the schematic: It changes their value, footprint, and datasheet reference to that of the part which I just added! The symbol library reference, and the graphical symbol on the sheet, remain intact.At least that is when I believe it occurs. I have had this happen at least half a dozen times, in three different projects, but never noticed it immediately at the part addition, but only slightly later. Going back via "Undo" will not repair the mess; it needs to be fixed manually, which can be quite tedious when many ICs are affected. Not all existing ICs on the sheet are renamed, but if one IC type gets messed with, all its instances on the sheet are affected. I have only seen this happen to ICs, never to passives.Given that I have observed this multiple times, and that it is a really annoying problem, I would have expected to find it mentioned on the Web -- but have come up empty. Any idea what might be wrong there? I am using KiCad 5.1.9-1 under Windows 10, 64 bit.

author: Bassman59
author_rank: Super Contributor
timestamp: April 11, 2021, 12:12:20 am
content: Quote from: ebastler on April 10, 2021, 05:09:22 pmHaving done about two dozen designs in Kicad in the last few years, and maybe half a dozen with the 5.1.x line, I can honestly say I've never come across the problem you describe. I can't even imagine _why_ it would do what you describe!

author: phil from seattle
author_rank: Super Contributor
timestamp: April 11, 2021, 12:59:22 am
content: Some symbols in the libraries actually point to other symbols. You place the symbol in a schematic but when you go back and look at it, it is called something else. I don't recall the specific part or library that did this. It was a real head scratcher for a while. Might have been a 74 logic series part.

author: retiredfeline
author_rank: Frequent Contributor
timestamp: April 11, 2021, 01:26:00 am
content: Sorry never had that happen to me. Perhaps you could make a note of the ICs and what they turned into next time it happens? Maybe the IC ID you chose was an alias for a group of chips?

author: ebastler
author_rank: Super Contributor
timestamp: April 11, 2021, 06:26:01 am
content: Thank you for your thoughts! This is a mysterious one, I agree...The parts that get messed up are totally unrelated to the new ones I place. Yesterday's example:- Placed Sensor_Proximity:ITR8307-F43- Placed 74xx:74HC14- Noticed (a bit later) that all ITR8307 were now named 74HC14After manually repairing this, a similar problem recurred a bit later on the same schematic:- Placed 74xx:74HC123- Noticed that all ITR8307andall 74HC14 were now named 74HC123As mentioned earlier, where part names were changed, the package information and datasheet link were also changed to that of the new part at the same time. I still see the incorrect links to the 74HC123 datasheet in the parts details to remind me of what happened...Thismightoccur only when adding parts which have multiple units in one package, but I am not 100% sure whether that was really true on all prior occasions.Also, itmightonly mess up parts which I had originally placed once or a couple of times, then replicated (individually or as a small group) via the Shift-Select mouse operation. But that should not cause such problems, right? I spot-checked the "Unique ID" fields for various parts, and they do indeed seem to be unique.What the heck...?

author: pierreraymondrondelle
author_rank: Contributor
timestamp: April 11, 2021, 10:17:48 am
content: I had a similar issue in the past : In a hierarchical design, I edited one of the sheets in standalone mode and saved it. When opening the project again, either in standalone mode or via the kicad .pro Gui, I noticed after a while that several Ref/Des fields were absent or modified. The same may occur in the case that several calls to the same sub sheet are appearing in different sheets of the project, like hyper links.The reason is that every sub-sheet has a date code embedded in it and the sheets calling it have different codes. Hence the Ref/Des can't correspond.What version are you using ?How is your design organized ? Do you edit hierarchical sub sheets in standalone mode ?Please clarify your process.

author: ebastler
author_rank: Super Contributor
timestamp: April 11, 2021, 11:04:13 am
content: Good questions, thank you.The first time this happened to me was when editing sub-sheets of a hierarchical design. I edited these "properly", as part of the hierarchy. There is only one instance of the afected heets in the overall hierarchy, hence a confusion between multiple instances of the same sub-sheet can't be the cause.Currently I am working on a single-sheet schematic and have the same type of problem. But I originally derived that schematic from a copy of one of the sheets from that original hierarchical design, I believe. (There is a large connector with signal names in there which I wanted to retain as a starting point.)So maybe there is something broken or inconsistent in that original schematic file and the new schematic "inherited" that problem? But what could that possibly be? In my understanding the only thing "special" in a hierarchical sub-sheet are the hierarchical labels, and there aren't any in the new single-sheet schematic.As mentioned above, I am using KiCad 5.1.9-1 under Windows 10, 64 bit. Thanks for any further hints you might have!

author: retiredfeline
author_rank: Frequent Contributor
timestamp: April 11, 2021, 11:12:41 am
content: I don't know how you copied over the old sheets, but is some sort of linking going on, such that the file appears in more than one place and editing any link changes the original?

author: thinkfat
author_rank: Unknown
timestamp: April 11, 2021, 11:20:02 am
content: I've had issues like that when placing multiple units of a 74hc14 as well. Do you use hierarchical sheets? Are multiple sheets pointing to the same actual schematic file?

author: jpanhalt
author_rank: Super Contributor
timestamp: April 11, 2021, 11:20:10 am
content: Here's a thread that discusses the KiCad libraries. Symbol and packages are completely separate. I wonder whether what you are seeing may be related to that?https://www.eevblog.com/forum/kicad/eagle-to-kicad/msg3032312/#msg3032312(See: post #5 )I am not a KiCad user, and although I have been using Eagle since v.3, I have not updated past v. 7.

author: ebastler
author_rank: Super Contributor
timestamp: April 11, 2021, 01:10:21 pm
content: Quote from: retiredfeline on April 11, 2021, 11:12:41 amI just copied one of the .sch files (from the original hierarchical design) into the folder which KiCad had created when I started a new project. Renamed the .sch file to the new project name. KiCad saw it as part of the new project and was happy to work with it.I did not notice any interaction with the original .sch or project, and given how I created the new file, can't imagine that KiCad still knows about the connection. I looked into the .sch text file and don't see any reference to the old project there either.Quote from: thinkfat on April 11, 2021, 11:20:02 amAs mentioned in an earlier response, the original project was indeed a hierarchical one. But most of the affected schematic sheets did not exist in multiple instances there, just once.I do have one sheet in that large project which is indeed instanced three times, and it also got messed up at some point. But several other sheets which only exist once were also affected by the mix-up, and that happened before I had even created the multiple-instance sheet. So this is bug does not seem tied to multiple-instance sheets.

author: Bassman59
author_rank: Super Contributor
timestamp: April 11, 2021, 07:53:25 pm
content: Quote from: ebastler on April 11, 2021, 01:10:21 pmThis is a completely new _project_, and you copied previously-used schematics into it, and likely instantiated those sheets into a new top-level sheet?

author: julian1
author_rank: Frequent Contributor
timestamp: April 11, 2021, 08:24:43 pm
content: Quote from: ebastler on April 11, 2021, 01:10:21 pmIs instancing the same sheet file more than once, supported in kicad?I think designators (eg. C19, R20) are embedded in sheets, which wouldn't work well if the higher level layer thought it was managing truely independent files/sheets. (I know you said that problem occurred outside this context, but I would be interesting to know).

author: pierreraymondrondelle
author_rank: Contributor
timestamp: April 11, 2021, 09:02:36 pm
content: Hard to tell, the following is based on my own experience but as a rule of thunb, never edit a file in standalone mode, always use the project.pro. Except if it's not a hierarchycal file.If you copy a project in order to modify it, copy the entire project. Keep the subsheets into the same directory as the .pro file.When a sub file is created from the top file, a time stamp "U" is written inside the .sch file, making the file unique, Ref, Des and other fields are saved accordingly:(this is for ver 5.15 but it should be the same for all the 5.0 to 5.19 versions):$SheetS 8000 3400 850 300U 6044F3D0F0 "12-Configurable Extension Line Distribution" 40F1 "12-Configurable Extension Line Distribution.sch" 40$EndSheetThe sheets must have unique names.If you use a unique subfile belonging to 2 diffferent projects _or_ if you edit it outside the project in standalone mode, you will change its contents and when called from the project, the behaviour will be umpredictable. Same if you decide to attach an already existing file to a project. I mean after the project has been closed, if you replace the sub sheet you just have created by another existing one.I suggest that next time, when you have the issue, save the bugging .sch files in another directory, correct and save the prorject normally. Then compare the contents of the two equivalent sch files (modified and original), this will give you a clue where the issue is lying, especially if the time stamps are different.Tpically, this an abstract of a .sch file called from several locations in a same hierarchy, after messing up with wrong Ref / Des:$CompL !My_Switches:SW_SPST SW55U 1 1 5A2DF87FP 7700 2350AR Path="/5A2E973C/5A31DD6B/5A2DF87F" Ref="SW55" Part="1"AR Path="/5A2D3370/5A2DF87F" Ref="SW105" Part="1"AR Path="/60419081/604568C1/5A2DF87F" Ref="SW?" Part="1"AR Path="/604568C1/5A2DF87F" Ref="SW2024" Part="1"F 0 "SW2024" H 7710 2490 50 0001 C CNNF 1 "Key Switch" H 7750 2200 50 0000 C CNNF 2 "~" H 7700 2350 60 0000 C CNNF 3 "~" H 7700 2350 60 0000 C CNN1 7700 23500 1 1 0$EndCompYou can see the multiple time stamps sepatated by "/" as well as the multiple references. This may help to understand why your file remenbered the old organization.And this is an abstract of a clean file called only once from the same hierarchy:$CompL !My_Connectors_misc:GX12-6_inv J11U 1 1 6092B577P 2500 3925F 0 "J11" H 2850 4125 39 0000 C CNNF 1 "GX12-6_socket" H 3025 4050 39 0000 C CNNF 2 "" H 2510 3726 39 0001 C CNNF 3 "" H 2510 3726 39 0001 C CNN1 2500 39251 0 0 1$EndCompHope that it will helpPS have a look to this link:https://forum.kicad.info/t/purpose-of-unit-path-entries-in-schematic/8254

author: ebastler
author_rank: Super Contributor
timestamp: April 12, 2021, 05:32:38 am
content: Quote from: Bassman59 on April 11, 2021, 07:53:25 pmYes, it is a new project. I copied only one previously-used schematic (which came from a hierarchical project) into it; but the new project only has a single sheet.Quote from: julian1 on April 11, 2021, 08:24:43 pmMultiple instances seem to be supported nicely. In the original hierarchical design I have one functional block which is instantiated three times. There is only one .sch file for it, but KiCad manages separate component references for each instance. Depending on which of the instances I enter from the higher-level sheet, KiCad shows the right set of reference numbers, and of course all components and nets show up in PCBnew as expected.

author: ebastler
author_rank: Super Contributor
timestamp: April 12, 2021, 05:41:39 am
content: Quote from: pierreraymondrondelle on April 11, 2021, 09:02:36 pmThank you very much! You are onto something there, I think. I had not spotted the "AR" references as being unique to hierarchical sub-sheets.Still not quite sure what is going on there. I am not editing a sub-sheet separately and then trying to "plug it back" into a hierarchy (which would sound like a recipe for desaster). Also, what messed up the parts in my initial project, i.e. the hierarchical one which I created from scratch?But anyway, I will refrain from creating any further "descendants" from that project, or from other hierarchical projects, by extracting schematic sheets. If I should still observe this problem with a newly created project in the future, I will report back!

author: Bassman59
author_rank: Super Contributor
timestamp: April 12, 2021, 03:06:06 pm
content: Quote from: julian1 on April 11, 2021, 08:24:43 pmYes, I use this feature often. You have to give each instance of a subsheet a different Sheet Name, basically a reference designator for the subsheet.Kicad will also do the "right" thing, which is that when you open each instance of a subsheet, you'll see that each part has a proper unique reference designator. That is, say your subsheet has a simple two op-amp circuit and both op-amps are in the same two-unit package. For Subsheet 1, those op-amps will have one reference designator, for subsheet 2, they'll have a different designator, and so forth. You only see the different designators when you enter the sheets through the hierarchical navigator or when you click on a specific instance.One more thing. Global nets are truly global, so they will have the same net name in all instances of a subsheet. Local nets in a subsheet are all, as you would expect, local to only the instance.I think designators (eg. C19, R20) are embedded in sheets, which wouldn't work well if the higher level layer thought it was managing truely independent files/sheets. (I know you said that problem occurred outside this context, but I would be interesting to know).

author: Wolfram
author_rank: Frequent Contributor
timestamp: April 12, 2021, 03:59:35 pm
content: I've also recently had the exact issue described in the first post, in KiCad 5.1.9 under W10. I've used KiCad for years across maybe fifty board designs, and I've only had this happen recently.I don't remember the exact sequence of events, but I think I added a dual op-amp (multipart symbol) to the top level schematic, after which all ICs in the top level had their name and footprint fields replaced with those of the op-amp.

author: ebastler
author_rank: Super Contributor
timestamp: April 12, 2021, 04:19:58 pm
content: Quote from: Wolfram on April 12, 2021, 03:59:35 pmAh, thank you -- good to have reassurance that I am not the only one who fell into that trap. I am encouraged to try and find a systematic way to reproduce this, and file a proper bug report. (I have tried before, but could not pinpoint the problem. It only seems to occur when one is not looking...)

author: phil from seattle
author_rank: Super Contributor
timestamp: April 12, 2021, 05:37:06 pm
content: I am seeing some library related oddities with 5.1.9. Yesterday, I went to look at a symbol in a library using the symbol editor but didn't make any changes. When I closed editor and went back to the eschema sheet, all the symbols were replaced with the dreaded ?? in a box. Refreshing and such did nothing. Fearing I had lost a day of work, I closed kicad and reopened - all the symbols were back. Glad it was some sort of visual glitch but my cardiologist doesn't appreciate the scare

author: Bassman59
author_rank: Super Contributor
timestamp: April 12, 2021, 07:52:21 pm
content: Quote from: ebastler on April 12, 2021, 04:19:58 pmYikes, now I want to see if I can replicate this bug!