Formatting .op Data Labels in LTspice for Mac  - Page 1
Forum section: electronics / projects

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 03, 2020, 07:14:55 am
content: 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.

author: Zero999
author_rank: Super Contributor
timestamp: December 03, 2020, 09:59:32 am
content: Use the round function.Quotehttp://ltwiki.org/index.php?title=Undocumented_LTspice#Operating_Point_Data_Labels_.28visible_numeric_dc_bias_values.29

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 03, 2020, 08:00:15 pm
content: Quote from: Zero999 on December 03, 2020, 09:59:32 amThanks, 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) IDO NOTget a dialog. I suspect this is because I'm using theMac versionof LTspice?? I've downloaded the example, and was surprised to see the formatting/roundingis workingas 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?

author: Zero999
author_rank: Super Contributor
timestamp: December 03, 2020, 10:15:40 pm
content: 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.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 04, 2020, 02:01:09 am
content: Quote from: Zero999 on December 03, 2020, 10:15:40 pmThere 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

author: Zero999
author_rank: Super Contributor
timestamp: December 05, 2020, 10:54:35 am
content: 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?

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 06, 2020, 08:21:34 am
content: Quote from: Zero999 on December 05, 2020, 10:54:35 amYes - I did open your file. It renders a proper schematic, and runs perfectly inLTspice-Mac. Then I copied the data label formatting spec ("round...") from your file, and pasted it into an .asc filecreatedbyLTspice-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 inLTspice-Macto check the result. The result was chaos. By that I meanLTspice-Macdid 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 usingcharset=us-asciiencoding; this, according to running the Mac's CLI `file -I` command on your .asc file2. LTspice-Mac generates .asc files usingUTF-16 Little-Endianencoding; this according to a trial-and-error process with different formats in theBBeditapp on MacOS. In a fine example of Apple's attention to detail, the `file -I` command for an .asc file generated byLTspice-Macreports its file encoding ascharset=binary.3. Apple's built-in text editor (TextEdit), rendersUTF-16 LEin the same way it rendersus-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 toLTspice-Macgenerated .asc files when viewed inTextEdit. 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 yourus-ascii.asc file, and then pasted into myUTF-16 LE.asc file is pastedliterally- a bit like "mixing apples and oranges" I suppose. I wind up with a hybrid file containing bothUTF-16 LEandus-asciicharacters in the same file.For now, my only solution ismanual interventionusingBBeditto convertUTF-16 LE.asc files generated by LTspice-Mac tous-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-Macwill happily process and run .asc files withus-asciiencoding generated by LTspice-Windows.2. If any changes are made to aus-ascii.asc file using theLTspice-MacGUI, theus-ascii.asc file is changed toUTF-16 LE2. 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 theHelp, About menuto email a bug report. Unfortunately, that option is not available inLTspice-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??

author: Ian.M
author_rank: Super Contributor
timestamp: December 06, 2020, 08:56:04 am
content: 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.

author: nfmax
author_rank: Super Contributor
timestamp: December 06, 2020, 09:51:24 am
content: 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:od -t x1c VBatt.asc | more0000000 56 65 72 73 69 6f 6e 20 34 0a 53 48 45 45 54 20V e r s i o n 4 \n S H E E T0000020 31 20 31 31 37 32 20 36 38 30 0a 57 49 52 45 201 1 1 7 2 6 8 0 \n W I R E0000040 2d 38 30 20 2d 36 34 20 2d 33 38 34 20 2d 36 34- 8 0 - 6 4 - 3 8 4 - 6 40000060 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 - 80000100 30 20 2d 36 34 0a 57 49 52 45 20 33 38 34 20 2d0 - 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 206 4 1 1 2 - 6 4 \n W I R E0000140 34 38 30 20 2d 36 34 20 33 38 34 20 2d 36 34 0a4 8 0 - 6 4 3 8 4 - 6 4 \n0000160 57 49 52 45 20 2d 33 38 34 20 2d 31 36 20 2d 33W I R E - 3 8 4 - 1 6 - 30000200 38 34 20 2d 36 34 0a 57 49 52 45 20 31 31 32 208 4 - 6 4 \n W I R E 1 1 20000220 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 E0000240 20 33 38 34 20 30 20 33 38 34 20 2d 36 34 0a 573 8 4 0 3 8 4 - 6 4 \n W0000260 49 52 45 20 2d 38 30 20 39 36 20 2d 38 30 20 2dI R E - 8 0 9 6 - 8 0 -0000300 36 34 0a 57 49 52 45 20 31 37 36 20 31 34 34 206 4 \n W I R E 1 7 6 1 4 40000320 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 40000340 20 31 34 34 20 33 38 34 20 38 30 0a 57 49 52 451 4 4 3 8 4 8 0 \n W I R E0000360 20 33 38 34 20 31 34 34 20 32 35 36 20 31 34 343 8 4 1 4 4 2 5 6 1 4 40000400 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 80000420 34 20 31 34 34 0a 57 49 52 45 20 34 38 30 20 324 1 4 4 \n W I R E 4 8 0 2LTSpice 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.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 06, 2020, 10:12:23 am
content: No - that won't work.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 06, 2020, 10:20:29 am
content: Quote from: nfmax on December 06, 2020, 09:51:24 amI'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.

