Designfrage: Motor _hat_ Motorkomponenten

KeineAhnung78

Wernen, vielen Dank für deine konkreten Fragen.

Werner Salomon schrieb:

Welche Zweck soll Deine fertige Applikation am Ende haben? Es ist ein Riesenunterschied, ob Du an einer (Motor-)Steuerung oder an einer (Motor-)Simulation oder einem Artikelverwaltungsprogramm für Motorteile arbeitest. Die dazugehörigen Entwürfe sind dann ziemlich unterschiedlich.

Motorauslegung

Werner Salomon schrieb:

Wie läuft das Programm ab? Was ist der Input und was soll am Ende ausgegeben werden?

Input sind verschiedene Textdateien (ini-Stil), die aber je nach Motor einen abweichenden Aufbau haben. Ausgegeben werden (zunächst auf Kommandozeile) die elektrischen Daten verschiedener Betriebspunkte. Die Eigenschaften des Motors werden also durch charakteristische Größen beschrieben.

Werner Salomon schrieb:

Warum nicht einen Motor mit Stator, Rotor und Welle als Member? Und der Motor schaltet dann die notwendigen Verbindungen zwischen den einzelnen Objekte; wobei diese ja noch mit Interfaces versehen werden können, falls es verschiedenen Typen von Motorkomponenten gibt.

Hab ich sogar so gemacht, nur hier aus Schreibfaulheit die Liste eingefügt . Motor hat im Moment die Komponenten: Stator, Rotor, Gehäuse, Welle und Luftspalt. Wobei vielleicht besser Rotor und Welle durch ein _hat_ein_ verbunden werden könnten und ebenso Stator _hat_ein_ Gehäuse.

Werner Salomon schrieb:

Eine Kernfrage ist noch: wozu dient Motorkomponente? Ist dies nur ein Griff zum Anfassen (und Wegwerfen) der Objekte, oder hat Motorkomponentenoch irgendeine 'Motoreigene' Methode?

Im Konstruktor möchte ich alle erforderlichen Daten (Abmessungen etc.) aus den ini-Datei in Membervariablen abspeichern und daraus weitere Kenndaten in Memberfunktionen berechnen, die sich unmittelbar aus den Inputdaten ergeben. Beispiel: Die Abmessungen einer Nut stehen in der Inputdatei und die Fläche dazu wird ausgerechnet.

Shade Of Mine

Ich sehe in dem Zeiger jeder Komponente auf den Motor selbst absolut kein Problem.

Die reale Welt muss nicht immer 1:1 abgebildet werden, es geht viel mehr darum die Aufgabenstellung zu modellieren. Daher sollten wir uns nicht über eine Werkstatt und das Ausbauen von Motoren unterhalten sondern über die Aufgabenstellung.

Denn vielleicht sind die Parent-Pointer genau das was notwendig ist. uU ist hier eine Baumansicht sinnvoller als eine flache Liste? Das alles entscheidet die Aufgabenstellung...

dot

Ich würde hier mal den Builder Pattern vorschlagen. Und wenn du mich fragst hat wohl weder der Rotor einen Stator noch der Stator einen Rotor. Ich würde mal sagen ein Motor besteht aus einem Stator und einem Rotor...

KeineAhnung78

Shade Of Mine schrieb:

Denn vielleicht sind die Parent-Pointer genau das was notwendig ist. uU ist hier eine Baumansicht sinnvoller als eine flache Liste? Das alles entscheidet die Aufgabenstellung...

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

Werner Salomon

Ok - 'Motorauslegeung' und der Input für den Motor kommt aus einer Textdatei, die aber anscheinend schon den fertigen Motor und nicht die Anforderungen an den Motor beschreibt.

Ist es richtig, dass das Programm dann ausschließlich die Eigenschaften (elektr. Daten an Betriebspunkten etc.) berechnet, und die eigentliche Auslegung dann extern (ggf. durch den Bediener) geschieht?

Wenn es so ist, dann hast Du sicher einen (oder mehrere) Algorithmen, die Daten aus den verschieden Komponenten sammeln und daraus die gewünschten Ergebnisse bestimmen.

