EAGLE Netlist conversion

[Ian]

Mathias

I'm sorry I can't help you with your enquiry but I do want to give you some
encouragement! I am a long time user of Orcad SDT 3.22 and would love to use
it a higher screen resolutions than the 640x480 that I've had for 15 years
and the 800x600 that I got this week!

Is the schematic part of Orcad 386 the same as SDT 3? and do they use the
same drivers?

Best wishes

Ian Phillips



"Matthias Hartl" <maze@altmuehlnet.de> wrote in message
news:bgas28$bev$02$1@news.t-online.com...

Hello,

Does anyone know, if OrCAD has ever released a sample video driver source
code for their old OrCAD 386 series? I'm currently trying to write a new
video driver which fully complies to the VESA 1.2+ standard. Therefore
I've
"investigated" one of their drivers, called VESA1024.DRV. After many hours
of work, I already managed to fix a few bugs, so that the screen doesn't
get
distorted when moving the mouse or when a new menu pops up, but going any
further than that is very difficult. I wanted to rewrite the whole driver,
but due to lack of missing documentation I still don't fully understand
interaction between the driver and the program. ANY kind of help would be
appreciated! I already have a mixture of assembler and c source codes I'm
willing to share. They do compile and produce a working video driver.

With kind regards,
Matthias Hartl

 

[Matthias Hartl]

Hello Ian,

Is the schematic part of Orcad 386 the same as SDT 3?

As far as I know they're completely different, although both user interfaces
look very much the same. SDT3 had to struggle with many limitations, because
it was a "real-mode" application. SDT 386+ runs in "protected mode" and
therefore has access to all built-in ram by means of a flat addressing mode.

and do they use the same drivers?

I haven't yet disassembled a SDT3 driver, but I doubt they have the same
interface. It's certain, that the 386 series drivers have the same interface
as the ones for series IV, which still was real-mode. OrCAD 386 uses a
so-called real-mode interface handler in order to use the real-mode video
drivers from protected-mode. This is a bit of a hack, but it surely saved
them many man-hours of work rewriting drivers ...

With kind regards,
Matthias

 

[Ian]

Matthias

I only use Orcad for schematic capture, is it worth me 'upgrading' to 386?
(if I can find a copy)

