LTSpice UI

Pspice apparently costs $1500 per month, and that gets you up to 200 hours of run time.

Reply to
John Larkin
Loading thread data ...

I'm not saying anything bad about the PSpice product--it is a nice product, and I used it back around 2000. I doubt I'll ever use the full product again. But that is my point about the stripped down version: my incentives to use it are very low. TI has had 20 years to get on board. They haven't.

I use TI switchers too. I've used very many. But, the mentioned case was for a time sensitive project, not a cost sensitive one. The models and simulator allowed faster and more certain design.

If I'm forking out cash for simulators, I'd probably pay for AWR or simile before a spice simulator. I have a free spice simulator with schematic capture. Actually, I have 4 free ones, but I only use one of them. The incentive to pay for a spice simulator just isn't there for me when there are other productivity products competing for my $.

Reply to
Simon S Aysdie

Nothing to do with the mouse. If it were the mouse, I would see it in every program I use and I would not see it with all the mice I've ever used with LTspice on four machines over the years. The only common element is LTspice. Or maybe it's poltergeist?

I thought Symmetricom made equipment that used the IRIG time code. I believe I used info from their web site back when I initially designed this unit in 2008. Yep, Google finds all sorts of IRIG gear with the name Symmetricom. Seems they were bought by Microsemi since then.

No, there are many tools that have good user interfaces and are easy to pick up again with infrequent use.

Yes, LTspice has many advantages, but the UI is not one of them.

There's no small number of threads in this group that are complaining about something technical, in addition to the many threads that are just complaining about something. That is how we communicate problems and some people are happy to discuss the problems, with the hope of finding a solution. That's what I'm looking for. Are you trying to help?

Reply to
Ricky

LTspice XVII

If you have a group of .params, eg...

.param Rlim 75 .param Clift 10n .param Cbp 180p

...and you right click on one of them on the schematic, edit its value and click 'ok', then nothing happens. Instead, you have to right click, then click 'cancel', then edit from the list and press 'ok'. A bit annoying, but other than that the UI works ok once you've defined your keys to do more 'sensible' things. (M for move, R for rotate, Ctrl-C for copy etc)

Oh - copy and paste on a transformer changes the annotation for the windings, but not for the coupling coefficient.

I've a good mind to ask for a refund.

Reply to
Clive Arthur

Un bel giorno Clive Arthur digitò:

I had that annoying problem too with LTspice XVII, but it seems to be fixed on the new LTspice 17.1.x released this year.

Change log copied from a forum:

  • Transient Frequency Domain Analysis. LTspice 17.1 includes a new frequency response analyzer component and associate .fra spice directive.
  • Frequency domain analysis has been reduced to a single component and directive, greatly simplifying the generation of Bode plots for non-linear circuits, including switched mode power supplies
  • Both loop gain and output impedance are supported by this feature
  • Improved Installation. LTspice library files are stored in users’ %LOCALAPPDATA% directories, instead of My Documents
  • Waveform Viewer. Faster plotting speed for large datasets
  • Keyboard Shortcuts. Keyboard shortcuts can be saved to and loaded from text files
  • Schematic Capture. Numerous schematic editor bugs have been eradicated
  • Simulator Operation
  • Fixed a number of convergence problems
  • Updated initial conditions behavior and documentation to match behavior
  • Reduced multi-threaded CPU loading

Another important feature for me is that you can now specify relative paths for the models by manually editing the .asy simbol files. In this way you can give to anyone a complete package that just works, without the need to manually copy the models in some obscure folder. I think it should have been supported also on XVII in some way, but I've never managed to make it work.

Reply to
dalai lamah

On 2023-03-07 05:54, Clive Arthur wrote:> On 02/03/2023 23:25, Ricky wrote: >> Is there anyone here who thinks LTspice has a good UI? >>

Works fine for me--I just type <enter> when I'm done, and it remembers.

They did make it harder to avoid the specialized edit dialogs in XVII--I just put stuff in multi-line directive groups, e.g.

; SIMULATION COMMAND ; .tran 100u .ac oct 100 10 1g

; PARAMETERS .param Ree 2 .step param Ree list 1 2 5