author: Zero999
author_rank: Super Contributor
timestamp: December 06, 2020, 10:31:14 am
content: Quote from: seamusdemora on December 06, 2020, 08:21:34 amThat'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.

author: nfmax
author_rank: Super Contributor
timestamp: December 06, 2020, 10:35:40 am
content: Quote from: seamusdemora on December 06, 2020, 10:20:29 amThat'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?

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 06, 2020, 10:58:39 am
content: Quote from: Zero999 on December 06, 2020, 10:31:14 amI 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 wayIn 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.

author: nfmax
author_rank: Super Contributor
timestamp: December 06, 2020, 11:04:44 am
content: Quote from: Zero999 on December 06, 2020, 10:31:14 amThe 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.

author: Zero999
author_rank: Super Contributor
timestamp: December 06, 2020, 11:17:17 am
content: Quote from: nfmax on December 06, 2020, 11:04:44 amThat'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.Quote from: seamusdemora on December 06, 2020, 10:58:39 amDid you try clicking on the other window?QuoteIf you want to avoid Windows, how about a Linux distribution, running under a VM?

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 06, 2020, 11:30:29 am
content: Quote from: Zero999 on December 06, 2020, 11:17:17 amYep, 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?

author: nfmax
author_rank: Super Contributor
timestamp: December 06, 2020, 11:58:33 am
content: Quote from: seamusdemora on December 06, 2020, 11:30:29 amYou have to select thewhole wire segmentto which the .OP is attached - then you can click on another window and place.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 06, 2020, 09:37:20 pm
content: Quote from: nfmax on December 06, 2020, 11:58:33 amYes, 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.

author: nfmax
author_rank: Super Contributor
timestamp: December 06, 2020, 10:00:00 pm
content: 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.

author: Zero999
author_rank: Super Contributor
timestamp: December 06, 2020, 10:15:12 pm
content: Quote from: seamusdemora on December 06, 2020, 11:30:29 amNo, but the Windows version is specifically designed to work under WINE, which is does quite well.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 07, 2020, 02:17:51 am
content: Quote from: Zero999 on December 06, 2020, 10:15:12 pmYes, 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: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 fromUTF-16 Little EndiantoUS-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

author: nfmax
author_rank: Super Contributor
timestamp: December 07, 2020, 09:28:13 am
content: I just sent the following bug report to LTspice@analog.com:QuoteIt 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.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 07, 2020, 09:44:56 am
content: Quote from: nfmax on December 07, 2020, 09:28:13 amThanks 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?

author: nfmax
author_rank: Super Contributor
timestamp: December 07, 2020, 09:49:05 am
content: 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)

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 07, 2020, 10:05:42 am
content: Quote from: nfmax on December 07, 2020, 09:49:05 amI would have guessed thatTextEdit.appwould respect the character encoding, but perhaps not. What was thePlain Text Encodingdrop-down menu setting (bottom of theTextEdit.appwindow)?

author: nfmax
author_rank: Super Contributor
timestamp: December 07, 2020, 10:14:18 am
content: Odd, I don't have any such drop-down menu, the text edit area goes right to the bottom of the window. In preferences, input & output encodings are set to Automatic. TextEdit identifies itself as Version 1.15 (355)

author: nfmax
author_rank: Super Contributor
timestamp: December 07, 2020, 03:13:32 pm
content: Quote from: nfmax on December 07, 2020, 09:28:13 amAnd AD responded (or at least some email script did)Quote

author: Zero999
author_rank: Super Contributor
timestamp: December 07, 2020, 05:46:11 pm
content: Quote from: seamusdemora on December 07, 2020, 02:17:51 amHave you tried it youself? I assumed you had, which is why I suggested a Linux VM running LTSpice under WINE. It's clunky but at least you don't need Windows.

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 07, 2020, 09:03:32 pm
content: Quote from: nfmax on December 07, 2020, 09:49:05 amTheTextEditapp has a dialog that provides options for text encoding - options that are available for "open" and for "save as..." are a bit different, but are present in both cases - see the attached figures for clarification. You may have to click the "Options" button to see this dialog/drop-down. I wonder if this could be part of the problem?

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 10, 2020, 03:14:30 am
content: I submitted a "bug report" of sorts to AD on this issue last week. Yesterday, I received a reply from. He said, in summary:He confirmed the problem, and notified the "design team", andIt might take a while to resolve the issueHe was speaking of the inability for users to create a "round" directive in LTspice-Mac. He did not mention the issue w/ the odd character-encoding scheme used in LTspice-Mac?!That's all I know. If I hear anything else, I'll post it here.~S

author: nfmax
author_rank: Super Contributor
timestamp: December 10, 2020, 08:27:49 am
content: An AD application engineer has also acknowledged my bug report, on the text encoding problem:Quote

author: seamusdemora
author_rank: Regular Contributor
timestamp: December 10, 2020, 08:33:08 am
content: Cool... let's revisit this one year from today - hopefully it will be corrected.

author: nbenm
author_rank: Newbie
timestamp: July 16, 2023, 08:35:41 am
content: Quote from: seamusdemora on December 07, 2020, 09:49:05 amSadly two years and half after, it's still not.