Formatting .op Data Labels in LTspice for Mac

[seamusdemora]

The .op Data Label in LTspice is a great idea. When you need to post a schematic w/ quiescent voltages & currents, it's much more effective to have the values right there on the schematic instead of buried in a table, or (worse) having to create text boxes where the values are C&P from the SPICE Error Log.

But I have not been able to discover how to format the .op Data Labels. The default has way too may decimal places, a large font size  and too often an awkward orientation. Is there a control or interface in LTspice for Mac to adjust these things? If so, how do I "conjur" it up? 



Apologies... I had a screenshot of how this looked, but can't manage to insert that here either. It's not my night I guess.

[Zero999]

Use the round function.

round($*1k)/1k ; display no more than 3 digits (typically automatically expressed in engineering format).
round(I(R1)*1k)/1k ; same display format as above, but expression is of the current through R1.
round(V(1,2)*1k)/1k ; same format, but expression is of the voltage difference between nodes 1 & 2.

http://ltwiki.org/index.php?title=Undocumented_LTspice#Operating_Point_Data_Labels_.28visible_numeric_dc_bias_values.29

[seamusdemora]

Use the round function.

round($*1k)/1k ; display no more than 3 digits (typically automatically expressed in engineering format).
round(I(R1)*1k)/1k ; same display format as above, but expression is of the current through R1.
round(V(1,2)*1k)/1k ; same format, but expression is of the voltage difference between nodes 1 & 2.

http://ltwiki.org/index.php?title=Undocumented_LTspice#Operating_Point_Data_Labels_.28visible_numeric_dc_bias_values.29

 

Thanks, I found and read that before I posted my question. But my problem persists: When I right-click the data label (as indicated in the wiki) I DO NOT get a dialog. I suspect this is because I'm using the Mac version of LTspice?? I've downloaded the example, and was surprised to see the formatting/rounding is working as it should... but I cannot find where this is inserted in the model!? This works fine in the Windows version of LTspice (as shown below) - but not in the Mac version.

It's not in the SPICE error log. It's not in the SPICE netlist. It's not a SPICE directive. Where is it - and how do I create it in the Mac version?

EDIT: I found what appears to be the data label formatting directive in the Roundingdemo.asc file for this model (hopefully one of the screenshots below). But it's not immediately clear how to incorporate this into another schematic/asc file. Must the .asc file be edited "by hand" to incorporate the data label formatting?

[Zero999]

Sorry I can't be much help, as I don't have a Mac.

Have you tried holding a key such as shift, ctrl, alt, or another mouse button, whilst right clicking? That sometimes helps with Linux, when I've had problems with functionality which works in Windows.

The only workaround is to copy and paste from my file and use a text editor to change the expression. Not very user friendly, I'm afraid.

[seamusdemora]

Sorry I can't be much help, as I don't have a Mac.

Have you tried holding a key such as shift, ctrl, alt, or another mouse button, whilst right clicking? That sometimes helps with Linux, when I've had problems with functionality which works in Windows.

The only workaround is to copy and paste from my file and use a text editor to change the expression. Not very user friendly, I'm afraid.

There seems to be no combination of keys that will produce the same (or similar) dialog that the Windows version presents.

And even more unfortunately, editing the .asc file doesn't seem to be an option. Copying and pasting the "round($*1k)/1k" specification from your .asc file into my .asc file causes the schematic to "blow up"! Don't know why this is - perhaps I'm unknowingly violating some syntax??

But I suspect it's a bigger problem: If I use Mac's TextEdit app to open .asc files that were created by LTspice on the Mac, they look like normal plain text files. However, if I open that same .asc file in a bona-fide plain text editor (BBedit for example), I see that each character is separated by an "upside-down question mark". Oddly - LTspice seems to have no problem using plain-text files - for example the "Rounding demo.asc" file I downloaded runs fine.

Haven't chased this to ground yet... BBedit isn't giving me much help for now, but it does seem clear that LTspice for Mac generates .asc files that are not plain text.  This seems to imply that LTspice-for-Windows .asc files work fine in LTspice-for-Mac, but not the reverse. I've copied a couple of lines from an LTspice-for-Mac .asc file to illustrate:

