[Ktechlab-devel] simulator

[Alan Grimes]

> Enumerating case is only possible if the component act like a Finit
> State Automaton. That may not be the case for every component.
> Embedding language in javascript fashion is (I think) a bad use of
> XML.Remember this: "You know you made a poor use of XML when you need
> some additionnal parsing".

bah!
That doesn't apply because in our use case, what we are trying to
encode, as data are programs, which necessarily need to be interpreted,
no shame in that.

It is absolutely necessary that the user be able to design components.
So compiled C++ is out of the question.

> Embedding a "tag language"... not writable by hand. Not easily readable.
> But no additionnal parsing need to be done.
> another issue I see with XML is that it would be quite heavy. XML files
> may be quite big, parsing everything will take some time.

can't be much worse than the current size of the ktechlab binary! =P

There are several issues that I'm concerned about.

A. Loading circuit save files which contain references to library
components which may not be available when loaded.

B. Being able to easily create derived components. IE, specifying that
"this component is just like that component but here are some specific
specifications". That way we'd have a model for a darlington pair
transistor, then when the user finds a datasheet, he can quickly write a
 specific part specification based on the generic library model.

Multiple inheritance is also important, On-Semi, for example, makes a
power transistor teamed with a thermal diode. So therefore, we'd have to
inherit both the transistor model and the thermal diode model and then
assign them to a heatsink domain which may then be combined with a
larger heatsink domain in the circuit, to get an accurate model of the
part.

To make this really work we need to develop a new parts editor that uses
the same terminology and parameters found in datasheets. It should also
have a mode that would let the user implement simple test circuits and
verify that the graphs produced are similar to those the manufacturer
provided. Of special interest, are the transfer curves for transistors
(and tubes for that matter). -- It should be possible to reproduce these
in the simulator. By doing that we'll be able to verify the accuracy of
our models and the user will be able to understand in what ways the
simulation might not match the actual part.

First you'd need a proper oscilloscope... =P

Then you'd need to set up continuously variable probes for X and Y, and
then a stepping function where you would input a series of voltages or
currents. The engine would then apply a ramp function to X and then
graph Y for each value in the list.

> I'm not against the use of XML, but I think that only simple components
> should be written in XML. Others may be written in C/C++, compiled as
> .so and loaded at launch time (or later...).

Linux absolutly, positively, categorically, does not (and will not
ever), in any way, support that type of dynamically linked libraries. I
have no idea what gave you the impression that it did.

It is conceivably possible that there are kernel calls which may make it
possible BUT THEY ARE NOT DOCUMENTED, ANYWHERE!!!!, There may even be
linkers which support that, but once again they are not documented
anywhere, and there might be user libraries that let you do it but they
are either so obscure I've never heard of them or so arcane that I'd
never attempt to use them. I have spent so much time and effort in utter
frustration that I've had it. I want to design my own OS that loading
plugins is it's primary and essential function, however, in attempting
to develop such an OS, I've not only received no support (which is
expected), I've also been actively thwarted by people who have later
confessed that they didn't like me so they actively worked to frustrate
my efforts by banning me from chat rooms and mailing lists. I'm sorry,
this is a red-hot sore hot-button issue for me.


-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.