I'm more of an analog kinda guy, I don't really deal that much with
digital circuits yet - but I'm still learning. Could the glitch be
prevented by making inputs and outputs directional (inputs can only take
in signals, outputs can only put signals in.) I assume that you've thought
of this already and there's some very good reason it isn't done...
Anyway, I will be creating a patch based on current SVN soon.
Quick status check. I've added over-rates for resistors now. Resistors
also display the power they're dissipating. See screenshot:
(In the picture the resistor is 1/2W, 350V max., so it would normally be
burning up and destroying itself.)
I was thinking of doing some of the following:
- NTC/PTC resistors. These resistors vary resistance with temperature.
The resistors can be specifically designed to warm up and reduce/increase
resistance. For example, in some CRT TVs, they are used to control the
CRT degauss coil - as the TV starts up the resistor is cool, and at a low
resistane, and the coil degausses the TV. Then when the resistor's
temperature increases the coil reduces in power over a few seconds. A bit
of a speciality item, but would be a very neat addition.
- Variable resistors with:
- Log/antilog/linear scale.
- Power dissipation/voltage limits, identical to fixed resistors.
- Update value next to resistor (maybe) depending on slider value. Or
put another value next to slider.
- Signal generator/voltage signal modifications:
- If possible, add other types of wave: sawtooth (a triangle wave with
100% rise 0% fall), triangle, square and white noise.
- Symmetry, for square and triangle waves.
- For all voltage sources: warn if excess current/short circuit.
- Allow plotting of things like power dissipation through a resistor,
charge in a capacitor, joules in a capacitor, etc.
- Relays. Model as an inductor, so we get back EMF. Switch is controlled
by current through inductor.
- Thyristors, TRIACS, and other needed semiconductor devices.
- For transistors, back-EMF shows warning.
That's a long list of possible things to do, but I'd really like to
improve KTechLab because the other software I've come across is either
commercial /not open-source, or Windows-only, or slow / non-functional in
Wine or has significant analog bugs that affect me. It's also a first big,
open-source project that I've ever worked on, and great C(++) experience.
I have noticed that in my SVN version LEDs and diodes do not work. Is this
(or was this) a problem with SVN a bit back?
> thomas@... wrote:
>> Hi... Again,
>> I have made some more tweaks... I've added capacitor over-rates, and
>> also fixed many NPN transistor over-rate bugs. I added maximum power
>> dissipation for transistors as well (however, I'd like someone else to
>> review that I'm doing it correctly)
>> One thing I added to capacitors (only fixed capacitors at the moment,
>> maybe variable caps soon) was a polar setting, and a maximum working
>> voltage setting. If the capacitor is polar, then it cannot tolerate more
>> than 2.5 volts backward. (This might be a setting later, but at the
>> it's fixed.) If working voltage is exceeded, or the capacitor is run in
>> reverse (when it is polar) an over-rate warning is shown. I also added
>> charge (coulombs), energy (joules) and volts to the tooltip for the
> You are obviously far more capable of working with the GUI and front end
> than I am.
> My own changes had been focused on refactoring the code such that it was
> more reliable and more accurate.
> Currently there are massive problems with most nonlinear components. =(
> My most recent fix involved the Logic out, I think I did a half-way
> decent job of modeling the internal impedance of the port.
> One kinda cool thing ktechlab does now is with SR flip-flops, if you
> connect the output of a SR to an external voltage source and you can
> overpower the output impedance, you can force the part to change state!
> =P This is because the SR flipflop is basically two NOR gates, the
> output of one being one of the inputs of the other, so if you overpower
> that output (probably destroying the part!), you can cause it to change
> states. =P
> The code works because the implementation of SR flipflop is currently
> stateless, it uses nothing other than the states of its pins to
> function. Because LogicOut is a subclass of LogicIn, the output pins
> have all the functionality of input pins! Furthermore, I consolidated
> all state information for the pin down to a single state variable. So
> when you overpower the output, you can force it to change state which
> then triggers the normal cascade of events... =P
> It might also be useful to implement T-flip-flops at some point to
> simplify some other code, such as my DAC demo.
> New president: Here we go again...
> Chemistry.com: A total rip-off.
> Powers are not rights.
> Ktechlab-devel mailing list