C&P 2 lines:
W

[Zero999]

What I meant was, have you tried opening my file on the Mac and copying the data labels to other schematics?

Please post an LTSpice file you created using the Mac version, no formatted data labels or anything, so others can test it using the Windows version.

Have you tried running the Windows LTSpice under WINE?

[seamusdemora]

What I meant was, have you tried opening my file on the Mac and copying the data labels to other schematics?

Please post an LTSpice file you created using the Mac version, no formatted data labels or anything, so others can test it using the Windows version.

Have you tried running the Windows LTSpice under WINE?

 

Yes - I did open your file. It renders a proper schematic, and runs perfectly in LTspice-Mac. Then I copied the data label formatting spec ("round...") from your file, and pasted it into an .asc file created by LTspice-Mac. I used (initially) Mac's built-in text editor (TextEdit) to make these changes. Once the edits were made, I re-opened the .asc file in LTspice-Mac to check the result. The result was chaos. By that I mean LTspice-Mac did not render the schematic correctly, and the simulation failed.

I sat back, and wondered... WTF?? 

Since then I've learned a couple of things. I hope to post a more thorough analysis once I've got it all sorted, but here's what I have now:

1. LTspice-Windows generates .asc files using charset=us-ascii encoding; this, according to running the Mac's CLI `file -I` command on your .asc file

2. LTspice-Mac generates .asc files using UTF-16 Little-Endian encoding; this according to a trial-and-error process with different formats in the BBedit app on MacOS. In a fine example of Apple's attention to detail, the `file -I` command for an .asc file generated by LTspice-Mac reports its file encoding as charset=binary. 

3. Apple's built-in text editor (TextEdit), renders UTF-16 LE in the same way it renders us-ascii ; there seems to be no way to tell the difference in this app. In other words, .asc files imported from Windows (like yours) look identical to LTspice-Mac generated .asc files when viewed in TextEdit. Only when I viewed these files in a competent text editor (BBedit) did I see the difference: the NUL character is inserted after each ASCII character. Perhaps the LTspice-Mac maintainer(s) are not even aware of this?

4. It seems that what caused the issue is that the text I copied from your us-ascii .asc file, and then pasted into my UTF-16 LE .asc file is pasted literally - a bit like "mixing apples and oranges" I suppose. I wind up with a hybrid file containing both UTF-16 LE and us-ascii characters in the same file.

For now, my only solution is manual intervention using BBedit to convert UTF-16 LE .asc files generated by LTspice-Mac to us-ascii. This isn't ideal of course as it will be tedious & error-prone. Open to any suggestions!

Wrt Mac-Windows compatibility in LTspice, this is how it looks to me at present:

1. LTspice-Mac will happily process and run .asc files with us-ascii encoding generated by LTspice-Windows.

2. If any changes are made to a us-ascii .asc file using the LTspice-Mac GUI, the us-ascii .asc file is changed to UTF-16 LE

2. I've attached an .asc file generated by my LTspice-Mac for anyone who cares to test it. I don't know if the transport & storage of the file will change it, so I've also attached a compressed version.

Finally I've submitted a "report" to AD via their tech support form-mail, but I'll guess this will be lost in their bureaucratic maze. I have noticed that the Windows version of LTspice has an option under the Help, About menu to email a bug report. Unfortunately, that option is not available in LTspice-Mac. Maybe one of you Windows users could forward this as a bug report??

I'm surprised the maintainers have not discovered this. LTspice is not open-sourced, so there's not much to be done on our side except to wait for the maintainers to discover the issue & repair it. Or, perhaps they are aware of it, and consider it a feature instead of a bug? Any other suggestions??

[Ian.M]

I'm not surprised LTspice text files are 'wierd' by Mac OS standards, as it has to maintain file compatibility with the Windows application, and I doubt there's been much pressure to add native file import.

If you can rename the .asc file with any extension LTspice doesn't have special handing for, you should be able to open with LTspice's internal text editor, tweak the .op labels, then save, undo the rename and reopen it as a schematic.