Mal angenommen, da sind mehrere Motortyen und zu jedem Typ gibt es genau einen Algorithmus. Dann erfordert dieser Algorithmus bestimmte Information von jeder einzelnen Motorkomponente.
Wäre dann folgender Ablauf sinnvoll? Motor wird aus ini-Datei geladen - in Abhängigkeit des Inhalts der ini-Datei können unterschiedliche Klassen instanziiert werden (egal ob Motor oder dessen Komponenten). Der Motor legt ggf. noch Verbindungen zw. den Komponenten. Jede Komponente hat ein Interface über das der Algo zugreift.

.. so ich brauche erstmal Dein 'so isses' - bevor ich weiter spinne

Gruß
Werner

Werner Salomon

KeineAhnung78 schrieb:

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

.. nein tu's nicht. ich habe selber vor Jahren auch mal so angefangen. Das ist voll in die Hose gegangen. Ich habe es anschließend das 'Papa-Pattern' genannt - aufzunehmen in die Gruppe der Antipattern.

Das, was Du da vorschlägst, klappt nur, wenn der Motor seine Komponenten nicht kennt!

KeineAhnung78

Werner Salomon schrieb:

Mal angenommen, da sind mehrere Motortyen und zu jedem Typ gibt es genau einen Algorithmus. Dann erfordert dieser Algorithmus bestimmte Information von jeder einzelnen Motorkomponente.
Wäre dann folgender Ablauf sinnvoll? Motor wird aus ini-Datei geladen - in Abhängigkeit des Inhalts der ini-Datei können unterschiedliche Klassen instanziiert werden (egal ob Motor oder dessen Komponenten). Der Motor legt ggf. noch Verbindungen zw. den Komponenten. Jede Komponente hat ein Interface über das der Algo zugreift.

So isses :D.

Je nach Motortyp gibt es eine Instanz einer von Motor abgeleiteten Klasse. Diese Klasse konstruiert alle benötigten Komponenten.

Daneben gibt der Anwender (ebenfalls durch ini-Datei) vor, welche Berechnungen durchgeführt werden sollen.

Dazu gibt es dann eine Klasse Berechnung, die diese Informationen verwaltet.

Berechnung hält einen Zeiger auf den Motor. Soll bsp.weise ein Leerlauf berechnet werden, ruft Berechnung dann die entsprechende Leerlauffunktion der abgeleiteten Motorklasse auf (virtuelle Funktion).

Und die Leerlauffunktion greift auf alle Daten der Motorkomponenten zu.

volkard

KeineAhnung78 schrieb:

Dazu gibt es dann eine Klasse Berechnung, die diese Informationen verwaltet.

Nö. Berchnung ist eine Funktion.

Werner Salomon

KeineAhnung78 schrieb:

Je nach Motortyp gibt es eine Instanz einer von Motor abgeleiteten Klasse. Diese Klasse konstruiert alle benötigten Komponenten.

Daneben gibt der Anwender (ebenfalls durch ini-Datei) vor, welche Berechnungen durchgeführt werden sollen.

jetzt müßte man noch wissen, ob jede Berechnung auf jeden Motortyp angewendet werden kann? - wenn ja, wird es einfacher, weil man dann nur einen einzigen Satz von Interfaces benötigt, mit dem eine Berechnung auf Motor & Co zugreift.

dot

Nur mal so eine Frage: Für was sind in dem Szenario eigentlich die Komponenten gut!?

Shade Of Mine

KeineAhnung78 schrieb:

Shade Of Mine schrieb:

Denn vielleicht sind die Parent-Pointer genau das was notwendig ist. uU ist hier eine Baumansicht sinnvoller als eine flache Liste? Das alles entscheidet die Aufgabenstellung...

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

Das meine ich.
Das ist der komplett falsche Ansatz. Du sollst immer die Aufgabenstellung modellieren, nie die reale Welt.

Deshalb nochmal: WAS willst du machen. Nicht WIE oder WOMIT, sondern WAS.

Werner Salomon

KeineAhnung78 schrieb:

Berechnung hält einen Zeiger auf den Motor. Soll bsp.weise ein Leerlauf berechnet werden, ruft Berechnung dann die entsprechende Leerlauffunktion der abgeleiteten Motorklasse auf (virtuelle Funktion).

Und die Leerlauffunktion greift auf alle Daten der Motorkomponenten zu.