I have the Vesa800.drv and Vesa1024.drv files but they have much later dates
than my Orcad programme files and do not work (just give 'wrong version'
error message.

I don't know what limitations SDT3 had to contend with but the programmers
produced a marvellous result.

Ian Phillips




"Matthias Hartl" <maze@altmuehlnet.de> wrote in message
news:bgau35$dle$02$1@news.t-online.com...

Hello Ian,

Is the schematic part of Orcad 386 the same as SDT 3?

As far as I know they're completely different, although both user
interfaces
look very much the same. SDT3 had to struggle with many limitations,
because
it was a "real-mode" application. SDT 386+ runs in "protected mode" and
therefore has access to all built-in ram by means of a flat addressing
mode.

and do they use the same drivers?

I haven't yet disassembled a SDT3 driver, but I doubt they have the same
interface. It's certain, that the 386 series drivers have the same
interface
as the ones for series IV, which still was real-mode. OrCAD 386 uses a
so-called real-mode interface handler in order to use the real-mode video
drivers from protected-mode. This is a bit of a hack, but it surely saved
them many man-hours of work rewriting drivers ...

With kind regards,
Matthias

 

[Mostafa Kassem]

Matthias Hartl wrote:

Hello,

Does anyone know, if OrCAD has ever released a sample video driver source
code for their old OrCAD 386 series? I'm currently trying to write a new
video driver which fully complies to the VESA 1.2+ standard. Therefore I've
"investigated" one of their drivers, called VESA1024.DRV. After many hours
of work, I already managed to fix a few bugs, so that the screen doesn't get
distorted when moving the mouse or when a new menu pops up, but going any
further than that is very difficult. I wanted to rewrite the whole driver,
but due to lack of missing documentation I still don't fully understand
interaction between the driver and the program. ANY kind of help would be
appreciated! I already have a mixture of assembler and c source codes I'm
willing to share. They do compile and produce a working video driver.

With kind regards,
Matthias Hartl

I have the latest version of Orcad386 and I don't see any Vesa1024.drv in
my driver directory. Where did you find that driver?

Mostafa

------------------------------------------------------
Mostafa Kassem
http://www.hasata.ca
Reply to: M DOT Kassem AT ieee DOT org
-----------------------------------------------------

 

[qrk]

On Thu, 31 Jul 2003 12:46:31 +0200, "Matthias Hartl"
<maze@altmuehlnet.de> wrote:

Hello,

Does anyone know, if OrCAD has ever released a sample video driver source
code for their old OrCAD 386 series? I'm currently trying to write a new
video driver which fully complies to the VESA 1.2+ standard. Therefore I've
"investigated" one of their drivers, called VESA1024.DRV. After many hours
of work, I already managed to fix a few bugs, so that the screen doesn't get
distorted when moving the mouse or when a new menu pops up, but going any
further than that is very difficult. I wanted to rewrite the whole driver,
but due to lack of missing documentation I still don't fully understand
interaction between the driver and the program. ANY kind of help would be
appreciated! I already have a mixture of assembler and c source codes I'm
willing to share. They do compile and produce a working video driver.

With kind regards,
Matthias Hartl

Boy, if you get this working, I'm sure a bunch of us would like your

driver. Unfortunately, I am unable to help you on the Vesa driver
issue.

I have a hacked version of composer.exe which allows you place pins at
the same location. Handy for modern digital parts with lots of ground
and power pins. You can have 50 ground pins look like one pin. Reduces
the symbol size for high-pin count parts.

Mark

 

[Matthias Hartl]

Hello Mostafa,

I have the latest version of Orcad386 and I don't see any Vesa1024.drv in
my driver directory. Where did you find that driver?

This driver was only distributed through their BBS. It was never included
with any version of OrCAD 386 AFAIK. I can mail this driver to you, but
judging from my thorough analysis, I doubt it would be any good for you. It
run's perfectly well on any SVGA card, that implements 2 so-called "video
memory windows" with exclusive read/write access. Needless to say, almost
any modern card I've tried so far doesn't implement video memory windows
like this.

With kind regards,
Matthias

 

[Matthias Hartl]

Hello Mark,

Boy, if you get this working, I'm sure a bunch of us would like your
driver.

It's good to see, that there's interesst in this project!

Unfortunately, I am unable to help you on the Vesa driver issue.

Well, and that's exactly the problem. If I can't find anyone who can at
least give me some hints, I'm lost. There are really strange things going on
inside the driver and I need some explanations.

Cheers,
Matthias

 

[Kevin Aylward]

nws wrote:

In the Eagle system, we have nets and we have signals, what
is the diference ?

A net would refer only to wires, i.e voltages on the wires. A signal
would refer to voltages and pin currents.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[David Harmon]

On Sat, 2 Aug 2003 13:58:43 +0100 in sci.electronics.cad,
"Kevin Aylward" <kevin@anasoft.co.uk> wrote:

nws wrote:
In the Eagle system, we have nets and we have signals, what
is the diference ?

A net would refer only to wires, i.e voltages on the wires. A signal
would refer to voltages and pin currents.

You have no idea what you are talking about. I.e. Eagle commands.

At the risk of oversimplification, "net" is like "wire"+"signal".
"Signal" means that things are logically connected.
"Wire" means that there is a line drawn on your document.
Normally, you will want to do both at the same time with "net".

Use "net" to add a connection on the schematic, which simultaneously
appears on the board as an airwire to be routed later. Or, if
working on a board without an associated schematic, use "net" to
draw a track on the board that can be ripped up and rerouted if you
choose.

Use "signal" if you are working on a board without a schematic, and
you want to add just an airwire. "Signal" cannot be used on a
schematic, because schematics are not allowed airwires.

Use "net".

 

[Mike Engelhardt]

The duty cycle isn't exactly 50%. When I change the .tran command to
".tran 0 2.0m 1m 10n" then V(n001) and V(vrc) average to 2.525V and
2.5248V respectively. These are pretty close to the same. Note you
can compute the average/rms of a trace by holding down the control
key and left mouse clicking on the trace label. You might want to
adjust your PWL waveform.

--Mike

"Chris Carlen" <crobc@BOGUSFIELD.earthlink.net> wrote in message
news:bgh8s402q9h@enews3.newsguy.com...

Hi:

I am beginning a PWM solenoid driver simulation, and discovered that my
average output voltage isn't precisely equal to the duty cycle of my PWM
waveform times the peak voltage:

* Y:\spice\LT-SWcad\solenoid.drive\exp-2.asc
V1 C_neg 0 PULSE(0 1 0 9.98u 20n 0 0u)
V2 C_pos 0 0.5
V3 Vpos 0 5
V4 0 Vneg 0
R1 N001 Vrc 1k
C1 Vrc 0 100n
B1 N001 0 V=limit({Cgain}*(v(C_pos)-v(C_neg)),v(Vpos),v(Vneg))
.tran 0 2.0m 0 10n
.param Cgain=1E4
.backanno
.end

I'm using the B source as a cheap comparator, with gain Cgain, and
inputs C_pos and C_neg.

I sim-ed this then magnified the graph of Vrc in the later time regions
where it levels off, say from 1.5ms to 2ms. The average is 2.5249V.

Adding the line:

.ic v(Vrc)=0

which makes the levelling off start from zero volts instead of 5V,
causes the same result, so the problem isn't just not waiting long enough.

Why isn't the average precisely 2.500V ?


Thanks!

--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Kevin Aylward]

