helldriver
Member
Prima, ich mache jetzt Feierabend und fahre Heim zum testen.
Gruß
Stephan
Gruß
Stephan
Software-Modellierung, UML-Klassendiagramme usw.
- Ersteller cadaver
- Erstellt am
helldriver
Member
@Alexander,
ich bin eben mit dem testen fertig geworden.
Das Kalibrieren über die App ist einfach und gut zu händeln. Leider kann ich den Kompasstest über die App nicht nutzen. Mein Mower fiebt immer nur wenn ich auf Norden, Süden, Westen oder Osten drücke. Auch eine Veränderung der Roll-Werte bei den IMU-Settings brachte keine Verbesserung. Ich denke das liegt an den original Tianchen Motoren die ich ja noch verwende.
Siehe hier:
[video width=425 height=344 type=youtube]FpDevpxZ2HU[/video]
Dann musste ich den Sender auch noch mit der Aktuellen Firmware bespielen. Mit der zuletzt von mir genutzten r128 lief er nicht mehr an. Nur schnelle Pieptöne. Nachdem ich den Sender mit der aktuellen SVN-Version versorgt hatte lief er wieder im Automatikmodus. Doch bleibt er überall auf der Wiese immer wieder stehen. So als wie wenn er auf die Perimeterschleife trifft. und mir ist noch aufgefallen das die neue Sender-Version scheinbar mehr Strom benötigt. Mein orig. Tianchen-Netzteil hat einen Lüfter eingebaut, der früher immer nur beim Laden anlief. Jetzt kurz nach dem Einschalten der Schleife läuft er auch. Was für mich bedeutet das die Schleife mehr Energie benötigt. Ich habe dann noch mal die r128 Schleifen-Version aufgespielt und der Lüfter hat sich nicht mehr eingeschaltet. Evtl. hat dieses Verhalten auch noch ein anderer Tester feststellen können.
Ich werde morgen noch mal genau die Leistungsaufnahme messen. Einmal mit der r192 und dann noch mal mit der r128.
Gruß
Stephan
ich bin eben mit dem testen fertig geworden.
Das Kalibrieren über die App ist einfach und gut zu händeln. Leider kann ich den Kompasstest über die App nicht nutzen. Mein Mower fiebt immer nur wenn ich auf Norden, Süden, Westen oder Osten drücke. Auch eine Veränderung der Roll-Werte bei den IMU-Settings brachte keine Verbesserung. Ich denke das liegt an den original Tianchen Motoren die ich ja noch verwende.
Siehe hier:
[video width=425 height=344 type=youtube]FpDevpxZ2HU[/video]
Dann musste ich den Sender auch noch mit der Aktuellen Firmware bespielen. Mit der zuletzt von mir genutzten r128 lief er nicht mehr an. Nur schnelle Pieptöne. Nachdem ich den Sender mit der aktuellen SVN-Version versorgt hatte lief er wieder im Automatikmodus. Doch bleibt er überall auf der Wiese immer wieder stehen. So als wie wenn er auf die Perimeterschleife trifft. und mir ist noch aufgefallen das die neue Sender-Version scheinbar mehr Strom benötigt. Mein orig. Tianchen-Netzteil hat einen Lüfter eingebaut, der früher immer nur beim Laden anlief. Jetzt kurz nach dem Einschalten der Schleife läuft er auch. Was für mich bedeutet das die Schleife mehr Energie benötigt. Ich habe dann noch mal die r128 Schleifen-Version aufgespielt und der Lüfter hat sich nicht mehr eingeschaltet. Evtl. hat dieses Verhalten auch noch ein anderer Tester feststellen können.
Ich werde morgen noch mal genau die Leistungsaufnahme messen. Einmal mit der r192 und dann noch mal mit der r128.
Gruß
Stephan
@Stephan: Danke Dir für's Testen.
Schleife: Ich musste die Leistung etwas erhöhen damit es bei mir perfekt ging. Wir brauchen aber wohl noch eine Leistungsanpassung (bei Dir weniger, bei mir mehr...). Ich denke wir werden das mit einem Poti am Sender lösen. Dein älterer Plot zeigt mir dass wir auch im Roboter die Ausfallerkennung einstellbar gestellten müssen (derzeit bedeutet "smag < 300" nämlich Schleifenausfall): http://www.ardumower.de/media/kunena/attachments/921/Wiese1_Mittig.png Die beiden Punkte werde ich umsetzen.
Kompaß: Den Kompaß-Motortest muss ich selber auch noch durchführen - vielleicht zeigt sich da etwas...
Schleife: Ich musste die Leistung etwas erhöhen damit es bei mir perfekt ging. Wir brauchen aber wohl noch eine Leistungsanpassung (bei Dir weniger, bei mir mehr...). Ich denke wir werden das mit einem Poti am Sender lösen. Dein älterer Plot zeigt mir dass wir auch im Roboter die Ausfallerkennung einstellbar gestellten müssen (derzeit bedeutet "smag < 300" nämlich Schleifenausfall): http://www.ardumower.de/media/kunena/attachments/921/Wiese1_Mittig.png Die beiden Punkte werde ich umsetzen.
Kompaß: Den Kompaß-Motortest muss ich selber auch noch durchführen - vielleicht zeigt sich da etwas...
@Stephan: der Schleifensender hat nun ein Poti bekommen:
http://www.ardumower.de/index.php/de/anleitungen/2013-11-23-19-50-19/induktion#perimeter2
Die Mittelanzapfung des Potis wird wie gezeigt an den Arduino A1 Pin angeschlossen. Über das Poti kann dann die Maximal-Leistung eingestellt werden.
In der pfodApp kann nun mit "Settings->Perimeter->Timed-out if smag below" der Wert für die Schleifenausfallerkennung eingestellt werden. Dazu schaut man sich am besten die Werte im Plot an (pfodApp->Plot->Perimeter (smag)).
Zum Kompaß: Da ist noch ein wenig Fein-Arbeit nötig - das geht so noch nicht...
http://www.ardumower.de/index.php/de/anleitungen/2013-11-23-19-50-19/induktion#perimeter2
Die Mittelanzapfung des Potis wird wie gezeigt an den Arduino A1 Pin angeschlossen. Über das Poti kann dann die Maximal-Leistung eingestellt werden.
In der pfodApp kann nun mit "Settings->Perimeter->Timed-out if smag below" der Wert für die Schleifenausfallerkennung eingestellt werden. Dazu schaut man sich am besten die Werte im Plot an (pfodApp->Plot->Perimeter (smag)).
Zum Kompaß: Da ist noch ein wenig Fein-Arbeit nötig - das geht so noch nicht...
akawakaluwa
New member
Hallo Alexander,
ich habe den Sender auf SVN 195 laufen, und auch das Poti nachgerüstet.
Zusammen mit meiner "alten" SVN 158 auf dem Mäher (Du warst ja mal wieder sehr fleißig
)
läuft alles wunderbar:
Screenshot Mäher SVN 158; Sender SVN 195
Wenn jetzt die aktuell SVN 201 auf dem Mäher spiele, sieht das ganze so aus:
Screenshot Mäher SVN 201; Sender SVN 195
Ich habe hierbei den Mäher manuell mehrfach über die Schleife geschoben.
Es gibt leider keinen Umpolung mehr in Spule, und demnach auch keine Erkennung der Schleife mehr.
Habe ich eventuell zwischen SVN158 und SVN201 noch was übersehen?
Gruß,
Michael
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/1410/Screenshot_2014-08-29-11-08-07.png/
ich habe den Sender auf SVN 195 laufen, und auch das Poti nachgerüstet.
Zusammen mit meiner "alten" SVN 158 auf dem Mäher (Du warst ja mal wieder sehr fleißig
)läuft alles wunderbar:
Screenshot Mäher SVN 158; Sender SVN 195
Wenn jetzt die aktuell SVN 201 auf dem Mäher spiele, sieht das ganze so aus:
Screenshot Mäher SVN 201; Sender SVN 195
Ich habe hierbei den Mäher manuell mehrfach über die Schleife geschoben.
Es gibt leider keinen Umpolung mehr in Spule, und demnach auch keine Erkennung der Schleife mehr.
Habe ich eventuell zwischen SVN158 und SVN201 noch was übersehen?
Gruß,
Michael
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/1410/Screenshot_2014-08-29-11-08-07.png/
Zuletzt bearbeitet von einem Moderator:
@Michael: Danke Dir für's Testen - Nach r195 (r196 bis r201) ist nur für Kompaß und Motorsteuerung Code geändert worden - Hast Du evtl. "pfodApp->ADC Calibration" neu durchgeführt? Falls ja, bitte darauf achten, dass der Schleifensender dabei ausgeschaltet ist. Die ADC-Kalibrierung muss nur einmalig gemacht werden, insb. dann wenn die Werte im Plot "Perimeter->sig" nicht symmetrisch um Null (0) liegen...
akawakaluwa
New member
Vielen Dank für den Hinweis. Das mit der ADC-Kalibrierung hatte ich überhaupt nicht auf dem Schirm :huh:
Kam ja nach der SVN158, welche mein letzter Stand war.
Ich habe jetzt die SVN201 auf den Mäher geladen, und habe kurz mal getestet, primär die Perimeter Funktionen.
Nach der ADC-Kalibrierung mit ausgeschalteter Schleife wurde diese wieder erkannt. Erkennung,
Timeout, Sender Funktion etc, funtioniert alles super. Ich konnte meinen Senderstrom (ich arbeite mit 5 Volt)
auf 150mA drosseln, um überall auf dem Rasen einen ordentlichen SMAG Wert zu bekommen.
IMU habe ich noch deaktiviert, da muss ich mich mit der Kalibrierung noch mal befassen.
Was mir aufgefallen ist:
Ich hatte nach dem Update Probleme meinen Mäher zum fahren, und vor allem zum Wenden zu bewegen.
Ich benutze "noch" die GMPD Motoren ohne Odometrie.
Obwohl in der Motor Einstellung die Max PWM auf 255 stand, fuhr er nicht los.
Erst nachdem ich die RPM Einstellung auf 5 eingestellt hatte, wurden auch die 255 an die Motoren ausgegeben.
Seltsamer Weise verringerten eine höhere, als auch eine niedrigere Einstellung den ausgegebenen PWM Wert.
Ist nicht weiter dramatisch, sollte aber den Usern ohne Odometrie helfen.
Michael
Kam ja nach der SVN158, welche mein letzter Stand war.
Ich habe jetzt die SVN201 auf den Mäher geladen, und habe kurz mal getestet, primär die Perimeter Funktionen.
Nach der ADC-Kalibrierung mit ausgeschalteter Schleife wurde diese wieder erkannt. Erkennung,
Timeout, Sender Funktion etc, funtioniert alles super. Ich konnte meinen Senderstrom (ich arbeite mit 5 Volt)
auf 150mA drosseln, um überall auf dem Rasen einen ordentlichen SMAG Wert zu bekommen.
IMU habe ich noch deaktiviert, da muss ich mich mit der Kalibrierung noch mal befassen.
Was mir aufgefallen ist:
Ich hatte nach dem Update Probleme meinen Mäher zum fahren, und vor allem zum Wenden zu bewegen.
Ich benutze "noch" die GMPD Motoren ohne Odometrie.
Obwohl in der Motor Einstellung die Max PWM auf 255 stand, fuhr er nicht los.
Erst nachdem ich die RPM Einstellung auf 5 eingestellt hatte, wurden auch die 255 an die Motoren ausgegeben.
Seltsamer Weise verringerten eine höhere, als auch eine niedrigere Einstellung den ausgegebenen PWM Wert.
Ist nicht weiter dramatisch, sollte aber den Usern ohne Odometrie helfen.
Michael
helldriver
Member
Hallo,
bei mir ist irgendwie der Wurm drin. Seit der Umstellung des neuen Sender-Code bekomme ich die Schleife nicht mehr zuverlässig zu laufen.
Ich habe jetzt aktuell die r201 Auf dem Mäher und den passenden Code auf dem Sender. Jedoch wird die Schleife nicht mehr erkannt.
In den Sender habe laut Anleitung noch das 100k-Poti eingebaut. in der Konsole sehe ich auch schön die Veränderung bei IMAX wenn ich daran drehe. Ich es auf max Wert eingestellt ist dann bei mir IMAX=2,0.
Am Schleifenausgang habe ich mal ein Multimeter angeschlossen und auf Wechselspannung gestellt. Es wird dann ohne Schleife 12V angezeigt und mit Schleife 3V. Ich denke das passt. Da ich bedingt durch einen Wasserschaden größere Baumaßnahmen auf meinem Grundstück habe dachte ich evtl. Schleifenkabel defekt. Dann habe ich mir mal schnell eine ca. 50m Schleife neu verlegt und leider das selbe Ergebnis.
ADC-Kalibrierung mit ausgeschalteter Schleife hatte leider auch keine Verbesserung gebracht.
Wenn das Kabel der Schleife ganz dicht an die Spule halte kann ich zumindest wieder ein Klares IN oder OUT erkennen.
Den Verstärker des Empfängers im Mower habe ich jetzt sogar auf Max gestellt. Zuvor hatten immer ca. 3/4 gereicht.
Wie groß sollte der SMAG-Wert denn mindestens sein?
Hier mal ein Perimeter-Plot wo der Mower etwa ca. 10cm neben der Schleife im Inneren steht.
Gruß
Stephan
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/921/Screenshot_2014-08-29-19-54-32.png/
bei mir ist irgendwie der Wurm drin. Seit der Umstellung des neuen Sender-Code bekomme ich die Schleife nicht mehr zuverlässig zu laufen.
Ich habe jetzt aktuell die r201 Auf dem Mäher und den passenden Code auf dem Sender. Jedoch wird die Schleife nicht mehr erkannt.
In den Sender habe laut Anleitung noch das 100k-Poti eingebaut. in der Konsole sehe ich auch schön die Veränderung bei IMAX wenn ich daran drehe. Ich es auf max Wert eingestellt ist dann bei mir IMAX=2,0.
Am Schleifenausgang habe ich mal ein Multimeter angeschlossen und auf Wechselspannung gestellt. Es wird dann ohne Schleife 12V angezeigt und mit Schleife 3V. Ich denke das passt. Da ich bedingt durch einen Wasserschaden größere Baumaßnahmen auf meinem Grundstück habe dachte ich evtl. Schleifenkabel defekt. Dann habe ich mir mal schnell eine ca. 50m Schleife neu verlegt und leider das selbe Ergebnis.
ADC-Kalibrierung mit ausgeschalteter Schleife hatte leider auch keine Verbesserung gebracht.
Wenn das Kabel der Schleife ganz dicht an die Spule halte kann ich zumindest wieder ein Klares IN oder OUT erkennen.
Den Verstärker des Empfängers im Mower habe ich jetzt sogar auf Max gestellt. Zuvor hatten immer ca. 3/4 gereicht.
Wie groß sollte der SMAG-Wert denn mindestens sein?
Hier mal ein Perimeter-Plot wo der Mower etwa ca. 10cm neben der Schleife im Inneren steht.
Gruß
Stephan
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/921/Screenshot_2014-08-29-19-54-32.png/
Zuletzt bearbeitet von einem Moderator:
@Stephan: folgende Methode müsste funktionieren zum Einstellen von IMAX: zunächst IMAX auf Null stellen, den Mäher in die Mitte des Gartens stellen und dann ganz langsam IMAX höher stellen. Im Plot sollte nun 'sig' nach einiger Zeit (10 Sekunden) größer werden. An der Stelle wo 'sig' das Maximum erreicht, IMAX belassen.
Der richtige IMAX-Wert hängt mit der Leistungsanpassung zusammen. Ist IMAX für die Schleifenlänge zu groß gewählt, reduziert der Motortreiber automatisch die Leistung und das Signal wird schlechter. Ein Wert von IMAX=0.14 war damals fest im Code eingestellt - damit sollte es wieder gut bei dir funktionieren...
Der richtige IMAX-Wert hängt mit der Leistungsanpassung zusammen. Ist IMAX für die Schleifenlänge zu groß gewählt, reduziert der Motortreiber automatisch die Leistung und das Signal wird schlechter. Ein Wert von IMAX=0.14 war damals fest im Code eingestellt - damit sollte es wieder gut bei dir funktionieren...
akawakaluwa
New member
Hallo,
ich habe mich gerade mit dem IMU in SVN r201 beschäftigt. Die Kalibrierung funktioniert tadellos.
Ich habe den Roboter mal Pirouettent drehen lassen und den IMU geplottet, sieht sehr gut aus:
Allerdings bewegt er sich weder beim Kompass Test, noch bei eingeschalteter Richtungskorrektur auch nur einen Milimeter vom Fleck. Eine PID Anpassung der IMU Roll und Direction Werte haben da auch nicht geholfen.
Gruß,
Michael
Attachment: https://forum.ardumower.de/data/med.../1410/Screenshot_2014-08-30-14-20-36-IMU.png/
ich habe mich gerade mit dem IMU in SVN r201 beschäftigt. Die Kalibrierung funktioniert tadellos.
Ich habe den Roboter mal Pirouettent drehen lassen und den IMU geplottet, sieht sehr gut aus:
Allerdings bewegt er sich weder beim Kompass Test, noch bei eingeschalteter Richtungskorrektur auch nur einen Milimeter vom Fleck. Eine PID Anpassung der IMU Roll und Direction Werte haben da auch nicht geholfen.
Gruß,
Michael
Attachment: https://forum.ardumower.de/data/med.../1410/Screenshot_2014-08-30-14-20-36-IMU.png/
Zuletzt bearbeitet von einem Moderator:
Hallo zusammen, ich bin ganz neu hier. Tolles Projekt finde ich. Ich habe auch schon 2 Arduino Projekte für mich Privat gemacht und es macht mir sehr viel Spass.
Ich bin Software Entwickler und könnte mir vorstellen hier zu helfen.
Z.Z sieht die Software ja gut gewachsen aus und es sind auch "Objekte" definiert. Ist es vorstellbar die Software in eine SOA Architektur zu stecken? Ich habe bei meinem letzten Projekt mit dem Mediator Observer Pattern einen ganz guten Objekt orientierten ansatz gewählt und bin damit seht zufrieden, Da Softwareteile danach ganz einfach hinzugefügt und entfernt werden können, da keine gegenseitigen Abhängigkeiten bestehen.
Franklang
Ich bin Software Entwickler und könnte mir vorstellen hier zu helfen.
Z.Z sieht die Software ja gut gewachsen aus und es sind auch "Objekte" definiert. Ist es vorstellbar die Software in eine SOA Architektur zu stecken? Ich habe bei meinem letzten Projekt mit dem Mediator Observer Pattern einen ganz guten Objekt orientierten ansatz gewählt und bin damit seht zufrieden, Da Softwareteile danach ganz einfach hinzugefügt und entfernt werden können, da keine gegenseitigen Abhängigkeiten bestehen.
Franklang
Hallo Frank,
die Version 1.0 (Github master-Zweig) soll keine neuen Features mehr bekommen (nur noch Bugfixes). Wir werkeln bereits an der nächsten Version (2.0): https://github.com/Ardumower/ardumower/tree/simulator/tests/drivecontrol
Dort sind jetzt für alle Sensoren/Aktoren abstrakte Objekte (Interfaces) definiert, dessen Implementierung in enstprechenden Unterklassen vervollständigt wird.
Exemplarisch wurde das ganze bereits für einen Simulator (sim/simmower.cpp) und für den Arduino Mega (mower.cpp) umgesetzt, d.h. beide benutzen dieselben Oberklassen. Alle Objekte sind als Singleton-Objekte ausgelegt und werden daher nur einmal instanziert und es wird dann direkt auf diese zugegriffen.
Würde uns das Mediator-Pattern weiterhelfen und wie? Brauchen wir es?
Ein ebenfalls neuer Aspekt ist die Ablaufsteuerung des Roboters. Wir versuchen einen neuen Ansatz, weg vom Zustandsautomaten hin zum Behavior Pattern. Wir wissen nicht ob es wirklich geeinget ist so etwas komplexes wie einen Mähroboter vollständig zu steuern. Erste Versuche im Simulator zeigen aber (behavior.cpp), dass es machbar ist...
Gruss,
Alexander
die Version 1.0 (Github master-Zweig) soll keine neuen Features mehr bekommen (nur noch Bugfixes). Wir werkeln bereits an der nächsten Version (2.0): https://github.com/Ardumower/ardumower/tree/simulator/tests/drivecontrol
Dort sind jetzt für alle Sensoren/Aktoren abstrakte Objekte (Interfaces) definiert, dessen Implementierung in enstprechenden Unterklassen vervollständigt wird.
Exemplarisch wurde das ganze bereits für einen Simulator (sim/simmower.cpp) und für den Arduino Mega (mower.cpp) umgesetzt, d.h. beide benutzen dieselben Oberklassen. Alle Objekte sind als Singleton-Objekte ausgelegt und werden daher nur einmal instanziert und es wird dann direkt auf diese zugegriffen.
Würde uns das Mediator-Pattern weiterhelfen und wie? Brauchen wir es?
Ein ebenfalls neuer Aspekt ist die Ablaufsteuerung des Roboters. Wir versuchen einen neuen Ansatz, weg vom Zustandsautomaten hin zum Behavior Pattern. Wir wissen nicht ob es wirklich geeinget ist so etwas komplexes wie einen Mähroboter vollständig zu steuern. Erste Versuche im Simulator zeigen aber (behavior.cpp), dass es machbar ist...
Gruss,
Alexander
Hallo Alexander,
danke für die schnelle Antwort.
Das finde ich gut, dass Ihr erstmal eine Version so weit Bug fixed und nichts neues mehr implementiert.
Mit den Pattern stellst Du genau die richtigen Fragen. Man sollte nicht Patter nutzen der Pattern wegen. Denn jedes Pattern hat nicht nur Vorteile. Und was nutzen einem 10 Pattern und kaum einer versteht den Code noch.
Das Mediator und das Observer Pattern passen ganz gut zusammen und gehören zu den Behavior Pattern. siehe: https://sourcemaking.com/design_patterns/behavioral_patterns
Wie Funktionieren die Mediator Observer Patter zusammen: Es ist so, dass alle Kommunikationsteilnehmer von einer Abstakten Klasse ableiten, damit alle die gleiche Schnittstelle bekommen. Über diese Schnittstelle wird mit allen Kommuniziert. Dadurch kann man die Objekte ganz "sauber" halten ohne eine Zeile Code von einem anderen Kommunikationspartner zu implementieren. Dadurch können auch mehrere Personen Parallel arbeiten, Ohne auf den Code des Anderen zu warten. Oder man kann neue Klassen dazu nehmen ohne Code anpassung. Oder Mehrere Treiber haben und per Kommunikation an oder ausschalten oder oder.
Der Mdeiator steht in der Mitte aller Kommunikations Partner. Jeder der sich für eine spezielle Nachricht interessiert, meldet sich für die nachricht beim Mediator an. Wird jetzt eine Nachricht von irgend jemand gesendet , so schaut der Mediator nach wer sich dfür registiert hat und sendet es an Ihn.
Das ganz ist in wenigen Zeilen Code programmiert und macht das Design sehr Flexibel und Objet Orientiert.
Ich kann gerne mal ein kleines Beisplie senden.
Ich habe mir noch die behavior.cpp angesehen. Ich habe das Pattern selbst noch nicht eingesetzt, ich weiss auch nicht ob es die Software verbessert.
Gruß
Frank
danke für die schnelle Antwort.
Das finde ich gut, dass Ihr erstmal eine Version so weit Bug fixed und nichts neues mehr implementiert.
Mit den Pattern stellst Du genau die richtigen Fragen. Man sollte nicht Patter nutzen der Pattern wegen. Denn jedes Pattern hat nicht nur Vorteile. Und was nutzen einem 10 Pattern und kaum einer versteht den Code noch.
Das Mediator und das Observer Pattern passen ganz gut zusammen und gehören zu den Behavior Pattern. siehe: https://sourcemaking.com/design_patterns/behavioral_patterns
Wie Funktionieren die Mediator Observer Patter zusammen: Es ist so, dass alle Kommunikationsteilnehmer von einer Abstakten Klasse ableiten, damit alle die gleiche Schnittstelle bekommen. Über diese Schnittstelle wird mit allen Kommuniziert. Dadurch kann man die Objekte ganz "sauber" halten ohne eine Zeile Code von einem anderen Kommunikationspartner zu implementieren. Dadurch können auch mehrere Personen Parallel arbeiten, Ohne auf den Code des Anderen zu warten. Oder man kann neue Klassen dazu nehmen ohne Code anpassung. Oder Mehrere Treiber haben und per Kommunikation an oder ausschalten oder oder.
Der Mdeiator steht in der Mitte aller Kommunikations Partner. Jeder der sich für eine spezielle Nachricht interessiert, meldet sich für die nachricht beim Mediator an. Wird jetzt eine Nachricht von irgend jemand gesendet , so schaut der Mediator nach wer sich dfür registiert hat und sendet es an Ihn.
Das ganz ist in wenigen Zeilen Code programmiert und macht das Design sehr Flexibel und Objet Orientiert.
Ich kann gerne mal ein kleines Beisplie senden.
Ich habe mir noch die behavior.cpp angesehen. Ich habe das Pattern selbst noch nicht eingesetzt, ich weiss auch nicht ob es die Software verbessert.
Gruß
Frank
Hallo Alexander,
Ich habe mal ein kleines Beispiel ausgedacht, wie so etwas aussehen könnte. Entscheiden müsstet ihr das natürlich, da es ja wieder mehrarbeit ist, den vorhandenen Code umzuschreiben.
#include
#include
using namespace std;
class Mediator;
class Observer {
public:
Mediator* m_med = NULL;
public: virtual void update( int , int ) = 0;
};
class Mediator {
public:
enum Message { POWER_ON, TREIBER1_ON, TREIBER2_ON,TREIBER_INIT, TREIBER_INIT_FINISHED, TREIBER_ON, TREIBER_AVAILABLE, TREIBER_READY, START, STOP, CURRENT_OK , CUURENT_NOT_OK, MAX_COUNT};
private:
vector groups[MAX_COUNT];
public:
void registerMessage( Observer* o, Message type )
{
groups[type].push_back( o );
}
void sendMsg(string Sender, int msg, int data = -1 ) {
cout
Ich habe mal ein kleines Beispiel ausgedacht, wie so etwas aussehen könnte. Entscheiden müsstet ihr das natürlich, da es ja wieder mehrarbeit ist, den vorhandenen Code umzuschreiben.
#include
#include
using namespace std;
class Mediator;
class Observer {
public:
Mediator* m_med = NULL;
public: virtual void update( int , int ) = 0;
};
class Mediator {
public:
enum Message { POWER_ON, TREIBER1_ON, TREIBER2_ON,TREIBER_INIT, TREIBER_INIT_FINISHED, TREIBER_ON, TREIBER_AVAILABLE, TREIBER_READY, START, STOP, CURRENT_OK , CUURENT_NOT_OK, MAX_COUNT};
private:
vector groups[MAX_COUNT];
public:
void registerMessage( Observer* o, Message type )
{
groups[type].push_back( o );
}
void sendMsg(string Sender, int msg, int data = -1 ) {
cout