LTspice XVII

Looks a quick fix? All ready an update append on Dec 8th 16. ? I might just be looking into something that's not quite accurate.

GromTag said:

Looks a quick fix? All ready an update append on Dec 8th 16. ? I might just be looking into something that's not quite accurate.

Click to expand...

Update: This version seems stable, multiple start and stop during simulations, downsize and resize of window during sim run, and small to large circuit types run including frequency ranges and basic switching for tuned schematics TTL.
As for Spice statements for other function operations (.op Commands) unknown for their stability as I mostly use model and value statements only. SW, behavioral Schmitt triggers, Vhigh= Vlow, ect.

Well after some time and models ran, the program is back to the occasional schematic capture crash, even the run as and compatibility selects, run in Vista compat gave the better stability. Overall there should be no real need to run in any compatibility whatsoever for a program such as this to run properly.

It crashes for me too - when the simulation results file opens (Windows 7). Running it XP compatibility mode fixed it. Weird . . .

Installed the latest XVII update a couple of days ago (Feb 15th) - big mistake - now it crashes ("stopped working") every single time that it's run.

Hi,

Did anyone notice if the new version runs simulations any faster than the old version?

I've been using XVII at work for the past month or so. I don't notice much of a difference between IV and XVII, other than the fact that XVII appears more vibrant (thicker wires, maybe? Brigher colors? Can't put my finger on it), and sometimes it doesn't complain if you forget to put in a ground symbol. It still seems a bit buggy to me though, and has some of the same bugs as IV (if you delete a node that you're probing, you get ridiculous numbers often in the tens of kilovolts range).

At this point I think I could use IV and XVII interchangeably -- there is no real functional difference between them, at least not in my experience. Most of the changes were just the platforms they run on.

DerStrom8 said:

I've been using XVII at work for the past month or so. I don't notice much of a difference between IV and XVII, other than the fact that XVII appears more vibrant (thicker wires, maybe? Brigher colors? Can't put my finger on it), and sometimes it doesn't complain if you forget to put in a ground symbol. It still seems a bit buggy to me though, and has some of the same bugs as IV (if you delete a node that you're probing, you get ridiculous numbers often in the tens of kilovolts range).

At this point I think I could use IV and XVII interchangeably -- there is no real functional difference between them, at least not in my experience. Most of the changes were just the platforms they run on.

Click to expand...

Hi,

That's interesting, so i guess i have not been missing much.

One of the things that i did not like about the older version was that the color pallet for the wave graphics was very limited so there were not that many choices for the colors you can show the wave in. In Windows we have 16 million colors and a built in color selection dialog box (via the Windows API which had been around since the days of Windows 95) so it puzzled me why they would literally tone that down.

Does the new version allow more color choices, or did i miss the way to alter this in the old version?

MrAl said:

Does the new version allow more color choices, or did i miss the way to alter this in the old version?

Click to expand...

You missed it. It's the same in both versions. Go to Tools/Color preferences and you get a pop-up with sliders (0-255) for each of R,G,B.

Hi Alec,

Thanks for the tip. I was able to change the dark blue to something i can actually see on my monitor now

My only question left then is why they did not use the common controls library that comes as part of the Windows operating system. It's used to create the dialog usually referred to as the "Choose Color" dialog box. It has a user interface that provides the user with an intuitive color plate that allows changing brightness, color saturation, etc.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms646375(v=vs.85).aspx

That's what i use in all my Windows programs because that way i dont have to write any code for it really, just call the function and let Windows handle the user responses, then read the return value as that will be the color the user chose.

So it looks like they used their time to write their own dialog box, and it's not as intuitive. However, at least we have some way to handle the colors so that's good
I can open up another program with the color dialog box and choose the color there, then repeat the color component selection in LT Spice and get the color i was after, or just settle for whatever i can get using their custom dialog box.

MrAl said:

My only question left then is why they did not use the common controls library that comes as part of the Windows operating system.

Click to expand...

Perhaps because they wanted in-house source code re-usable for different operating systems?

alec_t said:

Perhaps because they wanted in-house source code re-usable for different operating systems?

Click to expand...

Hi,

That's a possibility, but if their dialog box was set up in a manner similar to the way Windows does it, then they could just opt out and opt in depending on which op sys they are compiling for. That way they could use the nicer Windows interface.

Note it is rare for me to say "the nicer Windows interface" because usually the Windows interface for something is lacking, and sometimes we dont know it until some time after we create the program. The color dialog part of common controls though i dont think is one of them.
For an example of one that is lacking, the Listview control seems like such a nice interface that gives us a lot of functionality for a program that needs to display a list to the user and allow changing various things about that list and selecting items and such. But for a large number of objects in the list the interface is very slow to load. For one of my programs it takes about 3 or 4 seconds to load just 2000 items, which is not a lot of items for some programs as we could easily need more. I had to switch to a custom list interface that did not use any common controls in order to get a decent load time at program startup. That took several hours to create and not all in one day. The color dialog works pretty well though so i never had to change that.