[nfmax]

I came across a similar problem a while back, but when exporting results - on Mac, the file was saved as UTF-16. This in turned tripped up a bug (which I reported) in LibreOffice when I tried to import the file.

However, a recent update of LTSpice for Mac changed the export format to US-ASCII (or possibly UTF-8). I just looked at a dump of a .ASC file generated by this version, showing the characters and hex together, and it seems the .ASC file is now being written using US-ASCII encoding on Mac as well (with \n line-ends, naturally):

Code: [Select]

od -t x1c VBatt.asc | more
0000000    56  65  72  73  69  6f  6e  20  34  0a  53  48  45  45  54  20
           V   e   r   s   i   o   n       4  \n   S   H   E   E   T   
0000020    31  20  31  31  37  32  20  36  38  30  0a  57  49  52  45  20
           1       1   1   7   2       6   8   0  \n   W   I   R   E   
0000040    2d  38  30  20  2d  36  34  20  2d  33  38  34  20  2d  36  34
           -   8   0       -   6   4       -   3   8   4       -   6   4
0000060    0a  57  49  52  45  20  31  31  32  20  2d  36  34  20  2d  38
          \n   W   I   R   E       1   1   2       -   6   4       -   8
0000100    30  20  2d  36  34  0a  57  49  52  45  20  33  38  34  20  2d
           0       -   6   4  \n   W   I   R   E       3   8   4       -
0000120    36  34  20  31  31  32  20  2d  36  34  0a  57  49  52  45  20
           6   4       1   1   2       -   6   4  \n   W   I   R   E   
0000140    34  38  30  20  2d  36  34  20  33  38  34  20  2d  36  34  0a
           4   8   0       -   6   4       3   8   4       -   6   4  \n
0000160    57  49  52  45  20  2d  33  38  34  20  2d  31  36  20  2d  33
           W   I   R   E       -   3   8   4       -   1   6       -   3
0000200    38  34  20  2d  36  34  0a  57  49  52  45  20  31  31  32  20
           8   4       -   6   4  \n   W   I   R   E       1   1   2   
0000220    2d  31  36  20  31  31  32  20  2d  36  34  0a  57  49  52  45
           -   1   6       1   1   2       -   6   4  \n   W   I   R   E
0000240    20  33  38  34  20  30  20  33  38  34  20  2d  36  34  0a  57
               3   8   4       0       3   8   4       -   6   4  \n   W
0000260    49  52  45  20  2d  38  30  20  39  36  20  2d  38  30  20  2d
           I   R   E       -   8   0       9   6       -   8   0       -
0000300    36  34  0a  57  49  52  45  20  31  37  36  20  31  34  34  20
           6   4  \n   W   I   R   E       1   7   6       1   4   4   
0000320    2d  31  36  20  31  34  34  0a  57  49  52  45  20  33  38  34
           -   1   6       1   4   4  \n   W   I   R   E       3   8   4
0000340    20  31  34  34  20  33  38  34  20  38  30  0a  57  49  52  45
               1   4   4       3   8   4       8   0  \n   W   I   R   E
0000360    20  33  38  34  20  31  34  34  20  32  35  36  20  31  34  34
               3   8   4       1   4   4       2   5   6       1   4   4
0000400    0a  57  49  52  45  20  33  38  34  20  32  35  36  20  33  38
          \n   W   I   R   E       3   8   4       2   5   6       3   8
0000420    34  20  31  34  34  0a  57  49  52  45  20  34  38  30  20  32
           4       1   4   4  \n   W   I   R   E       4   8   0       2

LTSpice identifies itself as 'LTspice XVII for OS X, Build Jul 30 2020, 17:34:47 US Pacific'. I'm not sure if this is the very latest version, but I would suggest downloading the latest and giving it a go. The use of UTF-16 on Mac is probably a relic dating back to before the days of OS X.

[seamusdemora]

No - that won't work.

[seamusdemora]

