| Electronics > Projects, Designs, and Technical Stuff |
| Spice Limitations? |
| (1/3) > >> |
| Glenn0010:
Hi All, So I've been using LTSpice to simulate switching events in power devices. IGBTs MOSFETs and diodes. I have added an OnSemi IGBT model to the library and simulated it. Sweeping through gate resistors, and currents. One of the main issues I've been facing is getting the darn thing to converge. So a "healthy?" does of parasitic conductors and resistors did the trick. I also used the Alternate solver to get it to converge. Not fully sure what that does tbh. A curious thing is that it would converge for half and the sweeps for example and then fail. Or it would fail for a temp of 125 degrees. So my question is. What are the limitations of this? What is not being shown as it would be in the simulation? Obviously I know that my circuit does not include all the parasitics that would represent a real system. For whoever wants to have look here is my model. IGBT Spice Model Link: https://www.onsemi.com/products/discretes-drivers/igbts/ngtb25n120fl3 |
| Ian.M:
When asking LTspice questions, please post your .asc file + links to any 3rd party symbols and models used. One obvious thing is: you haven't set a source impedance for the pulsed V1. 30 ohms would be 'in the ballpark' for a CMOS gate output. I'd bet its barfing on something internal to the OnSemi IGBT model. 3rd party models are often subcircuits that are optimised for PSpice, or that manufacturer's own SPICE, not LTspice. Sometimes they work well with LTspice, sometimes they are troublesome and occasionally you get one that just wont run under the LTspice engine, either because of incompatible syntax, or it stalls or even crashes it. The best way forward is to reconstruct the schematic of the subcircuit from its netlist so you can see what's there and what needs tweaking, then tweak as required. |
| Glenn0010:
--- Quote from: Ian.M on September 05, 2019, 08:27:03 am ---When asking LTspice questions, please post your .asc file + links to any 3rd party symbols and models used. One obvious thing is: you haven't set a source impedance for the pulsed V1. 30 ohms would be 'in the ballpark' for a CMOS gate output. I'd bet its barfing on something internal to the OnSemi IGBT model. 3rd party models are often subcircuits that are optimised for PSpice, or that manufacturer's own SPICE, not LTspice. Sometimes they work well with LTspice, sometimes they are troublesome and occasionally you get one that just wont run under the LTspice engine, either because of incompatible syntax, or it stalls or even crashes it. The best way forward is to reconstruct the schematic of the subcircuit from its netlist so you can see what's there and what needs tweaking, then tweak as required. --- End quote --- I've added the .asc file and the link to the model. It is from the OnSemi website and they have a model that is done specifically for LTSpice on there. With regards to the convergence it was mainly getting stuck with the IGBTs as you said. Either the diode of the IGBT or the IGBT itself. |
| T3sl4co1l:
Who fkn knows, it's an encrypted blob, all three versions. I'm sure there are fairly simple ways of decrypting SPICE models (runtime memory inspection perhaps?), but I haven't seen any posts on it so you're probably on your own unfortunately. The usual things are bad functions (poles or discontinuities, and sometimes even just exponential and hyperbolic functions), and simulation settings that need to be tweaked for the device or circuit. SPICE defaults are fine for general analog work, but not very good for switching circuits; LTSpice changes a number of these already, but gets rid of a lot too, so even if you're using "alternate" (actually the original solver, trapezoidal integration (or higher order Runge–Kutta methods ("GEAR" of specified order); LT's default solver is an approximate hack that is a lot faster in switching circuits, but misses a lot, too), you might not be able to set all the parameters you need to. Tim |
| Ian.M:
Cracking LTspice model encryption is *NOT* something we can safely discuss here. L.T. (now Analog Devices) historically have been tough on anyone disclosing what they regard as proprietary data, and it would not be fair to bring that level of legal scrutiny down on our host Dave's neck! @Anyone: If this offends your belief in a right to free speech, are you willing to put your money where your mouth is and provide Dave with a large enough legal defence fund to go up against A.D's corporate legal team? @Glenn, Therefore the only legal way forward to get insight into the OnSemi model internals is to work with OnSemi's product support team. First try any test jigs they show in the datasheet and if any of them have similar sim issues, send them the .asc file and ask what you are doing wrong. If their test jigs sim O.K. try simplifying your circuit until you get a minimal one that has the problem, then submit that to them for comment. If you have any personal contacts at OnSemi reach out to them for how to escalate to whoever actually writes the models. Also you could try begging for an unencrypted model, hopefully not under a NDA so you are free to discuss it here. Unfortunately the link you provided was to models and symbols for NGTB25N120FL3WG, not the NGTB25N120S in your 'Draft6.asc' sim. I've just found the latter here: https://www.onsemi.com/products/discretes-drivers/igbts/NGTB25N120S I'll give it a try later today and see if I can reproduce your problem and find any workarounds. So far, I have noticed that the .ic command for L1 current isn't being applied (no uic option in the .tran command) and also has an inappropriate space between the I and the (. Also if you want that current to actually 'take' you need to set it as an initial condition for *ALL* the inductors in the loop it will be flowing through via the U2 body diode before U1 first switches on. Its possible that issues with the model's internal diode could be 'patched' by adding a suitable external diode in parallel. General LTspice hints: Multiple SPICE dot commands can be placed as a single item on the schematic. Ctrl-Enter starts a new line in the dot command edit dialog, and it also accepts blocks of text complete with line endings copy/pasted from external text editors etc. This is particularly useful for stuff that should be kept together e.g. multiple .measure or .option commands, that you can then enable or comment out as a block Also, with a very slow or glitchy sim, you may well want to move your .measure statements to a separate file and .include it rather than putting them directly on the schematic, as then you can edit and re-run them by File:Execute .MEAS script with the waveform subwindow in focus without having to rerun the sim. |
| Navigation |
| Message Index |
| Next page |