[Ktechlab-devel] questions about components

[Alan Grimes]

> I've got several questions about this software.

> 1st. Is possible to exchange subcircuits with other users. For example,
> I've made a 74LS00 (14 pins): this is a 4-NAND IC, or a small 1-bit
> adder, and I would like to offer this circuit to others.

I _think_ you can cut and paste it onto another document-page and then
save that to a file...

> 2nd. Is it possible to make new components, as Shottky Diode, or some
> sources as a Delta-Dirac, or a Slope, Sin, triangle, or any other
> mathematical function for example?

That would be an excellent idea. I downloaded this program for the first
time two nights ago and have been hacking on the code... (I want to
simulate a valve amplifier so I don't waste money on the wrong components.)

The present code implements everything as a class. This is an entirely
intractable approach as there are literally millions of parts out there.

A more ideal approach will attach to a SQL database (such as the MySQL
server available on most linux distros), and be able to import parts
databases from the varrious manufacturers. (I've seen them before though
I havn't yet researched the issue.)


> 3rd. Sometimes, with very small test circuits, if I change the value of
> one variable during the simulation time (frequency for example),
> KTechlab hangs and I have to kill the process. Does I have to stop the
> simulation before change any value?

That's a bug.

This software does three things, all jumbled together.

1. It's an amazingly good GUI, that is the great strength of KDE-family
software.

2. It is a compiler that translates the pictoral language of schematics
into computer code and XML, It does a reasonably good job at that...

3. It is a simulator, at which it mostly sucks. It has several major
issues. Firstly, it implements what I feel to be the wrong set of
concepts including a number that I think are redundant and harmful (in
that they bloat the code and diminish the performance. Today I spent my
time attacking the concept of GROUND. To my thinking, ground is a
voltage source that is fixed at 0 volts and which has a miniscule
resistance and inductance, these secondary properties become important
when considering the wiring layout of an amplifier. I've been going
through the code today and ripping out all of the code having to do with
"GROUND" which is treated as a special kind of node in a lot of
different places. My current code doesn't have any "hidden"
short-circuits, a plague with the code you're probably working with --
voltages and currents which vanish before reaching any actual ground
trace... It still uses the ground icon but the implementation is now the
same (I think), as a voltage source set at 0.

My current code run on my test circuit doesn't behave very well right
now... The AC wall current I'm using works, it charges up the power
supply, but when I attach a load, the entire thing goes dead... HOWEVER,
if I charge up the power supply, then switch the source on and THEN,
power the loads, the capacitance in the circuit discharges as one would
expect it to... The stock code crashed when I tried to install a 100uF
capacitor (current code doesn't), and it would only allow me to power
one load at a time, ontherwise it'd just go dead.

The second major issue with this code is that it implements its own
linear algebra engine. (this is useful for DC circuits.). This has
several problems. First, the implementation is imperfect. I've seen a
situation where I've switched off the right-half of my power supply, it
is now running on its own capacitance. Then I toggle the switch on the
primary load a few times (on the still-connected part of the supply),
obviously there are some cross-linked variables that cause the two
disconnected halves of the cricuit to behave as if they were linked.
Another issue is performance, the comments say that the custom vector
and matrix classes were implemented for performance reasons. Well, if
you want performance USE BLAS/LAPAC!!! Those standardized matrix
libraries are implemented by more than a dozen different vendors and are
optimized for supercomputer class hardware that you can buy for only
$8,000. Another issue with the matrix implementation is that it contains
far too much knowledge about the "element list" class... =(

Good software is written like the CIA, all the information is
compartementalized. ;)

-- man those guys are typedef happy, they even redefined uint!
(Apparently it's a GCC supported type already.. (see stdint.h))

The problem with simulation engines is that the current approach can do
a halfway decient job at low frequencies, but at higher frequencies an
analytic approach is required to accurately determine the waveform at a
given part of the circuit. A critical calculus problem in amplifier
design is to get the thing to be critically dampened... If it is
underdampened, it rings, if it's over dampened, it kills the sound... =(

One solution would be to do what gspeakers did and use gnucap as a
back-end.... I'm not sure what gnucap does but that's the direction I
think this should be headed.

Anyway...


-- 
Don't let your schoolwork get in the way of your learning.

### NEW E-MAIL: agrimes at speakeasy.net ###