However, a recent update of LTSpice for Mac changed the export format to US-ASCII (or possibly UTF-8). I just looked at a dump of a .ASC file generated by this version, showing the characters and hex together, and it seems the .ASC file is now being written using US-ASCII encoding on Mac as well (with \n line-ends, naturally):

snip---

LTSpice identifies itself as 'LTspice XVII for OS X, Build Jul 30 2020, 17:34:47 US Pacific'. I'm not sure if this is the very latest version, but I would suggest downloading the latest and giving it a go. The use of UTF-16 on Mac is probably a relic dating back to before the days of OS X.

I'm using an LTspice-Mac build dated Dec 3,2020. On macOS 10.15.6, the .asc files generated by LTspice are still UTF-16 LE. 

[Zero999]

What I meant was, have you tried opening my file on the Mac and copying the data labels to other schematics?

Please post an LTSpice file you created using the Mac version, no formatted data labels or anything, so others can test it using the Windows version.

Have you tried running the Windows LTSpice under WINE?

 

Yes - I did open your file. It renders a proper schematic, and runs perfectly in LTspice-Mac. Then I copied the data label formatting spec ("round...") from your file, and pasted it into an .asc file created by LTspice-Mac. I used (initially) Mac's built-in text editor (TextEdit) to make these changes. Once the edits were made, I re-opened the .asc file in LTspice-Mac to check the result. The result was chaos. By that I mean LTspice-Mac did not render the schematic correctly, and the simulation failed.

That's not what I meant. Try to copy the data labels using LTSpice's schematic editor, by opening my file and the one you want to copy them to side by side. Click on the copy icon on the toolbar and drag and drop. Does that work? I  know it's not much help, if it does, but it would be interesting to see, if the labels are preserved, when copying from one schematic to another.

By the way, all of the files you've posted worked for me using the Windows LTSpice running under WINE. Others have reported issues with the Mac version. Running the Windows version, under WINE might be better, although there are some minor glitches, which are easy to workaround.

[nfmax]

I'm using an LTspice-Mac build dated Dec 3,2020. On macOS 10.15.6, the .asc files generated by LTspice are still UTF-16 LE.

That's weird - I have just downloaded this same version and used it to create a new .ASC file, which was again in US-ASCII encoding. My Mac is running 10.15.7, and the region is set to United Kingdom, but that shouldn't make a difference.

Edit to add: I then added a couple of .OP directives, ran a simulation & saved the file, and this time it was saved in UTF-16 encoding. Deleted the .OP directives, saved again: still in UTF-16. I created another circuit and saved it - the file is in UTF-8. Edited it to add a global label and a SPICE directive (.op) and saved again - and it turned into UTF-16!

OK - found the issue. LTSpice saves the .ASC file in UTF-16 encoding if you use the Save menu command. If you just edit the circuit & run a simulation, without using the menu to save the changes, it auto-saves the circuit in a .ASC file with US-ASCII encoding. If you use the menu Save as... command to save the file, even if you choose the same filename, US-ASCII encoding is used.

Bugs - don't you just love'em?

[seamusdemora]

That's not what I meant. Try to copy the data labels using LTSpice's schematic editor, by opening my file and the one you want to copy them to side by side. Click on the copy icon on the toolbar and drag and drop. Does that work? I  know it's not much help, if it does, but it would be interesting to see, if the labels are preserved, when copying from one schematic to another.

By the way, all of the files you've posted worked for me using the Windows LTSpice running under WINE. Others have reported issues with the Mac version. Running the Windows version, under WINE might be better, although there are some minor glitches, which are easy to workaround.

I tried that, but it didn't work. It's difficult to describe, but once I figured how to "copy" the label, I could not move it outside the window in which I did the copy.

Unfortunately, WINE is reported to have many issues running on macOS Catalina - what version of macOS are you running? I could create a Windows VM, but I'd still have to fuss with a license, etc. Windows is in  my rear view mirror now, and I'd like to keep it that way   In most respects, I think the LTspice-Mac user interface is more difficult - or at least awkward - compared against the Windows interface. But this label business is the only thing I've been unable to do, and if the character-encoding conversion wasn't so awkward I'd be content manually editing the .asc files.

