From: <th...@tg...> - 2009-06-30 15:19:04
|
I have added a feature, just to BJTs at the moment (but I'm planning resistors, capacitors and most ICs soon), which warns you if you overrate the device. The problem being at the moment, is all it does is show an exclamation mark next to the device. I am trying to figure out how to warn the user of the specifications which have been overrated. Any ideas? I was thinking of a tooltip. But how could this be done? Any implementation ideas? See pic for what has been done so far: http://img14.imageshack.us/img14/5653/ktechlaboverratednpn.png If anyone wants the code they can have it, but it is very messy and probably breaks many standards about mixing display code and calculation code... Tom |
From: Lawrence S. <det...@gm...> - 2009-06-30 20:58:50
|
Nice! I'm not a coder, but I love that feature! th...@tg... wrote: > I have added a feature, just to BJTs at the moment (but I'm planning > resistors, capacitors and most ICs soon), which warns you if you overrate > the device. The problem being at the moment, is all it does is show an > exclamation mark next to the device. > > I am trying to figure out how to warn the user of the specifications which > have been overrated. Any ideas? I was thinking of a tooltip. But how could > this be done? Any implementation ideas? > > See pic for what has been done so far: > http://img14.imageshack.us/img14/5653/ktechlaboverratednpn.png > > If anyone wants the code they can have it, but it is very messy and > probably breaks many standards about mixing display code and calculation > code... > > Tom > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > |
From: <th...@tg...> - 2009-07-01 15:07:40
|
Hi again, Well, after a lot of fiddling, I actually made a pretty good amount of progress. I've added tooltips to BJTs informing you if you overrate them and what specifications have been overrated. See screenshot: http://img268.imageshack.us/img268/934/overnpn.png Work needs to be done on separating parts of the drawing code from calculation code, as it's still a big hack. Then applying it to other components like ICs, capacitors, and resistors. Finally I need to figure out how to post a patch, because I haven't really kept track of files I changed. (Though my editor, KDevelop, leaves backup files like 'main.c~' which is useful in seeing which files have been modified.) I have made a modification which lets components set their own tooltips. At the moment these tooltips are all, by default, set to the component name. I was thinking of adding useful info like power dissipation, charge in a capacitor, etc. to the tooltips. Any other ideas? Tom > Nice! I'm not a coder, but I love that feature! > > th...@tg... wrote: >> I have added a feature, just to BJTs at the moment (but I'm planning >> resistors, capacitors and most ICs soon), which warns you if you >> overrate >> the device. The problem being at the moment, is all it does is show an >> exclamation mark next to the device. >> >> I am trying to figure out how to warn the user of the specifications >> which >> have been overrated. Any ideas? I was thinking of a tooltip. But how >> could >> this be done? Any implementation ideas? >> >> See pic for what has been done so far: >> http://img14.imageshack.us/img14/5653/ktechlaboverratednpn.png >> >> If anyone wants the code they can have it, but it is very messy and >> probably breaks many standards about mixing display code and calculation >> code... >> >> Tom >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: <th...@tg...> - 2009-07-02 15:00:00
|
Hi... Again, I have made some more tweaks... I've added capacitor over-rates, and I've 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 moment 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 capacitor. See screenshot: http://files.getdropbox.com/u/1134084/CapOverRateAndCharge.png I will try to post a patch (and it will be a big patch, because a lot had to be changed to accommodate these additions, which makes KTechLab a more useful program for me, and hopefully others) based on current SVN soon. Tom > Hi again, > > Well, after a lot of fiddling, I actually made a pretty good amount of > progress. I've added tooltips to BJTs informing you if you overrate them > and what specifications have been overrated. > > See screenshot: > http://img268.imageshack.us/img268/934/overnpn.png > > Work needs to be done on separating parts of the drawing code from > calculation code, as it's still a big hack. Then applying it to other > components like ICs, capacitors, and resistors. Finally I need to figure > out how to post a patch, because I haven't really kept track of files I > changed. (Though my editor, KDevelop, leaves backup files like 'main.c~' > which is useful in seeing which files have been modified.) > > I have made a modification which lets components set their own tooltips. > At the moment these tooltips are all, by default, set to the component > name. I was thinking of adding useful info like power dissipation, charge > in a capacitor, etc. to the tooltips. Any other ideas? > > Tom > >> Nice! I'm not a coder, but I love that feature! >> >> th...@tg... wrote: >>> I have added a feature, just to BJTs at the moment (but I'm planning >>> resistors, capacitors and most ICs soon), which warns you if you >>> overrate >>> the device. The problem being at the moment, is all it does is show an >>> exclamation mark next to the device. >>> >>> I am trying to figure out how to warn the user of the specifications >>> which >>> have been overrated. Any ideas? I was thinking of a tooltip. But how >>> could >>> this be done? Any implementation ideas? >>> >>> See pic for what has been done so far: >>> http://img14.imageshack.us/img14/5653/ktechlaboverratednpn.png >>> >>> If anyone wants the code they can have it, but it is very messy and >>> probably breaks many standards about mixing display code and >>> calculation >>> code... >>> >>> Tom >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Ktechlab-devel mailing list >>> Kte...@li... >>> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Alan G. <ag...@sp...> - 2009-07-02 17:10:34
|
th...@tg... wrote: > Hi... Again, > > I have made some more tweaks... I've added capacitor over-rates, and I've > 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 moment > 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 > capacitor. 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. |
From: <th...@tg...> - 2009-07-02 20:12:19
|
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: http://files.getdropbox.com/u/1134084/ResistorOverRatePlusPower.png (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. - Transformers. - 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? Tom > th...@tg... wrote: >> Hi... Again, >> >> I have made some more tweaks... I've added capacitor over-rates, and >> I've >> 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 >> moment >> 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 >> capacitor. > > 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 > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: <th...@tg...> - 2009-07-02 21:07:28
|
Hi, I'm back again. After a bit of getting used to patch/diff - it's the first time I've really got used to it - I made a patch file. See here: http://files.getdropbox.com/u/1134084/ktechlab-over-rate-additions-plus-more-by-Tom-Oldbury.patch Hopefully I did it right - please can someone try it out on a copy of current SVN. Now to work on more stuff. Tom > 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: > http://files.getdropbox.com/u/1134084/ResistorOverRatePlusPower.png > > (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. > - Transformers. > - 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? > > Tom > >> th...@tg... wrote: >>> Hi... Again, >>> >>> I have made some more tweaks... I've added capacitor over-rates, and >>> I've >>> 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 >>> moment >>> 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 >>> capacitor. >> >> 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 >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Alan G. <ag...@sp...> - 2009-07-03 06:37:19
|
th...@tg... wrote: > Hi, > > I'm back again. > > After a bit of getting used to patch/diff - it's the first time I've > really got used to it - I made a patch file. See here: > http://files.getdropbox.com/u/1134084/ktechlab-over-rate-additions-plus-more-by-Tom-Oldbury.patch > > Hopefully I did it right - please can someone try it out on a copy of > current SVN. I found the problem with my build, I had a "--prefix=" statement in my kdevelop configuration. =\ Those SVN diffs had several problems, for one thing it includes differences involving the makefiles, which are specific to your machine and the version of automake you used. For some reason you have a number of Makefile.in's, one from automake 1.9.6 and the other from 1.10.1 Second, I've been on a jihad against class Component. Previously, all the code in DSubCon, DIPComponent, and SimpleComponent were all mixed together in the same class, with hundreds of children. The new layout makes it a bit saner. A great deal of refactoring is still required to confine as much information as possible as tightly as possible. If this were Java, which deals with interfaces quite nicely, this wouldn't be too bad, but in C++ .... You are currently the most enthuseastic programmer on ktechlab, and I must say you are far more capable than even I am! =P I've been wrestling with this code for years and had not gotten close to adding new features of the scope you have. (on the other hand, your rapid progress is probably in part due to my constantly tweaking the code). I'm not sure Item should know anything about "ratings", it's just something that you can put on a canvas... But then this is probably an interface issue. I REALLY don't like class member variables because they are a great place for glitches if not actual bugs to hang out, bloat the memory footprint, bloat the symbol tables in the binaries, etc etc... m_hoverTipText should definitely be replaced by a lazy evaluator which will generate a string ONLY when the tip is actually in the neighborhood. I didn't compute V_CE in BJT because it was an extra variable and it was trivially available from V_BE and V_BC. I felt it was important to remove that variable because it made: (V_CE != V_BE - V_CE) possible so therefore I removed that variable and thereby removed the potential bug. OH CRAP, I MIGHT HAVE BEEN COMPLETELY WRONG!!! I didn't realize, at that time, that I had to diode-clamp those other two variables, hence needing to pre-compute V_CE... ARGH!!!! =0 Maybe I am also completely wrong about how and where I need to diode clamp... (mosfet is currently putting INF's into the matrix! =((( The pathetic attempt at computing the transistor current are these lines here: ###### m_ns.I[0] = (-I_eq_B - I_eq_C) * m_pol; m_ns.I[1] = ( I_eq_C - I_eq_E) * m_pol; m_ns.I[2] = ( I_eq_B + I_eq_E) * m_pol; ###### Those being the device's three Cnodes, or was it cbranches... since we're setting current, I think they're cnodes... You are completely wrong by confusing STATE with SETTINGS. Never use SETINGS for STATE!!!!!! Furthermore, state is only visible when queried, therefore if it is not inherently part of the state, then it should be computed WHEN IT's QUERIED. Once again, this makes it impossible for the state to become inconsistient. In database terms, I'm trying to normalize the classes to make inconsistiencies impossible. Capacitance is an abstract ideal circuit element. (look up "elemental analysis" or something like that). It would be great to have specific capacitor types such as electrolytic capacitor, with the correct symbol... (there are five or six different symbols for different types of capacitors...) I don't know why you have getJoules, it seems trivial to compute from Columbs in higher level code. The functions for obtaining voltage and stuff seem to be fine additions... In general, the stuff in Simulation is there for exactly one task, to set up the linear algebra engine. The components shouldn't do much except try to figure out what's happening by looking at the state of its pins. (pin currents are problematic and moderately broken..) Components are free to be as realistic as desired. There you get things such as the capacitor's ESR, etc, all modeled in terms of abstract circuit elements. Goddamnit, I just spent the entire night using Kompare to view your changes when I should have been catching up on my badly needed sleep. =( -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: <th...@tg...> - 2009-07-03 07:12:44
|
Yeah I know circuit elements really shouldn't know much about being overrated. I also think that items perhaps shouldn't know much about being overrated, but I am not very experienced with C++ and this is my best shot at it without having to rewrite the engine. I use getJoules because it's convenient, I don't have to put maths everywhere. Whilst there aren't specific circuit types, if you do polarize a capacitor the icon does change appropriately. I don't know much about transistors and states and settings... Let me know what needs to be changed with my patch. I did compare the transistor simulation in ktechlab to another simulator (the software at my school is Yenka - it's OK but it's got lots of bugs) and it seems plenty accurate, unless both simulations are wrong... I've gotta go now, bye. Tom > th...@tg... wrote: >> Hi, >> >> I'm back again. >> >> After a bit of getting used to patch/diff - it's the first time I've >> really got used to it - I made a patch file. See here: >> http://files.getdropbox.com/u/1134084/ktechlab-over-rate-additions-plus-more-by-Tom-Oldbury.patch >> >> Hopefully I did it right - please can someone try it out on a copy of >> current SVN. > > I found the problem with my build, I had a "--prefix=" statement in my > kdevelop configuration. =\ > > Those SVN diffs had several problems, for one thing it includes > differences involving the makefiles, which are specific to your machine > and the version of automake you used. For some reason you have a number > of Makefile.in's, one from automake 1.9.6 and the other from 1.10.1 > > Second, I've been on a jihad against class Component. Previously, all > the code in DSubCon, DIPComponent, and SimpleComponent were all mixed > together in the same class, with hundreds of children. The new layout > makes it a bit saner. A great deal of refactoring is still required to > confine as much information as possible as tightly as possible. > > If this were Java, which deals with interfaces quite nicely, this > wouldn't be too bad, but in C++ .... > > You are currently the most enthuseastic programmer on ktechlab, and I > must say you are far more capable than even I am! =P I've been wrestling > with this code for years and had not gotten close to adding new features > of the scope you have. (on the other hand, your rapid progress is > probably in part due to my constantly tweaking the code). > > I'm not sure Item should know anything about "ratings", it's just > something that you can put on a canvas... But then this is probably an > interface issue. > > I REALLY don't like class member variables because they are a great > place for glitches if not actual bugs to hang out, bloat the memory > footprint, bloat the symbol tables in the binaries, etc etc... > m_hoverTipText should definitely be replaced by a lazy evaluator which > will generate a string ONLY when the tip is actually in the neighborhood. > > I didn't compute V_CE in BJT because it was an extra variable and it was > trivially available from V_BE and V_BC. I felt it was important to > remove that variable because it made: (V_CE != V_BE - V_CE) possible so > therefore I removed that variable and thereby removed the potential bug. > > OH CRAP, I MIGHT HAVE BEEN COMPLETELY WRONG!!! I didn't realize, at that > time, that I had to diode-clamp those other two variables, hence needing > to pre-compute V_CE... ARGH!!!! =0 Maybe I am also completely wrong > about how and where I need to diode clamp... (mosfet is currently > putting INF's into the matrix! =((( > > The pathetic attempt at computing the transistor current are these lines > here: > ###### > m_ns.I[0] = (-I_eq_B - I_eq_C) * m_pol; > m_ns.I[1] = ( I_eq_C - I_eq_E) * m_pol; > m_ns.I[2] = ( I_eq_B + I_eq_E) * m_pol; > ###### > > Those being the device's three Cnodes, or was it cbranches... since > we're setting current, I think they're cnodes... > > You are completely wrong by confusing STATE with SETTINGS. Never use > SETINGS for STATE!!!!!! > > Furthermore, state is only visible when queried, therefore if it is not > inherently part of the state, then it should be computed WHEN IT's > QUERIED. Once again, this makes it impossible for the state to become > inconsistient. In database terms, I'm trying to normalize the classes to > make inconsistiencies impossible. > > Capacitance is an abstract ideal circuit element. (look up "elemental > analysis" or something like that). > > It would be great to have specific capacitor types such as electrolytic > capacitor, with the correct symbol... (there are five or six different > symbols for different types of capacitors...) > > I don't know why you have getJoules, it seems trivial to compute from > Columbs in higher level code. > > The functions for obtaining voltage and stuff seem to be fine additions... > > In general, the stuff in Simulation is there for exactly one task, to > set up the linear algebra engine. The components shouldn't do much > except try to figure out what's happening by looking at the state of its > pins. (pin currents are problematic and moderately broken..) Components > are free to be as realistic as desired. There you get things such as the > capacitor's ESR, etc, all modeled in terms of abstract circuit elements. > > Goddamnit, I just spent the entire night using Kompare to view your > changes when I should have been catching up on my badly needed sleep. =( > > > -- > New president: Here we go again... > Chemistry.com: A total rip-off. > Powers are not rights. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Alan G. <ag...@sp...> - 2009-07-03 15:30:42
|
th...@tg... wrote: > I don't know much about transistors and states and settings... Let me know > what needs to be changed with my patch. I did compare the transistor > simulation in ktechlab to another simulator (the software at my school is > Yenka - it's OK but it's got lots of bugs) and it seems plenty accurate, > unless both simulations are wrong... What I'm saying is that you shouldn't put information about the state of a specific transistor into the transistor settings structure which may be associated with a whole class of transistors. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: P Z. <zol...@gm...> - 2009-07-03 07:30:07
|
Hi, I just looket at the patch and it looks OK for the first read. However, I suggest separating the GUI/drawing from the simulation as much as you can, because otherwise the result will be a messy code -- at this moment there _is_ a messed up code in the SVN... About what to draw when the component gets overrated: another possibility is to draw "smoke" on it. Hopefully next week I'll have some free time, then I'll write more and get some work done. Happy coding until then, you're getting on really well, Zoltan On Thu, 02 Jul 2009 22:54:03 +0200, <th...@tg...> wrote: > Hi, > > I'm back again. > > After a bit of getting used to patch/diff - it's the first time I've > really got used to it - I made a patch file. See here: > http://files.getdropbox.com/u/1134084/ktechlab-over-rate-additions-plus-more-by-Tom-Oldbury.patch > > Hopefully I did it right - please can someone try it out on a copy of > current SVN. > > Now to work on more stuff. > > Tom > >> 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: >> http://files.getdropbox.com/u/1134084/ResistorOverRatePlusPower.png >> >> (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. >> - Transformers. >> - 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? >> >> Tom >> |
From: Alan G. <ag...@sp...> - 2009-07-03 02:52:17
|
th...@tg... wrote: > I'm more of an analog kinda guy, mee tooo!! I want to implement vacuum tubes. =P I was just mentioning recent work on the simulator. > 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: > http://files.getdropbox.com/u/1134084/ResistorOverRatePlusPower.png > I was thinking of doing some of the following: Yeah, I've been working on a similar wishlist myself. The main concern that I've had is one of architecture. The current design pattern is not very scalable, witness the massive class heirarchy under PIC component. I want to move to a database driven parts library. Ideal components will still be built in. > 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? =( Yeah, I know. I'm currently having problems running my build on gentoo bcause they changed where the distro puts headers and ktechlab isn't currently compatible with the new configuration. =(((( The #1 problem is making sure the linear algebra engine is as accurate as possible, without that nothing will work. #2, diodes are the core bedrock of all nonlinear components, if the code underlying diode won't work, no other nonlinear component will work. I've been refactoring it trying to make it unbreakable, and it does seem to work a little bit, but it obviously needs a great deal more work. =( #3 I need some serious pen and paper time to figure out a programming language for writing component models that can scale to tens of thousands of parts, without breaking the overall usability of the program. =\ -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: Link <li...@pe...> - 2009-07-03 05:59:31
|
On 02/07/09 22:09, th...@tg... wrote: > 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: > http://files.getdropbox.com/u/1134084/ResistorOverRatePlusPower.png > > (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. > - Transformers. > - 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? > > Tom > Teehee, you're working on half of my own wishlist! I posted that a little over a month ago.[1] [1] http://sourceforge.net/mailarchive/forum.php?thread_name=4A1E478E.5090408%40penguindevelopment.org&forum_name=ktechlab-devel |
From: P Z. <zol...@gm...> - 2009-07-05 12:07:12
Attachments:
t-ff.circuit
|
On Thu, 02 Jul 2009 18:10:05 +0200, Alan Grimes <ag...@sp...> wrote: > Because LogicOut is a subclass of LogicIn, the output pins > have all the functionality of input pins! This just doesn't sound healthy. In analog, practically there is no "in" or "out", but for digital circuits, an output shoudn't "sense" anything. In my opinion, it would be better, to get overrated (too much current through it). > It might also be useful to implement T-flip-flops at some point to > simplify some other code, such as my DAC demo. > Should be fairly easy to create a subcircuit for it. I'm attaching an example ;) |