Plot settings (.PLT) file incompatibility problem

Hi AndyI ,

Yes, I see. Do you have a sample PLT file we can play with? I'm assuming you did all work in LTspice, including any direct edits of the PLT? Thanks.

mike

Mike,

I have attached two .PLT files here.  Both illustrate the problem with the micro symbol in LTspice 26.  They were sent to me by two individuals.  Presumably both were saved from LTspice and have not been altered since, except for renaming them (which was done in the usual way from Windows Explorer).  As far as I know, no direct edits were made of either .PLT file, so they are exactly as LTspice saved them.

Andy

Example1.plt

Example2.plt

Hi AndyI ,

Great, thanks. I'll try to reproduce. My hunch is that this is a with PLT-specific oversight wrt the sync'ing of all the save functions to UTF-8. Been wrong with these hunches before.

mike

Hi AndyI ,

I'm able to repeat even with new PLTs. I'll enter it in as a bug.

mike

Hi AndyI ,

Some more info from my testing. This appears to be a problem with the LTspice text editor, not just PLT files. Problem shows up in independent netlists as well, an I assume any text file saved from the text editor has this problem.

Furthermore, appears to apply to all extended characters. 

mike

I would assume that SOME extended characters require two bytes like this, so it might be unavoidable for those extended characters. 

However, the micro character has a single-byte version, and previous versions of LTspice used it.  That seems to be what "broke" the PLT files for backwards compatibility.

Thanks,

Andy

Hi AndyI ,

Unfortunately, the problem is entirely in the Old LTspice file structure, which is not as standard an encoding as one might think.

That is, you'll find that if you edit a netlist in a text editor, other than Old LTspice, you'll run into the same problem. This is an old problem, one of the reasons one should not edit a netlist or schematic in a text editor. It is possible, but unlikely that it will work. 

So, why do ASC files not have this problem? That is because, ASC files are still (New LTspice > 24.1) stored in the ASC (Old LTspice) format for backward compatibility wrt to schematics. 

I played around saving some simple text files using extended characters and saved using a number of formats. Old LTspice was not able to decode any of them. If you have found an.editor/save format that works, that might be a solution. I have heard of editors that work, but don't know which ones.

It is possible that "Save As Legacy file structure" may be added as a feature in the future.

mike

When one is saving or using a .PLT file, normally there is no editor involved.  You simply ask LTspice to Save the Plot Settings, or click the Save toolbar button.  No editor.

I'm just mentioning this because it is not really editor-related - although maybe an editor was behind the actions which the user does not see.  As far as the LTspice user knows, LTspice just saves the file, no editor is involved.

Over in the LTspice User's Group we used to have problems like this when someone or something edited an .ASC schematic file and saved it with corrupted 'micro' symbols.  Some editors did no do this (they handled it correctly) but others did not.  (There was a time when I remembered which ones were bad and which were OK.)  With schematics it was not totally bad because LTspice opens the modified schematic; but some of the values were off by a million which is pretty bad.

However, in the case of .PLT files, LTspice can't even open the .PLT file.  It is a complete failure in that respect.  It might not be so bad if it opened and used the .PLT file but just had the wrong labels applied to the plot pane.  But there is nothing we can do about that now.

Thanks,

Andy

Hi AndyI ,

AndyI said:

Over in the LTspice User's Group we used to have problems like this when someone or something edited an .ASC schematic file and saved it with corrupted 'micro' symbols.  Some editors did no do this (they handled it correctly) but others did not.  (There was a time when I remembered which ones were bad and which were OK.)  With schematics it was not totally bad because LTspice opens the modified schematic; but some of the values were off by a million which is pretty bad.

Yes, this is the same frustrating problem. New LTspice, to retain backward compatibility with old versions, uses the old asc format. To move forward, we would have to break the chain at some point. Certainly a point of discussion here.

Our focus is to keep moving forward, but retain as much backward compatibility as possible. At this point, though, many of our internal models take advantage of new features. Again, the chain will get thin over time. 

AndyI said:

However, in the case of .PLT files, LTspice can't even open the .PLT file.  It is a complete failure in that respect.  It might not be so bad if it opened and used the .PLT file but just had the wrong labels applied to the plot pane.  But there is nothing we can do about that now.

My suggestion for now is to go back in time and find those editors that worked. Open the "new" PLT in that editor and "save as…" it from that editor in the format that solved the problem in the past. My guess is that this should work as a way to produce a "clean" version of a PLT for use in Old LTspice.

mike

Mike wrote:

Yes, this is the same frustrating problem. New LTspice, to retain backward compatibility with old versions, uses the old asc format. To move forward, we would have to break the chain at some point.

Give me one reason why.

I can think of no reason why one would change LTspice so that it no longer understands the 'micro' character.  Why would anyone BREAK LTspice and make it lose its compatibility with LTspice?  There already is a 1-byte micro character in the ANSI character set.  LTspice uses it.  Don't change that.  Not ever.  It would be ridiculous to re-code LTspice so that it can't read or write that character.

Mike also wrote:

My suggestion for now is to go back in time and find those editors that worked. Open the "new" PLT in that editor and "save as…" it from that editor in the format that solved the problem in the past. My guess is that this should work as a way to produce a "clean" version of a PLT for use in Old LTspice.

I'm afraid that suggestion is ridiculous, and utterly wrong.  No editor was ever used to make those .PLT files (unless you mean one internal to LTspice that we can't see and have no access to).  No editor should need to be used to "patch up" the mistakes made by LTspice 26 so that the same .PLT file can be used in SwitcherCAD III or LTspice III or LTspice IV or LTspice XVII.

Anyway, no editor is capable of fixing the .PLT file after it was corrupted by LTspice 26.  The damage has already bee done.  LTspice 26 mangled the .PLT file making it unusable in earlier versions.  Why would any editor in the world know how to undo what LTspice 26 did to it?  None can.

Forcing users to either manually edit their files to UNDO the damage made by LTspice, or to add auxiliary programs to search for the damage and fix it, is totally a step in the wrong direction.  I would be ashamed to work for a company that does that.  Please tell me that is not what you are actually suggesting.

Andy