[nfmax]

That's not what I meant. Try to copy the data labels using LTSpice's schematic editor, by opening my file and the one you want to copy them to side by side. Click on the copy icon on the toolbar and drag and drop. Does that work? I  know it's not much help, if it does, but it would be interesting to see, if the labels are preserved, when copying from one schematic to another.

The Mac version of LTSpice does not have a copy icon on the toolbar, and the Copy menu command is greyed out. The way to copy & paste is to use the the right-click menu 'Duplicate' command. This will allow you to select a .op Data Label, but not to paste it into another window. To do that, you have to select the label and the wire to which it is attached.

[Zero999]

That's not what I meant. Try to copy the data labels using LTSpice's schematic editor, by opening my file and the one you want to copy them to side by side. Click on the copy icon on the toolbar and drag and drop. Does that work? I  know it's not much help, if it does, but it would be interesting to see, if the labels are preserved, when copying from one schematic to another.

The Mac version of LTSpice does not have a copy icon on the toolbar, and the Copy menu command is greyed out. The way to copy & paste is to use the the right-click menu 'Duplicate' command. This will allow you to select a .op Data Label, but not to paste it into another window. To do that, you have to select the label and the wire to which it is attached.

That's odd. The right click menu on the Windows version also has the duplicate command, which has the same icon, as the toolbar, which is called copy, according to the tooltip.

That's not what I meant. Try to copy the data labels using LTSpice's schematic editor, by opening my file and the one you want to copy them to side by side. Click on the copy icon on the toolbar and drag and drop. Does that work? I  know it's not much help, if it does, but it would be interesting to see, if the labels are preserved, when copying from one schematic to another.

By the way, all of the files you've posted worked for me using the Windows LTSpice running under WINE. Others have reported issues with the Mac version. Running the Windows version, under WINE might be better, although there are some minor glitches, which are easy to workaround.

I tried that, but it didn't work. It's difficult to describe, but once I figured how to "copy" the label, I could not move it outside the window in which I did the copy.

Did you try clicking on the other window?

Unfortunately, WINE is reported to have many issues running on macOS Catalina - what version of macOS are you running? I could create a Windows VM, but I'd still have to fuss with a license, etc. Windows is in  my rear view mirror now, and I'd like to keep it that way   In most respects, I think the LTspice-Mac user interface is more difficult - or at least awkward - compared against the Windows interface. But this label business is the only thing I've been unable to do, and if the character-encoding conversion wasn't so awkward I'd be content manually editing the .asc files.

[/quote]
If you want to avoid Windows, how about a Linux distribution, running under a VM?

[seamusdemora]

That's odd. The right click menu on the Windows version also has the duplicate command, which has the same icon, as the toolbar, which is called copy, according to the tooltip.

Did you try clicking on the other window?

If you want to avoid Windows, how about a Linux distribution, running under a VM?

Yep, rt-clk->Duplicate (F6) is what I used. It won't move outside the "pane" from where the label was copied.

Yes - I had them tabbed & that didn't work. I opened them in new windows - same result.

Is there a Linux version of LTspice?

[nfmax]

That's odd. The right click menu on the Windows version also has the duplicate command, which has the same icon, as the toolbar, which is called copy, according to the tooltip.

Did you try clicking on the other window?

Yep, rt-clk->Duplicate (F6) is what I used. It won't move outside the "pane" from where the label was copied.

You have to select the whole wire segment to which the .OP is attached - then you can click on another window and place.

[seamusdemora]

You have to select the whole wire segment to which the .OP is attached - then you can click on another window and place.

Yes, well thank you for that, but I think we have wandered off course. Even if I could copy the data label onto another schematic, it's an awkward and inconvenient method. And unless the round format matches what I need, I'm still stuck with manually editing the .asc file.

For now, I'm stuck with the manual edit. Maybe LTspice maintainers will read this thread, and fix it properly. Using UTF-16 encoding when only ASCII characters are required (or even legitimate) sounds like either a kludge, or a mistake.

[nfmax]

