To be honest it’s extremely difficult to investigate this without the schematic file, especially if this really is a bug. It could be anything, anywhere, and now we don’t even know if we can replicate the problematic situation.
If this a bug, you should report it, but it doesn’t help without the file. You can also strip down the file to minimum until only the problem is there, or try to create a new showcase from scratch.
Indeed. A few screenshots showing some highlighted names is not very useful here. In KiCad it’s legal to connect different labels together, and this is a useful feature. From your screenshots we can not see what else happens in the schematic. Normally it does give a warning about this in ERC, but those can be disabled. What does it say in your project about this?
Well, a few note
I was presenting the images as a partial indication of the corruption not as the means to diagnosis. I wasn’t about to send a file to anyone without them being willing and able to dig into that corruption. That would be unfair to all
The second image comes from simply loading the file into rev 6, no editing. I was expecting and hoping corruption on this scale would have been seen before and that there was a fix or conversion process since 6 has been out for a while.
The images show the result of that. The labels are indications of the expected form and the signals originally given to those lines. Loaded into version 5 each line highlights on it’s own with the proper signal/net name. Loading into version 6 and it scrambles. Most of the nets are at a minimum renamed.
As far as ERC, this is what I get in that region, complaints about unconnected labels.
Not only are they connected, but reconnecting them has no affect. In any case that’s secondary to the nets being joined to a single net when the file was read in.
As far as reducing the size, that could be a long process with editing the file in rev 5 and eliminating unrelated errors from editing and then reloading into rev 6 to get the smallest the project size. While I understand the instinct, I do think the appropriate size in this case is the project given the extent of the corruption.
BTW, as far as reporting a bug I don’t have a gitlab account, which seems to be needed, and I really don’t need yet another account. I’ll do it I have to but it’s really more sand in the gears
There was a bug in V6.0.9. Updating to V6.0.10 should fix it.
And now there is also:
Updates in the 3rd number are bug fixes and minor things and an upgrade is always recommended and should be safe. Sometimes *&^%$#@! happens though, and if your ability to buy sandwitches depends on KiCad, then I recommend to wait about a week before you update. If a big blunder has been made, it should have been discovered by then.
Thanks, let me give that a try. Might take a day or so to fight past the alligators but I will report back on the degree of success or failure
Just a general note. Attaching a zipped project file isn’t unfair to anyone, except when the poster doesn’t have permission (by copyright or from employer etc.) to publish it. There are people here who are willing to test projects, sometimes someone may file a bug report for you if you are lucky, or even a KiCad developer may get interested and fix it (although usually an official report is needed).
Indeed. Sometimes I ask to upload a project, but if a zipped project is already attached then the incentive to have a look at what is going on without having to ask for it just lowers the threshold to have a look. And it’s not like you’re forcing anyone to look at your project.
OK, bopped a couple of alligators on the nose, downloaded the new version and gave it a try.
It made a significant difference and reduces the ERC errors to 68 (more than an order of magnitude reduction).
It’s either made clear something with buses or is complaining about something new.
It hasn’t fixed the issue I started with but the bus issue could be related and it’s clear enough that I’m going to try to reproduce it in something small enough to digest.
OK, I have managed to reproduce this in a nice small schematic using only standard library items. It is related to the busing. It’s definitely a behaviour change between 5 and 6 and I’d consider it a bug.
VersionTest.zip (3.8 KB)
Note the highlighted net is composed of nets that remain separate in version 5. They are shorted on reading into version 6. I suspect the problem is that version 6 is interpreting the sub buses that are dropped off of the main bus as if they are the full bus. This is contrary to version 5 which correctly interprets them as subsets. It’s also, in my opinion, contrary to the principle of least astonishment. I would have expected it to work as it does in version 5.
The example I’ve done showing the issue sort of illustrates why it’s useful to behave in that fashion, but you can hopefully see why it’s useful for fanning out or merging signal buses. An example might be merging analog input signals to a central, high channel count converter, where each input channel requires significant conditioning and power management.
I think this likely accounts for most of the remaining issues since this particular schematic has multiple such buses with subset branches.
BTW, the zip is the original Rev 5.
Such sub-branches are not supported in v6 (see discussion Is it possible to simply make a branch from the bus? or gitlab-issue Schematic Editor [Feature request]: Would it be possible to add an easier way to make bus branching? (#13673) · Issues · KiCad / KiCad Source Code / kicad · GitLab to implement such a feature).
You could find a short explanation in the kicad-documentation: Schematic Editor | 6.0 | English | Documentation | KiCad
Section Electrical connections → bus connections → Buses with more than one label
According to the documentation there should be a “migrate buses”-dialog at opening the v5-schematic, but this dialog didn’t show up. Thats the only bug I could see.
So for your schematic there is the need to differently slice the buses. (Or feed the complete bus into the subsheets).
Your sub-buses on the right side are not connected to anything. You can see that from the small square at the end. You need a subsheet entry and connect correctly.
Get that fixed first.
That’s the normal indication for a passive connection to a sub sheet ML9014. It is connected.
@mf_ibfeew well, that explains it. It’s decidedly unsatisfying to have that subsetting and supersetting capability suddenly disappear, it’s a very useful feature not to burden hierarchical sheets with knowledge of bus members it doesn’t use. Even more unsettling to have it fail silently on an upgrade.
This has the potential to produce boards with shorts, especially since it produces no errors on an ERC.
Unsatisfying is probably a little understatement for your situation (I can feel your problem). I would do something like the picture shows:
This has the potential to produce boards with shorts
yes, on converting a v5-design to v6/v7.
especially since it produces no errors on an ERC.
This is not entirely true. I get multiple warnings:
But i must admit that there is something wrong with the ERC:
Can I use your project for an gitlab-issue (regarding the ERC)?
Yep, feel free to use the project. It’s just using standard library elements and there’s nothing close to something I’d consider protected.
I do see the warnings, just pointing out that warnings are easier to ignore.
And thanks for the work around idea.
I noticed some other weirdness.
If I extract a fresh copy then hover over J5 pin 1 and hit the backtick to highlight, I get:
and this is different from what was earlier posted in: Bus renumbered with collisions on import from 5.1.12 to 6.0.9 - #13 by Robert1
If I then:
The result is:
I found another replicable oddity in the ERC while cleaning up. I’ve modified the test schematic to show it.
VersionTest.zip (5.9 KB)
I’m seeing an issue with checking on output types on hierarchical sheets.
The original looks like
Results in ERC errors in version 5. Version 6, however, is much worse. In version 6 an ERC check of this results in the schematic editor crashing!
What does work to silence the ERC in version 6 without causing the schematic editor to crash is to add unterminated nets! So the following passes ERC
While better than crashing, I think that’s worse than Revision 5 but that may be my personal aesthetics.
BTW, for anyone wondering why the outputs would not be connected, think of the hierarchical sheet like an IC, used in multiple places and boards, it doesn’t always have all of its pins connected.
That bug was introduced into v6.0.10. NC-Flags on hierarchical sheet pins caused the crash. I think this was the main reason for the v6.0.11-version (released some days ago, which was originally not planned). An update with this last v6-version should solve the crash.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
