What are you referring to?

Post #10, which is where the original error message for the simulation for this part was displayed. The symbol in the schematic is clearly a MOSFET symbol and the error message suggested the model was for some species of JFET. IMHO it looked strange, but probably had a rational explanation of which I was unaware. I fully admit that I am unfamiliar with these parts and had no a priori knowledge of what might be wrong, except for the speculation that the model might be the victim rather than the culprit.

 

Move the load.
Don't use UIC. (i dont know how many times I have to say that)
Use the OnSemi LTspice symbol

View attachment 242565

I was trying everything and I forgot the uic there.
I was using the OnSemi LTspice symbol.

I moved the load even though I did not know why I should do that but it still does not work for me. You have selected different MOSFET but it does not work either.

 

This is unexpected, and I'm tempted to ask what are the configurations of the machines running the simulation?

 

This is unexpected, and I'm tempted to ask what are the configurations of the machines running the simulation?

It is Dell 7577 Intel i7 7700HQ 16 GB RAM and GTX 1060 MAX Q. I don't know if it has anything to do with gpu but still..

 

hi beleg,
Post your latest LTS documents etc and I will do a compare run of the sim.
E

 

Post #10, which is where the original error message for the simulation for this part was displayed. The symbol in the schematic is clearly a MOSFET symbol and the error message suggested the model was for some species of JFET. IMHO it looked strange, but probably had a rational explanation of which I was unaware. I fully admit that I am unfamiliar with these parts and had no a priori knowledge of what might be wrong, except for the speculation that the model might be the victim rather than the culprit.

Sometimes the graphic matches a mosfet but the pin order may be different. That could cause issues.
If OnSemi was nice, and since the file is encrypted, they could have placed a comment in the model file showing the pin assignments. Of course, I could have found all that out and made my own, but it was easier to just use their symbol.

Regarding the error, could be there are multiple model files stomping on each other.

 

I was trying everything and I forgot the uic there.
I was using the OnSemi LTspice symbol.
View attachment 242576
I moved the load even though I did not know why I should do that but it still does not work for me. You have selected different MOSFET but it does not work either.
View attachment 242575

I tried both models and both worked fine.

Run the simulation, then post the .log file for us to review.

 

It is Dell 7577 Intel i7 7700HQ 16 GB RAM and GTX 1060 MAX Q. I don't know if it has anything to do with gpu but still..

I don't think so...

 

I don't think so...

It remains a mystery for the moment. I think that system has plenty of resources
Only other thing that might be worth looking at besides the Spice Error Log is the LTspice ".ini" file which is located in \Users\%Username%\AppData\Roaming

 

It remains a mystery for the moment. I think that system has plenty of resources
Only other thing that might be worth looking at besides the Spice Error Log is the LTspice ".ini" file which is located in \Users\%Username%\AppData\Roaming

Um...no...."Timestep too small" errors are not HW related. They are spice SW convergence (calculation) errors.
Although, I have seen bad characters in model files that have caused these errors.

One thing to try is:
1. Exit LTspice
2. Rename the LTspiceXVII.ini file to something like LTspiceXVII_ini.txt.
3. Launch LTspiceXVII.

LTspice will re-create the .ini file with defaults. Then try the simulation and see if there are errors.

 

Um...no...."Timestep too small" errors are not HW related. They are spice SW convergence (calculation) errors.
Although, I have seen bad characters in model files that have caused these errors.

One thing to try is:
1. Exit LTspice
2. Rename the LTspiceXVII.ini file to something like LTspiceXVII_ini.txt.
3. Launch LTspiceXVII.

LTspice will re-create the .ini file with defaults. Then try the simulation and see if there are errors.

Excellent hypothesis - I hope the results are illuminating.
Edit: I was thinking that the .raw files for this simulation might be pushing a boundary, but I've never actually seen that be the cause of a problem.

 

For some reason I could not replicate the error from the

Um...no...."Timestep too small" errors are not HW related. They are spice SW convergence (calculation) errors.
Although, I have seen bad characters in model files that have caused these errors.

One thing to try is:
1. Exit LTspice
2. Rename the LTspiceXVII.ini file to something like LTspiceXVII_ini.txt.
3. Launch LTspiceXVII.

LTspice will re-create the .ini file with defaults. Then try the simulation and see if there are errors.

I exited and relaunched the LTspice and right now I got the same results as you. I was able to finish the 10ms. However, the convergence problem is still there. Even though I got no error during the simulation you can see the log file and there are a lot of "Heightened Def Con" messages. I think I would get errors again if I put this MOSFET in a bit more complex power converter. You can see it in the attachment.

Do you have such messages in your log file? If not can you share your .asc file?

 

For some reason I could not replicate the error from the

I exited and relaunched the LTspice and right now I got the same results as you. I was able to finish the 10ms. However, the convergence problem is still there. Even though I got no error during the simulation you can see the log file and there are a lot of "Heightened Def Con" messages. I think I would get errors again if I put this MOSFET in a bit more complex power converter. You can see it in the attachment.

Do you have such messages in your log file? If not can you share your .asc file?

The simulation is converging or it wouldn't complete. The Defcon Messages usually mean the V/I relationships somewhere are not correct. An example would be where a mosfet load is applied that draws 10 AMPs but the mosfet is designed to support a load of 1A. The encrypted model make this difficult to troubleshoot.

Place this directive on your schematic:

.opt ABSTOL=1e-10

Most of the Defcon messages will disappear.

 

The simulation is converging or it wouldn't complete. The Defcon Messages usually mean the V/I relationships somewhere are not correct. An example would be where a mosfet load is applied that draws 10 AMPs but the mosfet is designed to support a load of 1A. The encrypted model make this difficult to troubleshoot.

Place this directive on your schematic:

.opt ABSTOL=1e-10

Most of the Defcon messages will disappear.

I did the exactly the same simulation but for 20ms for this time and there is this "time step too small error" again. I agree this methods definitely helps but the solution does not scale and if I set the abstol to 1e-10 it definitely gets rid of the earlier defcon messages but also time step too small error occurs in the second defcon message. You can observe this in the attached log file.

I think at this point the model seems too unreliable to use in some complex converter. There is this contact info on top of the model file. I will contact them and I will write here if anything comes up. In my opinion this would be the best way to continue.

 

I did the exactly the same simulation but for 20ms for this time and there is this "time step too small error" again. I agree this methods definitely helps but the solution does not scale and if I set the abstol to 1e-10 it definitely gets rid of the earlier defcon messages but also time step too small error occurs in the second defcon message. You can observe this in the attached log file.

I think at this point the model seems too unreliable to use in some complex converter. There is this contact info on top of the model file. I will contact them and I will write here if anything comes up. In my opinion this would be the best way to continue.

I noticed you change the rise/fall time of V2. That seems to cause the timestep errors. If I add a parallel capacitance (1nf) at the gate of the mosfet (I'm actually specifying it as V2 parallel capacitance) the timestep error goes away. Defcon errors still occur though.

It's good you contact them. May they can tell you how to use their models properly.

 

Use .opt trtol=0.1 ABSTOL=1n

 

See

 

See
View attachment 242611

This seems rather promising. There were some defcon messages and I have introduced series resistance to C1 and C2 and that seems to be helping even further. Right now even though it is slow there are no messages or error whatsoever. I am no expert but set tolerances seems to be okay for my application or maybe I am interpreting them wrong.