So long as you only use Save as... and not Save, it appears the .asc file will be saved with US-ASCII encoding making it possible to edit.

[Zero999]

Is there a Linux version of LTspice?

No, but the Windows version is specifically designed to work under WINE, which is does quite well.

[seamusdemora]

Is there a Linux version of LTspice?

No, but the Windows version is specifically designed to work under WINE, which is does quite well.

 

Yes, but again, from various reports, WINE does not work well with Catalina - which is where I need it to be.

I have found something else that should help:

Code: [Select]

iconv -f 'UCS-2LE' -t 'US-ASCII' '/path/to/your/LTspice-Mac.asc' > '/path/to/your/ASCII-encoded.asc' 

This uses the `iconv` utility to change the encoding from UTF-16 Little Endian to US-ASCII - same encoding as LTspice-Windows.  I'm now thinking that `iconv` coupled with something like `fswatch` could be used to automate the process. I'll post that solution if and when I become motivated enough to build and test it

[nfmax]

I just sent the following bug report to LTspice@analog.com:

Bug report:

When a new circuit is first saved to a .ASC file, or is auto-saved after clicking Run, or is subsequently saved using the ‘Save as…’ menu command, and the textual description of the circuit contains no characters outside the base ASCII set (for example, the Greek letters mu or omega), it is saved in US-ASCII text encoding.

If the same, unmodified, circuit is subsequently saved using the menu ‘Save’ command, or by means of the cmd-S keystroke, the .ASC file is saved in UTF-16LE encoding, with no byte order mark.

In the case where the circuit description contains non ASCII characters - for example in a comment - and all such characters are subsequently deleted from the circuit, the auto-saved file generated by clicking Run will change from UTF-16LE encoding to US-ASCII without warning.

This behaviour makes the (sometimes necessary) use of text editing tools to modify the .ASC file more difficult: the behaviour appeared completely unpredictable to me until I ran some tests. An example where such editing is necessary is when formatting the numbers generated by .op Data Labels (the Mac version of LTSpice lacks the menu command which I understand is present in the Windows version)

A consistent text encoding should be used throughout, ideally UTF-8, although Windows version compatibility may make this impractical

It looks like TextEdit in Catalina is also buggy. It appears to open a .ASC file in UTF-16LE encoding and display it correctly, but if you add additional text anywhere in the file this addition is simply saved (automatically, overwriting the original file without warning!!!) as 8-bit characters, which of course make no sense when interpreted as UTF-16. Only the added text is saved as 8-bit (US-ASCII? UTF-8?), the rest of the file remains UTF-16LE. This is wrong behaviour under any possible interpretation of the text encoding.

If the ASC file contains characters outside the base range (i.e. α character such as Ω, which can be used in comment text) TextEdit does not interpret & display these correctly.

[seamusdemora]

It looks like TextEdit in Catalina is also buggy. It appears to open a .ASC file in UTF-16LE encoding and display it correctly, but if you add additional text anywhere in the file this addition is simply saved (automatically, overwriting the original file without warning!!!) as 8-bit characters, which of course make no sense when interpreted as UTF-16. Only the added text is saved as 8-bit (US-ASCII? UTF-8?), the rest of the file remains UTF-16LE. This is wrong behaviour under any possible interpretation of the text encoding.

If the ASC file contains characters outside the base range (i.e. α character such as Ω, which can be used in comment text) TextEdit does not interpret & display these correctly.

Thanks for submitting the bug report - I submitted one also.  It'll be interesting to see if and how the maintainers respond.

It's a really odd situation - LTspice-Mac will happily run an .ASC file encoded in US-ASCII. In my experiments, the imported US-ASCII .ASC file was never changed to UTF-16LE until I made a change to it using the GUI (that's covered in an earlier post). But your comment has raised my curiosity:

When you added additional text to the .ASC file using TextEdit.app, did you do this by typing it in - or by copying from another file & pasting it in?

[nfmax]

Typing it in - that's why I think it is a TextEdit bug, it's not respecting the encoding of the input file (unless it's just blithely ignoring the \0's it contains)