No problem reading the LTSPICE <standard.mos>
directly on console… runs perfectly…
can choose ANY VDMOS or MOS defined device…
works great!!!
Paul
I have the first issue with a standard SPICE3 draft.
This examples runs fine WITHOUT PSPICE compat.
But WITH compat ennabled it generates the following error:
Error on line 308 :
as1 %vd(vsw 0 ) %gd(q1c 0 ) arelaysw
MIF-ERROR - unable to find definition of model arelaysw
From spice source
Paul
A bug fix is uploaded to the ngspice master branch
Holger
1 Like
Another update to the ngspice master branch (and the MS Windows executables for download):
things became too complex, so there is now a re-write of the vswitch transformation code, dealing with multiple models within subcircuits and top level, and instances calling the models, in a mix of standard ngspice switches and PSPICE vswitches.
Holger
For the sake of organizing the results …
- What version should I keep my tests with?
- pre-master9 ? master ? or else …
Paul
Please move on with the ‘master’ branch.
Holger
1 Like
OK some more test results…
Here is a thing:
- regarding latest changes in <src/frontend/inpcom.c>
- traced a segfault that boils down to MODEL VSWITCH
- Just that part - all other changes are fine
- Note the detail - IT IS NOT a recursive .include directive
- SEGFAULT when finding a VSWITCH model included from other source
Explained:
- MASTER <*cir> file (eg analysis) includes a SLAVE <*cir>
- SLAVE <*cir> defines models and sources (including VSWITCH)
- RESULT SEGFAULTS
Now single file does not include any file w/VSWITCH
- MASTER <*cir> file (eg analysis) is single includes all sources
- but STILL INCLUDES OTHERS WITHOUT VSWITCH models
- RESULT WORKS PERFECT even including VSWITCH model - perfect
Could not figure out a PATCH without removing the bottom part
of function pspice_compat
Reverting that part to the lastest pre9 works fine
but that previous error is still there.
Paul
Some fancy shots may help
This is a typical BOOST where multiple analysis are run from a single
definition source. The source includes a VSWITCH model
Modes vary wide in params to cover from BCM to DCM/CCM modes
as well as various thermal loop and feedback stability control runs
here the shot
Paul
Do you have a (simplified) input file for me that seg-faults?
Holger
To find this problem I have spent last 3 days combining several of the master sources to figure out WHY
- a simple single source file IS PERFECT
- while a source with multiple included files some are fine some not
Reason being is that - the latest change to correct VSWITCH in
pspice_compat is affected - but just that bottom part of the function
When you include VSWITCH in another source
- which will be included - you got the fault.
The simple shots I have posted are the result of 3 days
of trial and error to find that.
Inclusion of VSWITCH model outwards a source file
If you include the VSWITCH model right in the master source
the PATCH you have made is WORKING PERFECT.
SAME FILE COMBINATIONS 100% equal
just by including the VSWITCH model
from outside the master source is causing this
and whatever I have tried…
it boils down to this fact on pspice_compat function latest fix of VSWITCH.
As you said - it is not trivial to consider that much level of handles
in that function
You may try this very simple approach for example
a real part of the far more complex sources I have passed…
* MASTER
V1 Vin GND DC 5
V2 Vsw GND DC 0 PULSE(0 5 0 0 0 97.22u 166.7u)
.include 'SLAVE.cir'
.control
run
.endc
.end
* SLAVE
.include '/share/spice/whatever...'
.model relaysw SW(Ron=10m Roff=1G) ; Vt=threshold Vh=hysteresis
It should be able to reproduce a traceable guide to this fault
Paul
Paul,
if I type your files as they are, nothing happens…
Basically the ngspice option is made to include device libraries with PSPICE syntax.
In these device libraries all .model lines (e.g. .model myswitch vswitch(…) ) and the corresponding instance lines (e.g. smyswitch 1 2 3 4 myswitch) have to be contained in a single file that is then loaded by .include. It is not intended that one .include contains the .model line of the vswitch (we are not talkng about the sw switch!) and the other .include contains the corresponding instance s…, it is also not possible to have the .model line on the top level and the instance s… in the .include.
Still it should not seg-fault, whatever you try. So could you add some lines to make your example complete (immediately runnable)?
Holger
I may try but obviously results may not be the same
This thing is complicated.
I have a bunch of scripts that will run inside the control loop
compute deviations and mostly stuff to FFT as I am interested
in harmonics and drift.
I have cut almost 90% of the stuff…
BUT STILL SEGFAULTS with just those silly lines…
* MASTER
V1 Vin GND DC 5
V2 Vsw GND DC 0 PULSE(0 5 0 0 0 97.22u 166.7u)
.include 'SLAVE.cir'
.options method=gear reltol=1m NOPAGE NOACCT NOINIT
.tran 10n 15m 0 uic
.control
run
plot v(Vout) v(Vsw) l1#branch
.endc
.end
* SLAVE
.include '/share/spice/cmp/MINE/MINE.dio'
.include '/share/spice/cmp/MINE/MINE.bjt'
.model relaysw SW(Ron=10m Roff=1G)
S1 Q1c GND Vsw GND relaysw
L1 Vin Q1c 23.85u
D1 Q1c Vout 1N4007
C1 Vout GND 231u
Rx Vout GND 2.4
I can not change my included files I have no option to those.
But my guess is that it won’t matter
** IF IT DOES MATTER**
tell me so I can pass again other combinations
it requires just this to segfault.
Paul
And BTW running that same crappy MASTER/SLAVE
above under the “REGULAR” SPICE3F ONLY
version (aka the ngspice - version27)
the thing is fine
should produce something like this
Paul
To form a complete panorama
I managed to have the 3 versions running on my Workstation
- regular ngspice27
- premaster9
- master
This is the result of pre-master9 running the same crappy
MASTER/SLAVE …
It is obviously WRONG but at least the fault is not there.
with this included model
Paul
Bug is identified, a fix is under way to master.
Done!
1 Like
Great…
I forgot to put available the diode model used in this draft
but my guess is that it won’t matter for this case
.model 1N4007 D (
+ IS=7.02767e-09 N=1.80803 RS=0.0341512
+ EG=1.05743 XTI=5
+ CJO=1e-11 VJ=0.7 M=0.5 FC=0.5
+ TT=1e-07 BV=1000 IBV=5e-08 KF=0 AF=1)
Paul
Paul,
any bugs left?
If not, I will start preparing the new ngspice release.
Holger
1 Like
too soon to have that sure
But IMHO things are pretty close to consider a MAJOR release
It has nothing to do with the old one.
Any bug found will be a MINOR fix.
Every run in my system is very time consuming
and space as well. Data is dump in several files to post process.
That simple BOOST when closed loop will produce a roughly 2G
of data to plot after several minutes tweaking data.
Front end result looks like this
so eventually one of the runs may find some issue not seen so far.
If the last one BUG is closed
i think it is good to go.
Paul
and by the way…
THE SHOT ABOVE WAS MADE USING THE LATEST FIX
using that very same included master/slave sources
but this time complete with all gizmos
got to the filled FFT vectors to the point WITHOUT a GLITCH
so far so good
Paul
The following patch will allow proper recognition of VDMOS
as a VALID MODEL TYPE in spice dialog list
Very simple fix needed
Working fine so far against this week latest GIT synch
--- ./eeschema/dialogs/dialog_spice_model.cpp.orig 2018-06-17 08:27:37.000000000 +0000
+++ ./eeschema/dialogs/dialog_spice_model.cpp 2018-06-17 08:19:59.000000000 +0000
@@ -786,7 +786,7 @@ DIALOG_SPICE_MODEL::MODEL::TYPE DIALOG_S
if( val.StartsWith( "npn" ) || val.StartsWith( "pnp" ) )
return BJT;
- else if( val.StartsWith( "nmos" ) || val.StartsWith( "pmos" ) )
+ else if( val.StartsWith( "nmos" ) || val.StartsWith( "pmos" ) || val.StartsWith( "vdmos" ) )
return MOSFET;
else if( val[0] == 'd' )
return DIODE;
kicad_dialog_spice_model.patch.gz (296 Bytes)
Paul
1 Like