Spannungsteiler berechnen

Besonders was die Steuerung mittels Kommandozeile anbelangt habe ich 
hier wohl etwas Mist gebaut. Sollte jetzt besser sein.

Mit Visual Studio 2005 und GCC (Unter Linux). Was denn für Fehler?

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.

Wer sich getraut kann auch gleich die kompilierte Exe ausführen.

@Andreas:

Entweder hat's alle umgehauen oder das Prog ist einfach keinen Kommentar 
wert ;)

@Latex:

Danke :)

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.

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 ;)

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(char msg[]) : 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.

Ooops. Anhang vergessen

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 ;)

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:

1

    //Calculate resistors

2

    // | R1 + R2 = Resistance     |

3

    // | R2 / (R1 + R2) = U2 / U1  |

4

    // => R1 = ((U1 - U2) * Resistance) / U1

5

    R1 = ((U1 - U2) * Resistance) / U1;

6

    if (!get_nearest_combination(values, &R1, &R1cnt, &r11, &r12, &mode1)) {

7

      throw InvalidInputException("No suitable solution could be found for R1!");

8

    }

9

    R2 = R1 * U2 / (U1 - U2);

10

    if (!get_nearest_combination(values, &R2, &R2cnt, &r21, &r22, &mode2)) {

11

      throw InvalidInputException("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!

^^

Grmpf.

Die Express-Versionen sind dahingehend nicht eingeschränkt.

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...

Stefan wrote:
> Tja, selber schuld!

Na, sag bloss.

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).

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 ;)

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)

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 :)

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.