Plot settings (.PLT) file incompatibility problem

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

Hi AndyI ,

AndyI said:

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.

One reason is to get out from under the vagaries of using (relatively) vestigial ISO8951-X. The decision to use UTF-8 for all but schematics has eliminated many of the errors we (and many on the groups forum) would see. It has greatly simplified support for localized users, and prevents LTspice from being left behind wrt to unicode support. UTF-8 has risen to the point of the defacto standard, even over UTF-16. It's efficient (in byte usage) and backwards compatible with ASCII. So, about that last bit, unfortunately, µ lies outside of the single-byte (first 128) characters supported by UTF-8. If it did, we would not be having this discussion. It is an aw shucks moment. If only the standard had expanded to ANSI… though, probably because it has so many competing definitions.

AndyI said:

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 XVI

Apologies for the confusion, I was using the LTspice "editor" to view the files. It acts as a window, allowing me to see how LTspice views the files. My shortcut, rather than trying to "use" the files. Result is the same: try to use the PLT, get an error; view the PLT in the LTspice XVII editor and see why one would get an error.

From the perspective of those old versions, yes, files are broken. This is an unfortunate, but necessary step to move forward. Many features do and will depend on modern unicode support. This decision was not made lightly, nor without careful study. 

AndyI said:

Anyway, no editor is capable of fixing the .PLT file after it was corrupted by LTspice 26.  The damage has already bee done. 

I was able to open your Example1 file in (free) Notepad++ (running in crossover on my Mac) and save as ANSI and open in LTspice XVII with no visible double-byte confusion.

AndyI said:

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.

The alternative, of course, is to allow LTspice to save these files in ISO8951-X, and maybe this is what you are requesting, but this is somewhat involved, especially when dealing with localized machines, where the "X" used may vary. 

mike

Hi AndyI ,

AndyI said:

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.

One reason is to get out from under the vagaries of using (relatively) vestigial ISO8951-X. The decision to use UTF-8 for all but schematics has eliminated many of the errors we (and many on the groups forum) would see. It has greatly simplified support for localized users, and prevents LTspice from being left behind wrt to unicode support. UTF-8 has risen to the point of the defacto standard, even over UTF-16. It's efficient (in byte usage) and backwards compatible with ASCII. So, about that last bit, unfortunately, µ lies outside of the single-byte (first 128) characters supported by UTF-8. If it did, we would not be having this discussion. It is an aw shucks moment. If only the standard had expanded to ANSI… though, probably because it has so many competing definitions.

AndyI said:

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 XVI

Apologies for the confusion, I was using the LTspice "editor" to view the files. It acts as a window, allowing me to see how LTspice views the files. My shortcut, rather than trying to "use" the files. Result is the same: try to use the PLT, get an error; view the PLT in the LTspice XVII editor and see why one would get an error.

From the perspective of those old versions, yes, files are broken. This is an unfortunate, but necessary step to move forward. Many features do and will depend on modern unicode support. This decision was not made lightly, nor without careful study. 

AndyI said:

Anyway, no editor is capable of fixing the .PLT file after it was corrupted by LTspice 26.  The damage has already bee done. 

I was able to open your Example1 file in (free) Notepad++ (running in crossover on my Mac) and save as ANSI and open in LTspice XVII with no visible double-byte confusion.

AndyI said:

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.

The alternative, of course, is to allow LTspice to save these files in ISO8951-X, and maybe this is what you are requesting, but this is somewhat involved, especially when dealing with localized machines, where the "X" used may vary. 

mike