Error on load: Unexpected version

I’ve opened and saved it. Not sure if it will help you.
Beep_BRRR.kicad_sch (141.4 KB)

1 Like

Thanks! They were 100% equal (also by running diff on them), so no, as you expected. But it was worth a try.

Do any of your other schematics also give the same issue? Maybe some issue with your installation?

Strange that it opens fine here.

1 Like

… I only have this one! (being so new). But I’ll try more tomorrow, like making a new and see what happens. If ok I could perhaps paste this one in. I guess my installation won’t just give up like that…

Offset 13 is actually at the v in version, not the version date. Could it be some other program, not eeschema, that’s trying to open the file and complaining? How are you opening this project?

1 Like

Thanks @retiredfeline - yes and no. If I start a new project it comes out with the same figures there. I’ll study further, see whether pushing and pop’ing versions on this thread might have done anything, which I doubt. I must do some more diff’ing first. I now tend to think that I’ll need to post this as a code issue.

You should really find out which program is generating that message, all that’s shown is the timestamp. Could it be you have an old v5 version of eeschema, or some plugin that’s reading the .kicad_sch file? Do you have a file association from .kicad_sch to some other program?

You see the word version and you think it’s objecting to the date string. What I’m saying is that the error message has ‘version’ in quotes so I say it’s objecting to the literal word version, which starts at offset 13.

1 Like

I understood what you said, but I didn’t resond to it because I hadn’t made these yet:

Here you see the diff between two .kicad_sch files. The left is the one where it complains, the right is the one that goes ok. I made it by starting a new and then pasting in everything. (It seems like the annotations don’t come across though). The files do differ a lot further down of course:

Here is the one to the right which opens fine:

And here is to assert which app that opens these files. You can also see the version stuff and who opens it.

Hypothesis

  • I did download IRLU2905 MOSFET (I-PAK) symbol from Ultra Librarian that was generated with version 5 of eeschema. Then they sent me one that was generated with v.6. It turned out I didn’t use it, because it was flat on 3D. So I went for a mix. Maybe it isn’t really complaining about ‘version’ but about the fact that I should have used another version to open it with? So it’s actually something about my file’s contents? The text should have been “This file contains an object which is not supported with this version any more, or which may have been converted to a newer version inaccurately”. A hypothesis made from black box arguments, since I don’t know what’s inside.
  • Con: select all from the one that issues this error message then copy paste to a new circuit diagram causes the error to disappear. Will it do some filtering or conversion on the paste?

Edit: Another con. Here is the difference in the files describing that transistor. The left fails, the right doesn’t. Not much to write home about:

Sometimes with formats like S-expressions that rely on balanced parentheses, a missing closing parenthesis far far down the file could trigger a error report for the start of the parenthesised expression. See if you can check if the parentheses are balanced.

1 Like

I gave it an -xml extension and checked it at https://www.xmlvalidation.com and I only got an error in the first line saying

Content is not allowed in prolog.

So it may not be proper XML. The number of ‘(’ and ‘)’ are also the same. Plus, the total diff does not complain about this.

I guess I’ll just close this and file it as an issue, and refer to this post. Thanks a lot @retiredfeline, good questions! (I’ll just live with that error message for now, since it’s only nagging, nothing else, it seems.)

@Aclassifier

S-expressions are not XML.

I’m inclined now to think it’s a bug somewhere in the code where a certain condition causes the execution to fall through to a section where it reports a spurious error with the word ‘version’.

I also suspect it’s something weird and there is nothing wrong with the file itself
I also opened it without problem.
Then I deleted a resistor and used Schematic Editor / Save As and the only difference (according to Meld was the missing resistor.

Ok, thanks: S-expression - Wikipedia ?

Thanks, @paulvdh!

I will come back here and link up the ticket I’ll make.

Ok and as expected: Error on load: Unexpected version. Thanks, guys! However, a bot seems to stop it: Error on load: Unexpected version (2). I will not report any more on this case if this is not treated ok.

It’s possibly a platform-specific bug which is why others can’t reproduce it on Windows and Linux. Which makes life difficult because dev resources are low for Macs. You may have to live with the annoyance for now.

What happens if you open this attached version?

Beep_Copied.kicad_sch (141.4 KB)

I opened two instances of the schematic editor, then copied all the contents from one schematic to the other and saved it.
Some title block info is missing, as the copy did not copy the title block itself.

The header is exactly the same though (apart from the uuid).
Further down in the file all the coordinates have shifted a bit, as I did not bother to try to re-insert it in the exact same location.

I also opened the schematic editor in standalone mode, saved it as an empty sheet and it’s contents is:

(kicad_sch (version 20211123) (generator eeschema)

  (uuid a1545928-1195-40b9-b3c4-78f837012afb)

  (paper "A4")

  (lib_symbols
  )


  (sheet_instances
    (path "/" (page "1"))
  )
)

And again, the first line is the same so this also indicates the error is “elsewhere”.

I think this is the basically same exercise that i did (described above). I started a new and copy pasted the one that had this error masseage into it, and then got rid of the error message after a save and reopening.

And yes, neither the error message on the one @paulvdh sent.

But I didn’t follow the diff further down than the first few lines, as you did (see diff screen clip above).

Aside: By the way, the annotations didn’t follow, not in my case, not in yours - is that how it’s supposed to be? Had they done I would have gone on with it, but since my board is kind of finished I didn’t want to redo annotating and then do a clean-up of the PCB.

I have had a KiCad installed like in 2017 and 2019 (+/-) - but I didn’t find anything left after them. The applications directory /KiCad was totally replaced and in the machine-top/libraries section there’s nothing either. And I made sure yesterday when I installed 6.0.4 that such was indeed the case.

I have also looked in the log files and there doesnt’ seem to be any relevant “kicad” or “eeschema” there. Which might indicate that it’s not a secondary error after some other error that might have been logged.

I did not read your post very carefully, but apparently you already did indeed the same as I did.

With a default Copy & Paste, KiCad clears the annotation, which is sensible, as multiple parts with the same annotation leads to *&^%$#@!.
However, if you press the right mouse button, there is a Paste Special in the popup menu (Also accessible via the main menu: Schematic Editor / Edit / Paste Special) With Paste Special, you have an option to preserve the annotation.

In your diff, the UUID’s and the coordinates change.
In KiCad the UUID’s always change. They have to, because they have to be unique, that is what one of those first two U’s stand for.

The coordinates could be kept the same relatively easy, for example by placing a dummy resistor at (0, 0).

So I combined this and chose: Keep existing reference designators, even if they are duplicated in the Paste Special operation.

The result is visually nearly the same (I kept the reference resistor at (0, 0)).
Beep_2022-03-28.kicad_sch.zip (21.8 KB)

All the UUID’s have (of course) still changed, and stuff is in a different order in the file and this confuses diff programs.

Also, KiCad uses the UUID’s by default to match schematic symbols with PCB footprints. To fix these (now broken) links, you can simply do: Schematic Editor / Tools / Update PCB from Schematic and then select: Options: Re-link footprints to schematic symbols based on their reference designators

This certainly is a crash course for me! Thanks, @paulvdh!

The sch looks great and keeps the barking eeschema away!

UPDATE: NOT ALWAYS! GO TO THE ISSUE:

I linked you up here.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.