Component Properties Changed Inadvertently

I am new to KiCad and have been reading and trying a first schematic. I am experienced with schematic and layout tools in general, just not this one.

So I have a small design with around 30 components and a few multi-section devices. One is a 74HC02 from the available library and the others I created. They all use a section just for power pins.

I’m not sure what it is that I do to trigger this, but every once in a while the information in some of the sections will get corrupted with information from another device! It seems the devices I made will take on the properties of the 74HC02. If on the schematic I open the corrupted symbol it will show a lot of data from the 74HC02, but the number of available sections and the current section are always the original value. I have to delete and replace these components to make them right. I’ve done it three times now.

I have only now completed the schematic and have not yet assigned reference designator numbers to anything. The corruption is only between devices with ref des of U?. Could this be the problem, that it is getting confused thinking all U? are sections of the same device type because the U number is “the same”???

At the moment the schematic is correct, but I’m sure there will be more work for me to do. I worried I will keep having this problem and will have to keep correcting the corruption.

Any ideas?

Rick

This under Windows 10 on a Dell Precision M6800 laptop with 32 GB of RAM. The KiCad version info is
Application: KiCad
Version: (5.1.6)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

Start with making regular (preferably daily) backups.
The simplest way to make these backups is to put the whole project directory in a zip file, and append a date in ISO8601 format.

Then, if this ever happens again, you can compare the files from your latest backup with the corrupted files with a program like meld.
http://meldmerge.org/

All KiCad files are simple readable ascii, and by comparing files in this way errors can often be located quickly.

I have not heard of this bug before, but if it is a bug, then having both a good and a corrupted version helps a lot in narrowing down the issue.

Apart from that, it’s always a good idea to teach yourself to make a habit of making backups of anything important on your computer.

Because of the nature of your errors it seems a good idea to also check the hardware of your PC. Do an extensive memory test. Run Checkdisk to test your hard disk or SSD. Are there any errors in the SMART data?
Do you have a habit of plugging the power supply of your laptop in or out?

Are you only having troubles with KiCad, of did you also have some problem with another program lately?

This problem is the only thing going on unusual at the moment on my computer. I don’t really suspect any issues on a more global perspective. I thought maybe there was something about leaving the ref des in the uncompleted state “U?” since the only components affected have that as the ref des, and ALL of the component with that ref des have been affected even if not all sections. I’ll try making backups to have as a reference. The time code thing is a real PITA, but I’ll make an effort.

Rick

I am not really sure i understand what happens. Screenshots of before/after corruption might help.

I can’t make the problem happen at will… or I should say I have not tried. I think I found the trigger. I edited the Value field to be horizontally centered rather than left justified on one instance on the schematic. On exiting the editing dialog many U? components have adopted the Value of the component just changed.

Before…

And after…

I’m glad you asked. I was a bit reluctant to try to reproduce this bug. This is a new program to me and I am still learning. So dealing with bugs is a bit intimidating for concern of blowing away the design. But I backed up the work yesterday so I felt better about playing with it.

So that seems pretty clear. Have multiple components of different devices on the page with the ref des still at U?. Change the Value horizontal alignment from left to center. The value field of many if not all of the components will change to match the one just edited. Odd that not all devices change. Notice that U?C in the center of the image didn’t change.

If I take the same action on a Q? device, no problem is observed. Same with resistors. Only the U? devices do this. I tried setting a U? device ref des to U2B and then changing the alignment on another device and nothing aberrant seemed to happen. So it is just the value field change on U? devices that causes the problem.

Rick

1 Like

I can’t find a solution yet.
I deduce that it isn’t the U? reference. The issue happens to the multiple unit symbols.

I can confirm that weird things happen with component values.
A few minutes ago I had 3 units of a 74HC00 on the top row and 3 units of a 74HC02 on the bottom row of the screenshot.

image
After manipulating the alignment of the value fields, the contents of the value fields from the 74HC02 started changing to 74HC00.

@pedro When you write “I can’t find a solution yet”, does that imply you can reproduce the error?

So this looks like a genuine bug in Eeschema. I’ll do some more testing trying to narrow down how and when exactly this gets triggered.

1 Like

I have not tried to reproduce the error. Maybe the solution is annotate before aligning the fields. But this solution doesn’t solve the bug.

Annotating the schematic is a workaround, not a solution. :slight_smile:

It just happened again.
I had 2 units of a 74HC74 and 2 from a 74HC00 next to each other and changed the horizontal alignment of one of the left 74HC74 and the value field of both 74HC00 IC’s also changed.

I’m using KiCad V5.1.6 on Linux Mint, but Gnuarm uses Windows.
Full version info:

Application: Eeschema
Version: 5.1.6-c6e7f7d~86~ubuntu18.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 5.3.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.5.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

Then I added a 74AHC04 to the schematic, right clicked on the value field and changed Horizontal alignment from Center to left.
Both units “B” of the 74HC74 and the 74HC00 have now changed to “74AHC04”.

I have just created a bug report for this on:

2 Likes

Fix already commited, will be available in next “Testing” build.

2 Likes

:slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile:

When I turned on my PC this morning I saw a message that the issue on Gitlab was closed. First reaction was: Huh? WTF???

Then I looked a bit further and I noticed it was closed because a fix was committed. So that’s 14 hours from bug report to committed patch. You guys are amazing !!!

3 Likes

That is amazing. I guess the coders on this project don’t have commitment issues! :wink:

Rick