.. das würde bedeuten, dass sich zumindest Teile des Algorithmus innerhalb des Motors oder seiner Komponenten befinden. OO-technisch ist das ok .. es kann aber auch ok sein,in diesem Fall Algorithmus und Entität (Motor & Co) völlig zu trennen.

Schau Dir doch mal das Visitor-Pattern an. Tasuche in dem (Java)Beispiel im Wiki mal Car durch Motor und Visitor durch Algo_Basis aus. Trifft das dann Deine Anforderungen?

volkard schrieb:

KeineAhnung78 schrieb:

Dazu gibt es dann eine Klasse Berechnung, die diese Informationen verwaltet.

Nö. Berchnung ist eine Funktion.

Stimmt - wenn man hier eine Berechnungs-Hierachie einsetzt, braucht man wieder die Klassen und würde diese dann als Funktoren bezeichnen

KeineAhnung78

Werner Salomon schrieb:

jetzt müßte man noch wissen, ob jede Berechnung auf jeden Motortyp angewendet werden kann? - wenn ja, wird es einfacher, weil man dann nur einen einzigen Satz von Interfaces benötigt, mit dem eine Berechnung auf Motor & Co zugreift.

volkard schrieb:

Nö. Berchnung ist eine Funktion.

OK, also gerne noch mehr Details

Die Klasse Berechnung enthält eine Liste von Einzelberechnungen. Dies ist erforderlich, da jede Einzelberechnung unterschiedliche Szenarien verwirklicht: z. B. unterschiedliche Speisespannung. Jede Einzelberechnung wiederum hat eine Liste von Betriebspunkten, denn die Anzahl und Art der Betriebspunkte ist leider auch motorabhängig (Eine Synchronmaschine hat keinen Schlupf, eine Gleichstrommaschine keinen Kipppunkt,...). Zu jeder Einzelrechnung gehört auch noch eine Instanz der Klasse Umgebung, in der Temperaturen usw. abgelegt sind.

Nehmen wir an, ich habe eine Asynchronmaschine und der Anwender will Leerläufe bei verschiedenen Spannungen:

Berechnung* b= new Berechnung();

//Parameter der Einzelrechnungen weggelassen
b->fuege_einzelrechnung_hinzu(new Einzelrechnung()); 
b->fuege_einzelrechnung_hinzu(new Einzelrechnung());
b->fuege_einzelrechnung_hinzu(new Einzelrechnung());

Die Berechnung wird aus der main angestoßen. Eine Schleife über alle Einzelrechnungen ruft jeweils die Methode leerlauf auf, wobei der Algorithmus des Leerlauf in der Motorklasse steckt, da dort dann auf alle Komponenten zugegriffen werden kann.

dot

Warum nicht einfach so:

void SynchronousMotor(Config& configuration)
{
  ...
  BreakoverPoint(stuff);
  ...
}

KeineAhnung78

Shade Of Mine schrieb:

KeineAhnung78 schrieb:

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

Das meine ich.
Das ist der komplett falsche Ansatz. Du sollst immer die Aufgabenstellung modellieren, nie die reale Welt.

Es mag ineffizient oder was auch immer sein, aber wieso es jetzt falsch wäre, erschließt sich mir nicht . Ich find´s stimmiger als pauschal jeder Komponente einen Zeiger auf den Motor mitzugeben.

Shade Of Mine schrieb:

Deshalb nochmal: WAS willst du machen. Nicht WIE oder WOMIT, sondern WAS.

