Hallo zusammen,
ich habe mal ein kleines Tool zum Berechnen von Spannungsteilern
geschrieben. Nach Eingabe der entsprechenden Widerstandsreihe (E3, E6,
E12, ..., E192) und einigen Parametern (z.B. Eingangs- und
Ausgangsspannung, sowie Gesamtwiderstand) berechnet das Prog die
entsprechenden Widerstandswerte. Unterstützt werden "Netzwerke" aus bis
zu zwei Widerständen in Serie oder parallel.
Vielleicht hilft es ja dem Einen oder Anderen. Verbesserungsvorschläge
und Fehlerberichte sind selbstverständlich willkommen.
Gruss,
Philipp
Hm, seltsam. Wenn ich es mit Visual C++ 6.0 kompiliere bekomme ich
ebenfalls diese Fehler. Naja, hab's jetzt mal entsprechend geändert,
damit sollte es nun gehen.
Hier mal eine Umsetzung mit Visual Studio (VC++ 6.0) in ein
Windows Programm.
Ich hab zwar die MFC statisch gelinkt, kann aber nicht ausschliessen,
dass nicht ev. eine DLL oder LIB fehlt. Bei Bedarf bitte melden.
@Karl heinz Buchegger
Win98se --> Geht ohne Lib (bzw... hab VC6 Lib wohl irgenwann mal
installiert...)
Lösung:
R1 = 2.2 Ohm in Reihe zu 10.0 Ohm
R2 = 10.0 Ohm parallel zu 47.0 Ohm
Widerstand = 20.4 Ohm
Abweichung für U1 = 12.0 V:
U2 = 4.8 V
-3.2 %
Abweichung für U2 = 5.0 V:
U1 = 12.4 V
3.3 %
@Karl Heinz Buchegger:
Danke für die Arbeit, funktioniert einwandfrei. Ich sehe zwar nicht ganz
ein, wozu man da eine GUI braucht, aber ich will mich deswegen ja nicht
beklagen :)
@Läubi:
Ist irgendwas mit dem Ergebnis nicht in Ordnung oder ist das der Beweis,
dass es funktioniert?
Philipp Burch wrote:
> @Karl Heinz Buchegger:>> Danke für die Arbeit, funktioniert einwandfrei. Ich sehe zwar nicht ganz> ein, wozu man da eine GUI braucht, aber ich will mich deswegen ja nicht> beklagen :)
Hauptsächlich deshalb, weil ich mir dann keine Command Line
Options merken muss. Und jedesmal dann vorher das ganze mit
Help aufrufen, nur um dann zu grübeln ob zwischen Command Line
Switch und zugehörigem Argument ein Blank reinmuss oder nicht,
und überhaupt ... Bin halt schon etwas älter :-)
Ach ja: Ein Bug ist mir aufgefallen.
Du hast da 2 Abfragen drinn (aus dem Kopf zitiert)
if( dev < 1.0 / 1000000.0 )
cout << "dev < 1ppm";
dass muss natürlich heissen
if( fabs( dev ) < 1.0 / 100000.0 )
cout << "dev < 1ppm";
dev kann auch negativ werden.
Au mann für sowas banales ein Programm? Das sollte jeder der etwas von
sich hällt im gebiet Elektrontechnik doch auch so hinbekommen? Ein
Spannungsteiler is ja jetzt mal nciht soo schwierig der erklärt sich ja
schon durch das Wort Spannungsteiler wie von selbst...
@Stefan:
Dann rechnest du garantiert wenn du eine Schaltung entwirfst oder bei
einer bestehenden Schaltung etwas Feintuning betreibst die notwendigen
Widerstandswerte im Kopf aus? Und weißt natürlich auch sofort VORHER
dass der notwendige zweite (oder dritte) Widerstand im Teiler auch in
der Bastelkiste vorhanden ist? Respekt.... ;)
Nettes Tool, hab bisher immer Excel bzw Calc dafür bemüht..
Stefan wrote:
> Au mann für sowas banales ein Programm? Das sollte jeder der etwas von> sich hällt im gebiet Elektrontechnik doch auch so hinbekommen? Ein> Spannungsteiler is ja jetzt mal nciht soo schwierig der erklärt sich ja> schon durch das Wort Spannungsteiler wie von selbst...
Im Prinzip hast du Recht.
Ich hatte heute das 'Problem' einen Spannungsteiler von 12V auf
5V zu rechnen, wobei ich einen Widerstand mit 10k ausführen
möchte.
Klar hätte ich mir einen Taschenrechner nehmen können und das
schnell durchrechnen. Ich hab mich halt an das Programm erinnert
und in einer schwachen Stunde das Original in VC++ mit einer
GUI drumherum versehen. Ist ja auch nicht ganz uninteressant, wenn
dir das Programm dann auch noch heraussucht, welche Widerstände
es überhaupt in der E-Serie gibt und dir auch noch ausrechnet,
welcher Fehler sich dadurch ergibt. Oder: Du weist welche
Spannung du erreichen möchtest und welchen Gesamtwiderstand
der Spannungsteiler haben soll. Wie gross sollen die Widerstände
sein? Wie kann man mit einer Parallel- bzw. Serienschaltung die
geforderten Widerstände des Teilers erreichen?
Klar: Das alles ist keine Raketentechnik. Aber die vornehmste
Aufgabe eines Computer ist es doch, mir Routinearbeit abzunehmen :-)
(Und ehrlich gesagt, weiß ich die Formeln nicht auswendig. Und
wenn ich die Formeln jedesmal neu ableiten muss, dann kann ich mir
die Formeln auch ein für allemal in ein Programm packen)
Karl heinz Buchegger wrote:
> Philipp Burch wrote:>> @Karl Heinz Buchegger:>>>> Danke für die Arbeit, funktioniert einwandfrei. Ich sehe zwar nicht ganz>> ein, wozu man da eine GUI braucht, aber ich will mich deswegen ja nicht>> beklagen :)>> Hauptsächlich deshalb, weil ich mir dann keine Command Line> Options merken muss. Und jedesmal dann vorher das ganze mit> Help aufrufen, nur um dann zu grübeln ob zwischen Command Line> Switch und zugehörigem Argument ein Blank reinmuss oder nicht,> und überhaupt ... Bin halt schon etwas älter :-)
Das Prog läuft auch wenn du ihm keinen Parameter gibst ;)
Aber egal, jedem das Seine. Ich kann ja auch nicht von mir behaupten,
dass ich dieses schwarze Fensterchen einer anständigen GUI vorziehe...
> Ach ja: Ein Bug ist mir aufgefallen.> Du hast da 2 Abfragen drinn (aus dem Kopf zitiert)>> if( dev < 1.0 / 1000000.0 )> cout << "dev < 1ppm";>> dass muss natürlich heissen>> if( fabs( dev ) < 1.0 / 100000.0 )> cout << "dev < 1ppm";>> dev kann auch negativ werden.
Da hast du natürlich Recht, danke!
@Stefan:
Ich wusste, dass das noch kommen musste. Daher habe ich mir auch schon
entsprechende Argumente zurechtgelegt:
1. "Ein Elektrotechniker der was auf sich hält" verwendet Hilfsmittel
die ihm das Leben erleichtern. Jeder Mensch ist von Natur aus faul ;)
2. Es geht ja nicht darum, bei gegebener Eingangsspannung und zwei
Widerständen die Ausgangsspannung zu berechnen. Das ist wirklich banal.
Aber es geht darum, den "idealen" Spannungsteiler aus einer Kombination
von bis zu vier Widerständen zu finden. Das ist im Kopf doch nicht mehr
ganz so trivial.
3. Es gibt schon genügend unnütze Programme, da kommt's auf Eines mehr
oder weniger eh nicht mehr an.
4. Rumtrollen kannste woanders, wenn es deine Ehre nicht zulässt, sowas
zu verwenden zwingt dich ja auch keiner dazu.
Karl heinz Buchegger wrote:
> (Und ehrlich gesagt, weiß ich die Formeln nicht auswendig. Und> wenn ich die Formeln jedesmal neu ableiten muss, dann kann ich mir> die Formeln auch ein für allemal in ein Programm packen)
Ich merk mir die Formel so:
Gesamtstrom ausrechnen durch beide Widerstände (ist klar: I=U/R wobei
R=R1+R2)
Spannung am unteren Widerstand ausrechnen (auch klar: U=R*I wobei
I=ausgerechneter Gesamtstrom)
So kann man sich die "Spannungsteiler-Formel" ganz gut merken. Falls du
das nicht ohnehin schon meintest mit herleiten.
Wenn man natürlich nen gegebenen Widerstand hat und den anderen
Ausrechnen muss, hilft bei mir auch nur noch aufschreiben und umstellen
der kompletten Formel - hier ist so eine kleine Applikation natürlich
ordentlich im Vorteil.
Ich hab das Programm mal kurz getestet und es gibt ja die häkchen für
"Parallel / Serienschaltung zulassen", zulassen klingt für mich, als
würde er trotzdem die optimale Konfiguration finden, auch wenn der
Fehler geringer ist, wenn man nur einen Widerstand nutzt.
Hier das "Problem": Eingabedaten U1: 5V, U2 = 3.3V, Rges = 10kOhm
Ohne Parallel/Serienschaltung errechnet das Programm einen fehler von
3,2%, wenn man die Parallel/Serienschaltung zulässt, errechnet das
Programm größere Fehler.
Anscheinend ist dem Programm der gegebene Gesammtwiderstand "wichtiger"
als eine möglichst korrrekte Ausgangsspannug.
Klar kann man jetzt klicken und gucken wo das beste Ergebnis rauskommt,
aber ... ;)
Edit: war jetzt bezogen auf Widerstandsreihe 3, war halt so eingestellt
;)
Hauke Radtki wrote:
> Ich hab das Programm mal kurz getestet und es gibt ja die häkchen für> "Parallel / Serienschaltung zulassen", zulassen klingt für mich, als> würde er trotzdem die optimale Konfiguration finden, auch wenn der> Fehler geringer ist, wenn man nur einen Widerstand nutzt.>> Hier das "Problem": Eingabedaten U1: 5V, U2 = 3.3V, Rges = 10kOhm>> Ohne Parallel/Serienschaltung errechnet das Programm einen fehler von> 3,2%, wenn man die Parallel/Serienschaltung zulässt, errechnet das> Programm größere Fehler.> Anscheinend ist dem Programm der gegebene Gesammtwiderstand "wichtiger"> als eine möglichst korrrekte Ausgangsspannug.
Ja, das ist mir auch schon aufgefallen. Das Problem liegt in der Art der
Berechnung: Zuerst wird anhand von U1, U2 und Rges der rechnerisch
exakte Wert für R1 berechnet. Dann wird die passende Kombination für R1
gesucht und anschliessend R2 anhand der beiden Spannungen und Rges
berechnet und gesucht. Warum ich das allerdings so gelöst habe ist mir
ehrlich gesagt ein Rätsel. Sinnvoller wär's, R2 anhand der Spannungen
und R1 zu berechnen. Ich hatte da wohl mal wieder geschlafen ;)
Ist korrigiert.
@Philipp oder Karl Heinz,
nettes kleines Tool.
Lust weiter zu machen ???? OPV Grundschaltungen ????
Immer wieder lästig diese Rechnerei und Formelumstellung.
Danke und Gruß
Stephan
Stephan Henning wrote:
> @Philipp oder Karl Heinz,>> nettes kleines Tool.> Lust weiter zu machen ???? OPV Grundschaltungen ????> Immer wieder lästig diese Rechnerei und Formelumstellung.
Danke. OPVs brauche ich nicht so häufig, aber da liesse sich bestimmt
was machen. Schreib doch mal auf, was das Tool alles können sollte,
vielleicht habe ich wiedermal ein Weilchen Zeit für sowas ;)
Sollte man das später im gleichen Tool kombinieren oder lieber ein neues
Programm schreiben?
wenn ich wünschen dürfte............
ein Proggi mit kleinen Icons für Spannungsteiler, OPV, etc.pp
etc.pp steht für Dinge die Dir oder anderen noch einfallen würden und
natürlich für Dich machbar sind.
Aber rein "elektronische" Berechnungen.
Bei OPV schau mal in die Sparte :
http://www.mikrocontroller.net/articles/Operationsverst%C3%A4rker-Grundschaltungen
Wobei ich nicht sagen will, was davon wirklich oft benötigt wird.
Aber der invertierende und nichtinvertierende wird immer gebraucht.
Der Komparator auch.
Gruß
Stephan Henning wrote:
> wenn ich wünschen dürfte............
Du darfst. Was wirklich umgesetzt wird steht ja eh auf einem anderen
Blatt ;)
> ein Proggi mit kleinen Icons für Spannungsteiler, OPV, etc.pp
"Symbole" klingt nach GUI, damit habe ich in C++ keine Erfahrung... Ich
könnte natürlich ein Schwarzes-Fenster-Nur-Mit-Text-Programm machen und
es jemand anderem überlassen, dazu eine GUI zu basteln. So wie von Karl
heinz bereits begonnen.
> etc.pp steht für Dinge die Dir oder anderen noch einfallen würden und> natürlich für Dich machbar sind.> Aber rein "elektronische" Berechnungen.>> Bei OPV schau mal in die Sparte :> http://www.mikrocontroller.net/articles/Operationsverst%C3%A4rker-Grundschaltungen
Ja, schlussendlich läuft da ja auch alles auf die Berechnung von
Spannungsteilern, bzw. Widerstandskombinationen hinaus. Würde also
relativ gut zum Prog passen.
> Wobei ich nicht sagen will, was davon wirklich oft benötigt wird.> Aber der invertierende und nichtinvertierende wird immer gebraucht.> Der Komparator auch.
Ich schau mal wann ich Zeit finde :)
Ich würd sagen ein extra Programm. Die ganzen Programme kann man dann
gut unter einer GUI zusammenfassen. Ich wäre auch bereit da was mit Java
hinzuklatschen ;)
Hab das Programm auch gerade runtergeladen und unter Linux kompiliert.
Folgende Kommentare hätte ich dazu:
- Funktioniert.
- Das Programm ist sehr nützlich, da das Finden optimaler
Widerstandspaare in den E-Reihen von Hand viel zu aufwendig ist.
- Kommandozeilenversionen haben auch im Klickibuntizeitalter ihre
Berechtigung. Vielleicht weniger auf Windowsplattformen, weil es
dort kein geeignetes Tool (sprich Shell) gibt, wo man Kommandos
komfortabel eingeben kann ;-), aber auf fast allen anderen Betriebs-
systemen. Im Moment scheint auch nur die Kommandozeilenversion
portabel zu sein. Als portables Zwischending zwischen Komandozeile
und GUI hast du ja auch noch den Menümodus eingebaut.
- Mein Eindruck ist, dass, wenn man die Maximalzahl von Widerständen
für R1 und R2 mit 2 angibt, diese auch genutzt werden. Bsp.: E12,
U1 = 5 V, U2 = 2 V, Rges = 25000 Ohm ergibt R1 = (6,8 + 8,2) kOhm
und R2 = (1.8 + 8.2) kOhm. Das ist zwar korrekt, aber R1 = 15 kOhm
und R2 = 10 kOhm wäre einfacher. Ist das beabsichtigt? Dann müsste
aber "Maximum number of resistors" in "Number of resistors"
umbenannt werden.
- Wenn du in Zeile 38
1
InvalidInputException(charmsg[]):ex(msg){}
ein const vor das char schreibst, reduziert sich die Anzahl der
Warnungen beim gcc 4.2.2 mit -Wall von 14 auf 0.
- Bei der Ausgabe der Ergebnisse wäre zu überlegen, ob man zwischen
Zahlen und Einheiten ein Leerzeichen einfügt. Ich bin mir bei 100Ohm
immer etwas unsicher, ob das jetzt 100 oder 1000 Öhmer sind. Kann
aber auch an meinen Augen liegen. Außerdem kann das ja jeder nach
seinem Geschmack ändern.
Ich habe natürlich auch die GUI-Variante von Karl Heinz ausprobiert,
und zwar mangels einer Windows-Installation mit Wine unter Linux. Auch
hier meine Kommentare:
- Funktioniert ebenfalls.
- Es werden keine Bibliotheken außer den mit Wine mitgelieferten
Opensource-Bibliotheken benötigt. Wären alle Windows-Programme so
geschrieben, könnte M$ bald schließen ;-)
- Kleiner Schönheitsfehler: Die beiden V neben U1 und U2 stehen nicht
exakt übereinander. Bevor ich jetzt Erbsenzähler gescholten werde:
Ein Kritikpunkt muss ja sein, und ich konnte keinen anderen finden
;-)
Zum scheinbaren Fehler der ersten Version von RDC.cpp:
> Hm, seltsam. Wenn ich es mit Visual C++ 6.0 kompiliere bekomme ich> ebenfalls diese Fehler.
Das ist ein Feature von VC6: Nach Standard ist eine Variable, die in
Kopf einer For-Schleife definiert wird, nur innerhalb der Schleife
gültig. VC6 sieht das anders. Man kann mittels einer Compiler-Option
die Standardkonformität einschalten (oder zumindest etwas erhöhen).
Dann verschwindet zwar die Fehlermeldung, dafür erntet man hunderte
neue aus den mitgelieferten Include-Files, die ebenfalls den Standard
mit Füßen treten ;-)
In der Nachfolgeversion von VC sind diese Fehler im Compiler und den
Include-Files behoben.
> Ich würd sagen ein extra Programm. Die ganzen Programme kann man> dann gut unter einer GUI zusammenfassen. Ich wäre auch bereit da was> mit Java hinzuklatschen ;)
Mit Java-Oberfläche würde das GUI plattformunabhängiger, und man
könnte das Programm sogar auf einem besseren PDA oder Handy laufen
lassen, hätte es also auch dabei, wenn man gerade auf Montage ist :)
Dann würde es sich aber anbieten, das gesamte Programm nach Java
umzuschreiben. Das dürfte ja wegen der Ähnlichkeit von C++ und Java
nicht allzu heftig werden.
yalu wrote:
> Hab das Programm auch gerade runtergeladen und unter Linux kompiliert.> Folgende Kommentare hätte ich dazu:>> - Funktioniert.
Schön :)
> - Das Programm ist sehr nützlich, da das Finden optimaler> Widerstandspaare in den E-Reihen von Hand viel zu aufwendig ist.>> - Kommandozeilenversionen haben auch im Klickibuntizeitalter ihre> Berechtigung. Vielleicht weniger auf Windowsplattformen, weil es> dort kein geeignetes Tool (sprich Shell) gibt, wo man Kommandos> komfortabel eingeben kann ;-), aber auf fast allen anderen Betriebs-> systemen. Im Moment scheint auch nur die Kommandozeilenversion> portabel zu sein. Als portables Zwischending zwischen Komandozeile> und GUI hast du ja auch noch den Menümodus eingebaut.
Ja, ich würde sagen, der Menümodus geht eigentlich nicht so schlecht zum
Verwenden. Ich mag sowas ;)
> - Mein Eindruck ist, dass, wenn man die Maximalzahl von Widerständen> für R1 und R2 mit 2 angibt, diese auch genutzt werden. Bsp.: E12,> U1 = 5 V, U2 = 2 V, Rges = 25000 Ohm ergibt R1 = (6,8 + 8,2) kOhm> und R2 = (1.8 + 8.2) kOhm. Das ist zwar korrekt, aber R1 = 15 kOhm> und R2 = 10 kOhm wäre einfacher. Ist das beabsichtigt? Dann müsste> aber "Maximum number of resistors" in "Number of resistors"> umbenannt werden.
Da hast du in der Tat recht. Ich hatte zwar eingebaut, dass er bei
exakten Werten nur einen Widerstand verwendet, aber wenn er vorher auf
eine passende Kombination gestossen ist, dann hat er die verwendet. Ist
jetzt korrigiert, ich hoffe mal, ich habe nicht andere Fehler
eingebaut...
> - Wenn du in Zeile 38>
1
>InvalidInputException(charmsg[]):ex(msg){}
2
>
> ein const vor das char schreibst, reduziert sich die Anzahl der> Warnungen beim gcc 4.2.2 mit -Wall von 14 auf 0.
Danke für den Hinweis. Ist korrigiert.
> - Bei der Ausgabe der Ergebnisse wäre zu überlegen, ob man zwischen> Zahlen und Einheiten ein Leerzeichen einfügt. Ich bin mir bei 100Ohm> immer etwas unsicher, ob das jetzt 100 oder 1000 Öhmer sind. Kann> aber auch an meinen Augen liegen. Außerdem kann das ja jeder nach> seinem Geschmack ändern.
Also ich bin ja überhaupt kein Verfechter vom Plenken, da ziehe ich die
angeklebte Variante definitiv vor. Leider ist 0 und O nunmal recht
ähnlich... Ich hätte ja eigentlich gerne das richtige Zeichen verwendet,
aber cmd.exe kommt schon mit Umlauten nicht recht klar, da brauche ich
mit echten Unicode-Zeichen gar nicht kommen wollen ;)
> Zum scheinbaren Fehler der ersten Version von RDC.cpp:>>> Hm, seltsam. Wenn ich es mit Visual C++ 6.0 kompiliere bekomme ich>> ebenfalls diese Fehler.>> Das ist ein Feature von VC6: Nach Standard ist eine Variable, die in> Kopf einer For-Schleife definiert wird, nur innerhalb der Schleife> gültig. VC6 sieht das anders. Man kann mittels einer Compiler-Option> die Standardkonformität einschalten (oder zumindest etwas erhöhen).> Dann verschwindet zwar die Fehlermeldung, dafür erntet man hunderte> neue aus den mitgelieferten Include-Files, die ebenfalls den Standard> mit Füßen treten ;-)>> In der Nachfolgeversion von VC sind diese Fehler im Compiler und den> Include-Files behoben.
Achso, gut zu wissen. Da hat M$ wohl wiedermal sein eigenes Süppchen
gekocht...
>> Ich würd sagen ein extra Programm. Die ganzen Programme kann man>> dann gut unter einer GUI zusammenfassen. Ich wäre auch bereit da was>> mit Java hinzuklatschen ;)>> Mit Java-Oberfläche würde das GUI plattformunabhängiger, und man> könnte das Programm sogar auf einem besseren PDA oder Handy laufen> lassen, hätte es also auch dabei, wenn man gerade auf Montage ist :)> Dann würde es sich aber anbieten, das gesamte Programm nach Java> umzuschreiben. Das dürfte ja wegen der Ähnlichkeit von C++ und Java> nicht allzu heftig werden.
Über die Verwendung von Java hatte ich am Anfang auch nachgedacht, habe
mich dann allerdings an unseren Pflicht-Programmierkurs in Java erinnert
und es daraufhin sein gelassen. Wäre aber sicher eine Überlegung wert,
vielleicht gibt es hier ja auch Java-Jünger, die gerade nix zu tun
haben.
Danke für das Feedback!
Und hier mal wieder eine aktuelle Exe.
Lässt die sich eigentlich so ausführen? Ich hab' immer noch nicht so
recht verstanden, was ich einstellen muss, damit alle benötigten
Ressourcen dazugelinkt werden...
Und hier die GUI Variante dazu.
@Phillip
Ohne das jetzt kontrolliert zu haben: Die Änderung bezog
sich nur auf get_nearest_combination. Richtig?
Zumindest mit dem oben genannten Testfall kommt bei mir
10k + 15k raus.
>> In der Nachfolgeversion von VC sind diese Fehler im Compiler und den>> Include-Files behoben.>> Achso, gut zu wissen. Da hat M$ wohl wiedermal sein eigenes Süppchen> gekocht...
Der 'Fairness' halber: ursprünglich wars im Stroustroup C++ so
wie M$ das hatte. Der Scope der Schleifenvariable in
for( int i = 0; i < 5; ++i )
{
}
war nicht auf die Schleife beschränkt. War irgendwie sogar logisch,
da ja die Variable wenn mans genau betrachtet ausserhalb des { }
Blocks definiert wurde. Aus praktischen Gründen hat man aber im
ersten C++ Standard den Scope der Variablen dem { } Block
zugeschlagen. Macht irgendwie mehr Sinn.
Nur: Den ersten C++ Standard gabs 1999. VC++ 6.0 kam 1998 auf den
Markt. Klar, M$ hatte Leute in den Gremien sitzen, hat also
schon frühzeitig gewusst, was da kommen wird. Da wird dann aber
die Zeit nicht mehr gereicht haben, die komplette MFC dahingehend
umzuarbeiten, bzw. man wollte kein Risiko eingehen.
Karl heinz Buchegger wrote:
> Und hier die GUI Variante dazu.>> @Phillip> Ohne das jetzt kontrolliert zu haben: Die Änderung bezog> sich nur auf get_nearest_combination. Richtig?
Fast. Die Definition von 'InvalidInputException' habe ich noch mit dem
'const' versehen (Siehe yalus Post oben). Ausserdem habe ich in
'find_values()' noch einige Überprüfungen auf plausible Werte eingebaut.
Das betrifft allerdings eigentlich nur die Kommandozeilenversion.
'make_nice_val()' habe ich ebenfalls noch leicht korrigiert, da gab's
noch ein Problem mit negativen Werten. Müsste jetzt auch passen
(Negative Spannungen werden ja auch unterstützt, ist allerdings nicht
wirklich sinnvoll).
> Zumindest mit dem oben genannten Testfall kommt bei mir> 10k + 15k raus.
Dann hast du die wichtigste Änderung erwischt ;)
>>> In der Nachfolgeversion von VC sind diese Fehler im Compiler und den>>> Include-Files behoben.>>>> Achso, gut zu wissen. Da hat M$ wohl wiedermal sein eigenes Süppchen>> gekocht...>> Der 'Fairness' halber: ursprünglich wars im Stroustroup C++ so> wie M$ das hatte. Der Scope der Schleifenvariable in>> for( int i = 0; i < 5; ++i )> {> }>> war nicht auf die Schleife beschränkt. War irgendwie sogar logisch,> da ja die Variable wenn mans genau betrachtet ausserhalb des { }> Blocks definiert wurde. Aus praktischen Gründen hat man aber im> ersten C++ Standard den Scope der Variablen dem { } Block> zugeschlagen. Macht irgendwie mehr Sinn.>> Nur: Den ersten C++ Standard gabs 1999. VC++ 6.0 kam 1998 auf den> Markt. Klar, M$ hatte Leute in den Gremien sitzen, hat also> schon frühzeitig gewusst, was da kommen wird. Da wird dann aber> die Zeit nicht mehr gereicht haben, die komplette MFC dahingehend> umzuarbeiten, bzw. man wollte kein Risiko eingehen.
Ok, so gesehen sollte man M$ wohl nicht zu start verurteilen. Aber es
gibt ja genügend andere Standards die sie mit Füssen treten ;)
Intervall
>> - Mein Eindruck ist, dass, wenn man die Maximalzahl von>> Widerständen für R1 und R2 mit 2 angibt, diese auch genutzt>> werden.> Ist jetzt korrigiert, ich hoffe mal, ich habe nicht andere Fehler> eingebaut...
Scheint zu funktionieren.
>> ein const vor das char schreibst, reduziert sich die Anzahl der>> Warnungen beim gcc 4.2.2 mit -Wall von 14 auf 0.>> Danke für den Hinweis. Ist korrigiert.
Ja, alle Warnungen sind weg.
>> - Bei der Ausgabe der Ergebnisse wäre zu überlegen, ob man zwischen>> Zahlen und Einheiten ein Leerzeichen einfügt.> Also ich bin ja überhaupt kein Verfechter vom Plenken, da ziehe ich> die angeklebte Variante definitiv vor.
Das hat mit Plenken (Leerzeichen vor Satzzeichen) nichts zu tun. Typo-
graphisch korrekt wäre eigentlich ein kleiner Abstand zwischen Zahl
und Einheit. Da es aber in der Terminalschrift keine halben Leerzei-
chen gibt, muss man sich entscheiden, ob man dieses auf 1 Leerzeichen
auf- oder auf 0 abrundet. Aber, wie gesagt, das kann jeder halten wie
er will.
> Und hier mal wieder eine aktuelle Exe. Lässt die sich eigentlich so> ausführen?
Unter Wine ja, und deswegen wahrscheinlich in jedem "echten"
DOS/Windows erst recht. Aber die Exe scheint nicht aus deinem main.cpp
vom 4.1.08 um 11:26 entstanden zu sein.
Für die folgende Eingabefolge (im Menümodus)
1
3 1 5 2 0 0 50000 1 1
liefert main.cpp ein Ergebnis, RDC.exe hingegen "No suitable solution
could be found for R1!". Auch die GUI-Variante von Karl Heinz bringt
die Fehlermeldung. Oder liegt die Lösung vielleicht so hart an der
Toleranzschwelle, dass Rundungsfehler in der FP-Lib von GNU bzw. MS zu
diesem Unterschied führen?
Jetzt hätte ich noch einen Verbesserungsvorschlag, den ich gestern
vergessen habe:
Ohne mir ihn näher angeschaut zu haben, scheint dein Algorithmus bei
Eingabe von U1, U2 und Rges eine Lösung zu suchen, bei der der Fehler
sowohl von U2 als auch von Rges minimiert wird. In der Praxis ist der
Fehler von Rges oft (wenn auch nicht immer) unerheblich. Wenn ich, wie
in obigem Beispiel, einen Teiler von 5V nach 2V suche, ist mir
ziemlich egal, ob Rges 10k oder 100k beträgt (1k oder 1M wären
allerdings ungünstig). Wenn ich nun auf gut Glück 20k vorgebe, bekomme
ich eine Lösung mit -1,46% Fehler für U2, obwohl mir die Lösung mit
25k und 0% Fehler lieber gewesen wäre.
Schön wäre es deswegen, wenn der Rges-Fehler vom Benutzer vorgegeben
werden könnte, entweder in Prozenten oder als Intervall (bspw. 10k bis
100k).
Karl heinz Buchegger schrieb:
> Und hier die GUI Variante dazu.
Ha, die beiden V stehen jetzt richtig übereinander ;-) Vielen Dank!
yalu wrote:
>>> - Bei der Ausgabe der Ergebnisse wäre zu überlegen, ob man zwischen>>> Zahlen und Einheiten ein Leerzeichen einfügt.>> Also ich bin ja überhaupt kein Verfechter vom Plenken, da ziehe ich>> die angeklebte Variante definitiv vor.>> Das hat mit Plenken (Leerzeichen vor Satzzeichen) nichts zu tun. Typo-> graphisch korrekt wäre eigentlich ein kleiner Abstand zwischen Zahl> und Einheit. Da es aber in der Terminalschrift keine halben Leerzei-> chen gibt, muss man sich entscheiden, ob man dieses auf 1 Leerzeichen> auf- oder auf 0 abrundet. Aber, wie gesagt, das kann jeder halten wie> er will.
Gut, "Plenken" war vielleicht das falsche Wort. Sollte eigentlich mehr
eine Anspielung auf das Problem bei Zeilenumbrüchen sein. Ist hier
allerdings wohl eher unerheblich... Naja, ich überlasse es jedem selbst.
Alternativ könnte die Einheit auch komplett weggelassen werden.
>> Und hier mal wieder eine aktuelle Exe. Lässt die sich eigentlich so>> ausführen?>> Unter Wine ja, und deswegen wahrscheinlich in jedem "echten"
Gut zu wissen.
> DOS/Windows erst recht. Aber die Exe scheint nicht aus deinem main.cpp> vom 4.1.08 um 11:26 entstanden zu sein.>> Für die folgende Eingabefolge (im Menümodus)>
1
> 3 1 5 2 0 0 50000 1 1
2
>
> liefert main.cpp ein Ergebnis, RDC.exe hingegen "No suitable solution> could be found for R1!". Auch die GUI-Variante von Karl Heinz bringt> die Fehlermeldung. Oder liegt die Lösung vielleicht so hart an der> Toleranzschwelle, dass Rundungsfehler in der FP-Lib von GNU bzw. MS zu> diesem Unterschied führen?
Das dürfte an Rundungsfehlern liegen. Der benötigte Wert ist 30k,
get_nearest_value() findet 27k und die Toleranz beträgt 3k. Leider fehlt
da ein '=', denn 3k ist ja eben gerade nicht kleiner als 3k ;)
Ist korrigiert.
> Jetzt hätte ich noch einen Verbesserungsvorschlag, den ich gestern> vergessen habe:>> Ohne mir ihn näher angeschaut zu haben, scheint dein Algorithmus bei> Eingabe von U1, U2 und Rges eine Lösung zu suchen, bei der der Fehler> sowohl von U2 als auch von Rges minimiert wird. In der Praxis ist der> Fehler von Rges oft (wenn auch nicht immer) unerheblich. Wenn ich, wie> in obigem Beispiel, einen Teiler von 5V nach 2V suche, ist mir> ziemlich egal, ob Rges 10k oder 100k beträgt (1k oder 1M wären> allerdings ungünstig). Wenn ich nun auf gut Glück 20k vorgebe, bekomme> ich eine Lösung mit -1,46% Fehler für U2, obwohl mir die Lösung mit> 25k und 0% Fehler lieber gewesen wäre.>> Schön wäre es deswegen, wenn der Rges-Fehler vom Benutzer vorgegeben> werden könnte, entweder in Prozenten oder als Intervall (bspw. 10k bis> 100k).
Da hast du recht. Allerdings will mir gerade keine gescheite Lösung für
dieses Problem einfallen. Im Moment wird ja jede Lösung durch ein leicht
optimiertes Brute-Force-Verfahren gesucht. Also einfach alle
Kombinationen durchprobieren bis ein passendes Ergebnis gefunden wird.
Das funktioniert für die Kombination aus zwei Widerständen ja auch schon
ganz ordentlich, dummerweise geht das aber halt nur, wenn ich wirklich
genau den Wert suche. Ich könnte nun natürlich hingehn und noch eine
Schleife mehr hinpacken, die z.B. 20 verschiedene Werte für Rges
aussucht und dann die Lösung mit dem kleinsten Fehler raussucht. Nur:
Was nehme ich dann als Intervall?
Das Problem liegt ja eigentlich hier:
throwInvalidInputException("No suitable solution could be found for R2!");
12
}
13
Resistance=R1+R2;
Ich habe ja zwei Gleichungen mit zwei Unbekannten, wovon ich erstmal R1
anhand der Spannungen und des Gesamtwiderstands berechne. Hier müsste
ich nun bereits in Betracht ziehen, welche Werte vorhanden sind und Rges
(Resistance) entsprechend anpassen...
Was mir gefallen würde, wäre eine Berechnung anhand der
Bildungsvorschrift der E-Reihe, denn die ist ja bekannt. Für einzelne
Widerstände würde ich mir noch zutrauen, da etwas zu finden, doch bei
Kombinationen dürfte das schon einigermassen kompliziert werden. Aber
ich werde mal was ausprobieren :)
> Karl heinz Buchegger schrieb:>> Und hier die GUI Variante dazu.>> Ha, die beiden V stehen jetzt richtig übereinander ;-) Vielen Dank!
^^
@Karl heinz Buchegger
mal eine Frage zu dem Programm mit dem du die GUI gemacht hast. Lässt
sich das mit C# unter Visual Studio 2005 mit der Express Version machen
oder braucht man da die kostenpflichtige Vollverion um eine Exe.Datei zu
entwickeln?
Ich habe vor zuerst mal so eine Art Tascherechner zu machen mit den man
Komplexe Zahlen berechnen kann.
wars denn aber nicht so dass programme die mit den Express editions
gemacht wurden nur auf dem jeweiligen rechner laufen?
ich hab jedenfalls mal eine bekommen die immer mit solche einer
fehlermeldung beim start abbrach.
Gruß
Fabian
Wäre mir neu.
Guck' mal hier: http://www.microsoft.com/express/support/faq/
Besonders: "# Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions for applications built using
Visual Studio Express Editions."
Wäre relativ sinnlos, wenn man die Progs nicht weitergeben könnte...
Nochmal ein Versuch...
Jetzt berechnet das Programm (wenn möglich) 9 verschiedene Lösungen mit
Werten für Rges im Bereich von Vorgabe / 5 bis Vorgabe * 5. Die Lösungen
werden dann nach dem Fehler sortiert und ausgegeben. Wie viele
Ergebnisse ausgegeben werden sollen, kann ebenfalls angegeben werden.
Leider mutiert das ganze Prog irgendwie schon wieder zum Flickwerk...
Hab gerade mal in der windows version U1=24V, U2=0, R1=47390, R2=47000,
Rges=0 eingegeben... da errechnet er mir ein U2 von 12V - ist aber
falsch. Aus irgend einen Grund rechnet er auch mit 47,4k anstatt meinen
47k + 390
Naja, "falsch" würde ich nicht unbedingt sagen. Es werden halt sämtliche
Ausgaben auf 3 signifikante Stellen gerundet. Das "korrekte" Ergebnis
wäre ja etwa 11.95V, das wird nunmal auf 12V aufgerundet. Zugegeben,
hier etwas extrem, ich hab's mal auf vier Stellen geändert und ein
weiteres Argument für die Commandline gebastelt um die Genauigkeit (Oder
die Auflösung?) einzustellen (1 - 6 Stellen).
>> - Bei der Ausgabe der Ergebnisse wäre zu überlegen, ob man zwischen>> Zahlen und Einheiten ein Leerzeichen einfügt.> Also ich bin ja überhaupt kein Verfechter vom Plenken, da ziehe ich> die angeklebte Variante definitiv vor.
Eigentlich kann man in diesem Fall nichts vorziehen oder mögen. Man
schreibt auch nicht 100SäckeKartoffeln, 1Meter oder dergleichen.
Zwischen Zahl und Einheit gehört ein Leerzeichen um als halbwegs
korrektes Deutsch durchzugehen.
Karl wrote:
>>> - Bei der Ausgabe der Ergebnisse wäre zu überlegen, ob man zwischen>>> Zahlen und Einheiten ein Leerzeichen einfügt.>> Also ich bin ja überhaupt kein Verfechter vom Plenken, da ziehe ich>> die angeklebte Variante definitiv vor.>> Eigentlich kann man in diesem Fall nichts vorziehen oder mögen. Man> schreibt auch nicht 100SäckeKartoffeln, 1Meter oder dergleichen.
Naja, das sind ja alles ausgeschriebene Wörter. Ich könnte natürlich
zwischen dem Widerstand und "Ohm" ein Leerzeichen machen, zwischen der
Spannung und "V" aber nicht, denn "12 V" schreibe ich ganz bestimmt
nicht. Ob korrekt oder nicht. Allenfalls "12 Volt".
Aber das kann ja wirklich jeder so anpassen wie er will, wozu gibt's
schliesslich den Sourcecode (Nein, dafür werde ich keine
Kommandozeilenoption einbauen ;) ).
> Zwischen Zahl und Einheit gehört ein Leerzeichen um als halbwegs> korrektes Deutsch durchzugehen.
Das Programm ist Englisch ;)
Korrekterweise heißt es trotzdem 12 V, 5 A und auch 100 Ohm. Bei den Ohm
zieht nichtmal das Argument, dass es kein ausgeschriebenes Wort ist ;)
Einen Kommandozeilenschalter will ich auch gar nicht, wenn dann mach es
richtig. Wenn ich im Moment Verwendung für das Programm hätte, würde
mich das ärgern bei jeder neuen Version wieder meine privaten
Anpassungen zu machen.
Also gut, ich gebe mich geschlagen. Hier die Version mit den
Leerzeichen. Vielleicht habe ich es sogar überall erwischt... (Ausser
bei Prozenten, das ist eher sowas wie ein Einheitenvorsatz)
So ein Programm mit GUI ist doch kontraproduktiv weil es die
Möglichkeiten einschränkt. Sinnvoll ist eine GUI als eigenständiges
Programm, welche das Spannungsteilerprogramm selber aufruft. Somit hat
man beide Vorteile, Kommandozeile zum schnellen Tippen und zum Einbau in
Skripte oä und eine GUI für komfortable Bedienung ohne Dokumentation
lesen zu müssen.
Ich wollte mit meinem Kommentar bzgl. der Leerzeichen eigentlich keine
Grundsatzdiskussion auslösen (deswegen der Zusatz "wäre zu überlegen"
in meinem ersten Post).
Hätte ich die Kommentare von Karl früher gelesen, hätt ich ihm gerne
ein Sed-Skript o.ä. angeboten, mit dem er bei jeder neuen Version mit
einem Kommando vor sämtliche von Einheiten Leerzeichen einfügen
kann (evtl. sogar direkt im Executable) ;-)
Oje, jetzt sehe ich gerade: Dein Dich-Geschlagen-Geben zieht weitere
Kreise. Ich habe gerade folgende Ausgabe erhalten:
1
Solution 1:
2
R1 = 47k Ohm
3
R2 = 33k Ohm
4
Resistance = 80k Ohm
Jetzt bekomme ich langsam ein richtig schlechtes Gewissen wegen meiner
Meckerei über die fehlenden Leerzeichen <-(
Zum Schluss aber noch etwas Positives: Die Möglichkeit, mehrere
Lösungen ausgeben zu lassen, finde ich echt topp. So ist immer die
gewünschte mit dabei, egal ob man auf genauen Teilungsfaktor oder
genauen Gesamtwiderstand Wert legt :-)
yalu wrote:
> Oje, jetzt sehe ich gerade: Dein Dich-Geschlagen-Geben zieht weitere> Kreise. Ich habe gerade folgende Ausgabe erhalten:>>
1
> Solution 1:
2
> R1 = 47k Ohm
3
> R2 = 33k Ohm
4
> Resistance = 80k Ohm
5
>
>> Jetzt bekomme ich langsam ein richtig schlechtes Gewissen wegen meiner> Meckerei über die fehlenden Leerzeichen <-(
Mach dir keinen Kopf deswegen. Dass die Ergebnisse nun so aussehen, war
klar, sollte das Leerzeichen denn direkt hinter die Zahl? In meinen
Augen gehört die Vorsilbe (Oder wie man das nennen will) eher zur Zahl
als zur Einheit. Das zu ändern wäre allerdings nicht weiter schwer.
> Zum Schluss aber noch etwas Positives: Die Möglichkeit, mehrere> Lösungen ausgeben zu lassen, finde ich echt topp. So ist immer die> gewünschte mit dabei, egal ob man auf genauen Teilungsfaktor oder> genauen Gesamtwiderstand Wert legt :-)
Danke :)
Ja, ja, ich kleiner Pedant schon wieder:
# Zwischen Einheitenvorsatzzeichen und Einheitenzeichen wird kein
Zwischenraum geschrieben.
# Die Zusammensetzung aus Einheitenvorsatzzeichen und Einheitenzeichen
bildet ein neues, untrennbares Einheitenzeichen, das ein Vielfaches oder
einen Teil der betreffenden Einheit bezeichnet.
Aus:
http://de.wikipedia.org/wiki/Vors%C3%A4tze_f%C3%BCr_Ma%C3%9Feinheiten
Karl wrote:
> Ja, ja, ich kleiner Pedant schon wieder:> # Zwischen Einheitenvorsatzzeichen und Einheitenzeichen wird kein> Zwischenraum geschrieben.> # Die Zusammensetzung aus Einheitenvorsatzzeichen und Einheitenzeichen> bildet ein neues, untrennbares Einheitenzeichen, das ein Vielfaches oder> einen Teil der betreffenden Einheit bezeichnet.>> Aus:> http://de.wikipedia.org/wiki/Vors%C3%A4tze_f%C3%BCr_Ma%C3%9Feinheiten
Grmpf, nach sowas hatte ich noch gesucht und nicht gefunden... Danke.
Korrigierte Version im Anhang.
@Gast:
Indem du es mit dem g++ kompilierst. Irgendein Linuxer hier wird dir
sicher sagen können, wie das am einfachsten geht, ich hab's grade nicht
auswendig im Kopf.
@yalu:
:)
weils irgendwie halbwegs in den thread passt ;)
vielleicht hilft das ja auch dem ein oder anderem:
http://hackwerk.de/widerstand/index.php
die berechnung wird online durchgeführt. (man muss also nichts
runterladen)
man gibt das gewünschte übertragungsverhältnis an und erhält
verschiedene vorschläge, die mit genauigkeit und realem verhältnis
aufgelistet werden.
die mindest-genauigkeit kann vorgegeben werden - es werden höchstens 4
widerstände verwendet.
realisiert auch übertragungsverhältnisse > 1 oder < 0 mit OPVs. (zeigt
entsprechende schaltung an)
e-reihen wählbar. zusätzliche widerstandswerte können, wenn gewünscht
angegeben werden.
Thread beobachten
Seitenaufteilung abschalten