Plot settings (.PLT) file incompatibility problem

Question

For engineers who share simulations with one another, it is critical that their files be forwards and backwards compatible. Old LTspice simulations must work (exactly the same, if possible) on newer LTspice versions - and simulations that were created on newer versions must work on older versions too - as long as they do not exploit new features or components that the older version did not have. 
 That compatibility has been violated here. I have been seeing it for a while, but did not track it down until today. 
 The problem being considered here is with the Plot Settings (*.PLT) file. If there is a micro ( &micro; ) symbol to be saved to the Plot Settings file, LTspice 26 corrupts it by saving it as a 2-byte combination. Previous LTspice versions did not do that. They saved the micro character as the normal 1-byte micro character in the ANSI extended ASCII character set, 0xB5. LTspice has used that 1-byte micro character since forever, and still uses it. It is found in every LTspice schematic that has values in microFarads or microHenries. But now LTspice seems to be unable to write it to a .PLT file. 
 And that causes the compatibility problem. Plot Settings files saved by LTspice 26 and contain a micro character, can not be read by older versions of LTspice. 
 Here is a line copied from a .PLT file written by LTspice 26: 
 X: ('&Acirc;&micro;',0,0.00046,2e-05,0.00068) 
 Here is the same line copied from a .PLT file from LTspice XVII: 
 X: ('&micro;',0,0.00046,2e-005,0.00068) 
 As you can see, LTspice 26 saved the " &micro; " character as " &Acirc;&micro; ". LTspice XVII does not understand the corrupted combination with the " &Acirc; " byte, so it rejects the .PLT file. That is unacceptable. 
 Please fix LTspice 26 , so that it correctly saves a " &micro;" as the non-Unicode "&micro;" (0xB5) like it used to do, without altering or corrupting it. There is no need for it to do that. Please restore LTspice's previous behavior, where it understood what a &micro; character was and does not try to cobble it. 
 I should point out that LTspice 26 does not have this deficiency when saving schematic or symbol files. It seems to be only the Plot Settings (.PLT) file that is being corrupted. 
 Thanks, 
 Andy

MStokowski · Answer

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

AndyI · Answer

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&hellip;" 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

SLA Status	Assignee	Support Status
SLA Closed. Met after 49 hours	MStokowski	Awaiting Customer Response

Popular Forums

Product Forums

Application Forums

Design Center Forums

Highlighted Webinar

Places

Libraries

Challenge Yourself!

What's Brewing

Places

Resources

Visit ContentZone

The Latest Read

New Release

Recent Technical Insights

SLA Information

Products Mentioned

Thread Details

Plot settings (.PLT) file incompatibility problem

Before You Switch