* Programm zur Motorauslegung
* Anwender gibt Art des Motors und Betriebsbedingungen (Temperatur, Kühlbedingungen,...) vor
* Programm berechnet Motorcharakteristik und Anwender kann prüfen, ob Motor für die Anwendung geeignet ist.
* IO über ini-Dateien, Kommandozeilenprogramm
* Motor besteht aus vielen Einzelkomponenten, die durch geometrische, elektrische, mechanische Daten beschrieben werden. Aus den Daten werden weitere Eigenschaften unabhängig von der späteren Rechnung abgeleitet (Bsp. Kreisradius wird eingegeben, Kreisfläche wird berechnet ist als Eigenschaft des Objekts abrufbar
* Es gibt nicht _die_ _eine_ Berechnung. Die Vielfalt ist sehr groß: verschiedene Umgebungsbedingungen, verschiedene Spannungen, verschiedene Betriebspunkte, Leistungsreduzierungen des Motors,...

KeineAhnung78

Äh...wollte mein Klassendiagramm als jpg einfügen, aber wie geht das

KeineAhnung78 schrieb:

Äh...wollte mein Klassendiagramm als jpg einfügen, aber wie geht das

Gar nicht, lade es auf http://imageshack.us hoch und verlink es hier.

KeineAhnung78

Interessierter Mitleser schrieb:

KeineAhnung78 schrieb:

Äh...wollte mein Klassendiagramm als jpg einfügen, aber wie geht das

Gar nicht, lade es auf http://imageshack.us hoch und verlink es hier.

Geht nicht, meine Firma blockt die Seite

Shade Of Mine

KeineAhnung78 schrieb:

Es mag ineffizient oder was auch immer sein, aber wieso es jetzt falsch wäre, erschließt sich mir nicht . Ich find´s stimmiger als pauschal jeder Komponente einen Zeiger auf den Motor mitzugeben.

Du erhöhst dadurch die Komplexität und gewinnst nichts. Wo ist der Nachteil wenn jedes Teil seinen Motor kennt? Das erspart enorm viel arbeit und ist auch Zukunftssicher. Denn wenn du jetzt einem neuen Teil den Motorzeiger nicht gibst, später aber draufkommst dass er ihn doch braucht, musst du refactoren.

Während ein pauschaler Zeiger nicht weh tut.

* Programm berechnet Motorcharakteristik und Anwender kann prüfen, ob Motor für die Anwendung geeignet ist.

Das ist der interessante Punkt.
Ich stelle mir das so vor, dass ich 10 unterschiedliche Motoren eingebe - wobei subsysteme ja gleich bleiben können. Ich kenne mich mit motoren nicht aus, deshalb ist der vergleich jetzt vielleicht etwas blöd. Aber ist es nicht so dass gewisse Teile des Motors durchaus gleich bleiben können und nur zB die zylinder anzahl oder vielleicht auch die Nutzlast die er Bewegen muss sich ändert? Dann wäre eine Baumstruktur ja richtig cool. Ein Motor besteht dann aus zB 5 Subsystemen die jeweils aus 2-7 einzelnen Motorteilen bestehen. Lässt sich dann super hin und herschieben.

Prinzipiell ist es aber so, dass die einzelnen Motorkomponenten aus der Programmsicht doch alle gleich sind, oder? Ích stelle es mir so vor, dass ich das eine Teil (oder auch den Motor selber frage): wie gut kannst du X und es schaut nach wie gut es X machen kann (hängt dann natürlich von seinen Nachbarn/Kindern) ab. Wenn das möglich ist, müsste man immer nur einen Baum traversieren und kann so auch die theoretische effizienz von subsystemen testen.

Alternativ kann es natürlich sein dass ein Teil immer von bestimmten anderen Teilen abhängen muss - dann ist es natürlich komplexer zu bauen da jedes Teil zeiger auf die Teile haben muss von denen es abhängt... dann hat man statt einem parent-Zeiger eben X sibling Zeiger. Ist natürlich viel komplexer und erschwert das austauschen von Komponenten...

Bilder kannst du übrigens auf millionen von webseiten hochladen, irgendeine davon wird schon nicht gesperrt sein...

E-Motoren allgemein, ich weiss ja nicht was der Themenersteller berücksichtigen muss.

Da wären z.B. Luft- oder weniger üblich Wasserkühlung - da könnte man so als Laie davon ausgehen, das der gleiche Rotor in beiden Motoren seine Verwendung finden kann, während andere Bauteile der Kühlung angepasst werden müssen.

Andererseits könnte es Kunden geben, die den gleichen Motor einmal mit einer Welle und ein anderes mal mit einem Wellenausgang auf beiden Seiten benötigen.
Dann könnten theoretisch nur Deckel und Rotor verschieden sein.

Aber, wenn ich dann in der Werbung lese, das man heute 8kW E-Motoren bei 400V Drehstrom an 16A Sicherungen fahren will, muss ich gestehen, das ich da doch Nachholbedarf bei meinen Kenntnissen habe.

MfG f.-th.