David Harmon wrote:

On Sat, 2 Aug 2003 13:58:43 +0100 in sci.electronics.cad,
"Kevin Aylward" <kevin@anasoft.co.uk> wrote:

nws wrote:
In the Eagle system, we have nets and we have signals, what
is the diference ?

A net would refer only to wires, i.e voltages on the wires. A signal
would refer to voltages and pin currents.

You have no idea what you are talking about.

Indeed I do. I am discussing general terms on schematic captures, I was
not referring specifically to idiosyncrasies of Eagle. It was not
apparent that your issue was Eagle specific, or a general understanding
of generic terms, as often used.


I.e. Eagle commands.

At the risk of oversimplification, "net" is like "wire"+"signal".
"Signal" means that things are logically connected.

Which is obviously totaly at odds to what would expect signals and nets
to mean in a generic way.

"Wire" means that there is a line drawn on your document.

A wire is the thing that connects bits of circuits together, that is, it
has electrical connectivity. A "line" would be a simple graphic object
with no electrical connotations. It makes no sense whatsoever to call
pure graphic objects a wire.

Normally, you will want to do both at the same time with "net".

Use "net" to add a connection on the schematic, which simultaneously
appears on the board as an airwire to be routed later. Or, if
working on a board without an associated schematic, use "net" to
draw a track on the board that can be ripped up and rerouted if you
choose.

Use "signal" if you are working on a board without a schematic, and
you want to add just an airwire. "Signal" cannot be used on a
schematic, because schematics are not allowed airwires.

If you know what the asinine way that Eagle defines their own
terminology, why did you post in the first place?

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mazer]

Mazer wrote in news:Xns93CBC00475137youremailcom@66.185.95.104:

Hi,
I don't know if this exists but what I am looking for is some kind
of CAD
logic software that allows you to tie inputs to keys on the keyboard
for purposes of simulation. I am a student trying to work on an
assignment for my Logic I course, and would like to save some time
designing and simulating my poject. I have been using Altera MAX+PLUS
II in the labs along with an Altera PLD, but would like to do some of
the legwork at home. Basically I want to draw the circuit on my
computer, tie the inputs to my keyboard keys and then simulate on my
PC using the keyboard as inputs and some kind of output to the screen
(waveforms probably). Does such software exist? Any suggestions?

Thanks

Sorry I forget to mention...demo version of the software would be best
for initial evaluation.

 

[Chris Carlen]

Mike Engelhardt wrote:

The duty cycle isn't exactly 50%. When I change the .tran command to
".tran 0 2.0m 1m 10n" then V(n001) and V(vrc) average to 2.525V and
2.5248V respectively. These are pretty close to the same. Note you
can compute the average/rms of a trace by holding down the control
key and left mouse clicking on the trace label. You might want to
adjust your PWL waveform.

--Mike

Mike, there seems to be some problems with the Pulse source.

If I use this:

Pulse(0 1 0 8u 2u 0 10u)

then I see a triangle wave with a period of exactly 10u like it should
be. All the lower peaks land exactly on 10u increments.

But if I use:

Pulse(0 1 0 9u 1u 0 10u)

then there is a little extra 100n or so delay each cycle before it
starts rising again.

This should definitely not happen. I think it is why the sawtooth
averaged less than it should, causing my PWM to average too much.

What can you say about this?

It seems anytime the fall time is specified very short, then this little
extra delay gets in there making the period *not* what was specified.
Note that there is carefully no discrepancy between the period and sum
of rise+Ton+fall times in these examples.

I'm using 2.04o version, BTW.

Ah-ha! Mike, you've got some numeric input bug:

Pulse(0 1 0 9u 1u 0 10u) broken
Pulse(0 1 0 9e-6 1e-6 0 10e-6) broken
Pulse(0 1 0 0.000009 0.000001 0 0.00001) WORKS!

Simulate them for 0.5 to 1ms and watch the horror.


Happy fixin' !


Thanks for assistance.


Good day!


--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Rich Webb]

On Sat, 02 Aug 2003 22:52:40 GMT, Mazer <cready24@hotmail.com> wrote:

Hi,
I don't know if this exists but what I am looking for is some kind of CAD
logic software that allows you to tie inputs to keys on the keyboard for
purposes of simulation. I am a student trying to work on an assignment for
my Logic I course, and would like to save some time designing and
simulating my poject. I have been using Altera MAX+PLUS II in the labs
along with an Altera PLD, but would like to do some of the legwork at home.
Basically I want to draw the circuit on my computer, tie the inputs to my
keyboard keys and then simulate on my PC using the keyboard as inputs and
some kind of output to the screen (waveforms probably). Does such software
exist? Any suggestions?

I don't know of one that specifically lets you "chord" the keyboard to
produce inputs. What I've usually seen is an "input port" or "clock" on
the screen that you mouse-click to change state. If you single step the
clock (as opposed to letting it free run) you can set several input
states and then step the clock to see what happens at the output.

For a freebie demo version (limited in the number of gates, I believe)
there's one at www.beigebag.com. Look for their "Lite" version. It also
does analog and mixed signal simulations.

--
Rich Webb Norfolk, VA

 

[Mike Engelhardt]

Your 2nd pulse function gives the warning:

WARING: Specified period is not longer than the sum of Trise,
Tfall, and Ton for v1. Increasing period to 1.01e-005.

This warning can be viewed with the command View=>SPICE
error log.

You have to make sure that the period is longer than what it
says, otherwise it will extend it 1% longer than the minimum.

This comes about as a consequence that LTspice allows pulse
functions with zero on time.

--Mike

"Chris Carlen" <crobc@BOGUSFIELD.earthlink.net> wrote in message
news:bghjd306qa@enews3.newsguy.com...

Mike Engelhardt wrote:
The duty cycle isn't exactly 50%. When I change the .tran command to
".tran 0 2.0m 1m 10n" then V(n001) and V(vrc) average to 2.525V and
2.5248V respectively. These are pretty close to the same. Note you
can compute the average/rms of a trace by holding down the control
key and left mouse clicking on the trace label. You might want to
adjust your PWL waveform.

--Mike


Mike, there seems to be some problems with the Pulse source.

If I use this:

Pulse(0 1 0 8u 2u 0 10u)

then I see a triangle wave with a period of exactly 10u like it should
be. All the lower peaks land exactly on 10u increments.

But if I use:

Pulse(0 1 0 9u 1u 0 10u)

then there is a little extra 100n or so delay each cycle before it
starts rising again.

This should definitely not happen. I think it is why the sawtooth
averaged less than it should, causing my PWM to average too much.

What can you say about this?

It seems anytime the fall time is specified very short, then this little
extra delay gets in there making the period *not* what was specified.
Note that there is carefully no discrepancy between the period and sum
of rise+Ton+fall times in these examples.

I'm using 2.04o version, BTW.

Ah-ha! Mike, you've got some numeric input bug:

Pulse(0 1 0 9u 1u 0 10u) broken
Pulse(0 1 0 9e-6 1e-6 0 10e-6) broken
Pulse(0 1 0 0.000009 0.000001 0 0.00001) WORKS!