You double-click on the heading, and a normal OS dialog box comes up that you type into as usual. in wine you have to use <ctrl><enter> to get a new line, not <ctl>M, but that's the only difference I notice.

I generally like XVII--for instance, there are some improvements in dealing with crappy models such as TI's. In early versions, and in IV, the OPA140 model would fail to converge unless the supplies were

-exactly- symmetric, and often not even then.

The current version handles the exact same OPA140 model just fine, probably on account of some workaround for all the sharp corners and discontinuities in the TI model.

Sure, and f5 for "run simulation". Makes it more like Visual Studio. LTspice gets credit for making that pretty easy.

Ain't no such thing as a transformer in my LTspice--dunno about yours. Just individual inductors with coupling coefficients. If you copy and paste, you have to specify the coupling between the two new inductors.

There's no way I can think of to automate that in a useful fashion--do you want it to guess, based on the way the inductors are arranged on the schematic? Not for me, thanks--that's definitely your pistol-shoehorn combination, right there.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

Nice. I'll have to try that out.

A bit better, true. However, it still gets confused doing marching waveforms with stepped parameters.

Yup!

IIRC it works in IV if the symbol is in the current directory, so you can just zip it up with the .asc and .lib files and send it off.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

right-click

Reply to
Phil Hobbs

I put each .param on its own line (not in a text box) and right-click edit works fine.

Does putting them in a box control the order of execution? I can see how that might matter.

Convergence fixes are welcome! I'd like a .sloppy directive to just do a fast sim at reduced accuracy. I don't need a switching supply to be parts-per-trillion accurate.

Reply to
John Larkin
<snip>

Yeah, I guess it would be tricky. I always draw my transformers with the K..... between the windings as if it were the core (it looks kewl!), so copying as one 'box' might give me unrealistic expectations that the coupling annotations should change too.

Another useful thing would be to temporarily lock the scaling on the plot screen, so you can zoom in, lock it, change something and run again. (Or maybe there is a way?)

Reply to
Clive Arthur
<snip>

So it does! It's the OK which doesn't work, thanks.

Reply to
Clive Arthur

Copy and paste preserves node names too, which can create interesting long-distance shorts.

Last time I checked, it still entangles parameters between transient and frequency analysis, hence the need to mess with semicolons to switch sim mode. Version IV switched modes properly.

Reply to
John Larkin
<snip>

Ah yes, forgot that one.

Reply to
Clive Arthur

Ah, okay, it's vitally important to be cooler than your CAD software, for sure. ;)

Agreed--the autoscaling on the plots is fascism at its best. ;)

One approach is to plot not v(out) but min(high, max(low, v(out)) ).

On the X axis you can tell the sim to start storing data at some time t_start instead of t = 0.

A recurring beef of mine is that the plot window code is stupid about units--you have to use (1V/1A) a lot instead of 1ohm, for instance. In noise plots, when inoise is a current, you often you want to check the input-referred noise due to some part on the schematic.

"No worries", you say, "I'll just divide by the built-in variable 'gain'". Then you find that you have two vertical scales, one in A/sqrt(Hz) and the other in V/(ohm sqrt(Hz)). To get one scale, you have to multiply by 'inoise/v(onoise)'.

That's a pain when building TIAs.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

<snip>

Yeah. Of course Diptrace will do that on your circuit board too, and screw up all the board traces besides. :(

(We switched to Kicad 7. It's actually a professional EDA tool now.)

Yup. I used the semicolons in IV as well, though, because the dialog box contents aren't preserved when the program exits.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

No, it implies that I know very little about V17 as mentioned above. If I have not used it how can you ASSUME I know something more about it than I mentioned? Are daft or just practicing to be so? Why are you pressing me for more information than I have? What's wrong with you?

Reply to
John S

That's an old one. And she died in 2007.

Reply to
John S

+100
Reply to
John S

Why is it that you have so much more trouble with it than others? Your attitude, maybe? Are you one of those people who expect everything to be handed to them on the proverbial silver platter? Grow up!

Reply to
John S

I'm with John L on this one. There are lots of times you can get a sample working on a piece of copper clad and learn most of what you need to know.

Reply to
John S

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.