Simulate them for 0.5 to 1ms and watch the horror.


Happy fixin' !


Thanks for assistance.


Good day!


--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[David Harmon]

On Sat, 2 Aug 2003 23:28:06 +0100 in sci.electronics.cad,
"Kevin Aylward" <kevin@anasoft.co.uk> wrote:

nws wrote:
In the Eagle system, we have nets and we have signals, what

[chop]

Indeed I do. I am discussing general terms on schematic captures, I was
not referring specifically to idiosyncrasies of Eagle. It was not
apparent that your issue was Eagle specific,

Oh come on, what do you think that "In the Eagle system" as written
by the original poster and quoted in your reply means then? It
means that the whole thread is Eagle specific. It means that your
reply is completely worthless, in the context of the Eagle system.
The qualification "In the Eagle system" could not possibly have been
more clear. You failed to read the post you were responding to.

If you know what the asinine way that Eagle defines their own
terminology, why did you post in the first place?

I didn't post "in the first place". Again you failed to read the
post you are responding to. I was answering the question posed by
the original poster, "nws".

 

[Helmut Sennewald]

"Mike Engelhardt" <pmte@concentric.net> schrieb im Newsbeitrag
news:bghnf8$2gp@dispatch.concentric.net...

Your 2nd pulse function gives the warning:

WARING: Specified period is not longer than the sum of Trise,
Tfall, and Ton for v1. Increasing period to 1.01e-005.

This warning can be viewed with the command View=>SPICE
error log.

You have to make sure that the period is longer than what it
says, otherwise it will extend it 1% longer than the minimum.

Mike,
this 1% isn't what a designer would expect in his wildest dreams.

This comes about as a consequence that LTspice allows pulse
functions with zero on time.

When I use the correct command PULSE(0 1 0 9.98u 20n 0n 10u),
I still have got the error message and the wrong period.
The only way to overcome this problem is something like
PULSE(0 1 0 9.98u 19.999n 0n 10u) .
It is now obvious that it is a simple problem when calculating with
floating point numbers. Floating pointer numbers are only exact
for integers and the numbers which exavtly fit the value of
mantissa*2^exponent.
So I have to use one very odd number in the PULSE command to avoid
this error. I recommend to use some correction(rounding) in LTSPICE to
overcome this problem.

I assume the chek is something like this:

// t_r(rise), t_f(fall), t_on(width), t_p(period)

May be your code look like this:
if ( (t_r + t_f + t_on) <= t_p )
{
ok;
}
else
{
fprintf(Error message);
t_on = 0.01 * (t_r + t_f); // The bad assumption
t_p = t_r + t_f + t_on;
}

Mike, here is a ready to use C-program to correct your pulse source check.
Hope that helps. It corrects as expected from an engineer.

Best Regards
Helmut

// Ltspice_pulse.cpp : Defines the entry point for the console application.
//
// LTSPICE PULSE source check
//
// Algorithm: Adjust first t_w until 0 if t_r + t_f_+ t_w > t_p .
// If that is not sufficient, then adjust t_r and t_f until
// t_p can be met. Never chnage t_p.
// If no t_p is defined, then set t_p = t_r + t_f_+ t_w .
//
// ___________ __________
// / \ /
// / \ /
// / \ /
// / \ /
// / \ /
// __________/ \________/
//
// | t_r |<-- t_w ->| t_f | |
// | |
// |<------------ t_p ----------->|
//

#include "stdafx.h"

int main(int argc, char* argv[])
{

double t_r, t_f, t_w, t_p, t_w_max;
t_r = 9.98e-6;
t_f = 15e-9;
t_w = 20e-9;
t_p = 10e-6;

// The algorithm starts here !


if (t_r == 0) // Some other param checks
first.
t_r = 1e-12; // LTSPICE uses 5% of t_p
here.
if (t_f == 0) // Most users didn't
understand this 5%.
t_f = 1e-12;
if (t_p == 0)
t_p = t_r + t_f + t_w;


if ( (t_r + t_f + t_w) <= t_p )
printf("ok\n");
else
{
t_w_max = t_p - (t_r + t_f); // Max. possible t_w time

if ( (t_w_max - t_w) / t_p < -1e-6 ) // Use a limit for the error
message
printf("Possibly bigger correction\n"); // to avoid the need of x99999
numbers.
else
printf("Possibly smaller correction\n");

if (t_w_max >= 0) // t_r + t_f <= t_p
{
if (t_w > t_w_max) // Adjust t_w to t_w_max
t_w = t_w_max;
}
else // t_r + t_f > t_p
{
t_w = 0; // Set t_w to 0
t_r = t_r + t_r/(t_r + t_f) * t_w_max;
t_f = t_f + t_f/(t_r + t_f) * t_w_max;
}
}

printf("t_r t_f t_w t_p t_w_max\n %e %e %e %e %e\n",
t_r, t_f, t_w, t_p, t_w_max);
return 0;
}

 

[Kevin Aylward]

David Harmon wrote:

On Sat, 2 Aug 2003 23:28:06 +0100 in sci.electronics.cad,
"Kevin Aylward" <kevin@anasoft.co.uk> wrote:

nws wrote:
In the Eagle system, we have nets and we have signals, what

[chop]

Indeed I do. I am discussing general terms on schematic captures, I
was not referring specifically to idiosyncrasies of Eagle. It was not
apparent that your issue was Eagle specific,

Oh come on, what do you think that "In the Eagle system" as written
by the original poster and quoted in your reply means then? It
means that the whole thread is Eagle specific.

It means the the poster *believes* that the question is specific to a
product.

It means that your
reply is completely worthless, in the context of the Eagle system.
The qualification "In the Eagle system" could not possibly have been
more clear.

Not relevant. It is very, very common for people to ask questions,
believing that it is specific to some particular product, but in fact,
has nothing particular to do with that product. One only has to note how
often people request PSpice information, when in fact, its generic Spice
information they are after. Go and read some posts, and look at the
replies.

You failed to read the post you were responding to.

Nope. I took an assumption that the poster might be looking for generic
information. Any fool, can read "Eagle". One tries to read between the
lines when people post. Its very rare that what people request is
actually what they want.

If you know what the asinine way that Eagle defines their own
terminology, why did you post in the first place?

I didn't post "in the first place". Again you failed to read the
post you are responding to. I was answering the question posed by
the original poster, "nws".

My apologise, I missed this.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

David Harmon wrote:

On Sat, 2 Aug 2003 23:28:06 +0100 in sci.electronics.cad,
"Kevin Aylward" <kevin@anasoft.co.uk> wrote:

nws wrote:
In the Eagle system, we have nets and we have signals, what

[chop]

Indeed I do. I am discussing general terms on schematic captures, I
was not referring specifically to idiosyncrasies of Eagle. It was not
apparent that your issue was Eagle specific,

Oh come on, what do you think that "In the Eagle system" as written
by the original poster and quoted in your reply means then? It
means that the whole thread is Eagle specific.

It means the the poster *believes* that the question is specific to a
product.

It means that your
reply is completely worthless, in the context of the Eagle system.
The qualification "In the Eagle system" could not possibly have been
more clear.

Not relevant. It is very, very common for people to ask questions,
believing that it is specific to some particular product, but in fact,
has nothing particular to do with that product. One only has to note how
often people request PSpice information, when in fact, its generic Spice
information they are after. Go and read some posts, and look at the
replies.

You failed to read the post you were responding to.

Nope. I took an assumption that the poster might be looking for generic
information. Any fool, can read "Eagle". One tries to read between the
lines when people post. Its very rare that what people request is
actually what they want.

If you know what the asinine way that Eagle defines their own
terminology, why did you post in the first place?

I didn't post "in the first place". Again you failed to read the
post you are responding to. I was answering the question posed by
the original poster, "nws".

My apologise, I missed this.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Ulrich Strate]

Hello,

Helmut Sennewald wrote:

When I use the correct command PULSE(0 1 0 9.98u 20n 0n 10u),
I still have got the error message and the wrong period.
The only way to overcome this problem is something like
PULSE(0 1 0 9.98u 19.999n 0n 10u) .

I tried n's instead of u's and it worked:

PULSE(0 1 0 9.98u 20n 0n 10000n)

regards
Ulrich