Mein MATLAB Forum - goMatlab.de

Mein MATLAB Forum

 
Gast > Registrieren       Autologin?   

Bücher:

Automatisierungstechnik

Studierende:
weitere Angebote

Partner:


Vermarktungspartner


Forum
      Option
[Erweitert]
  • Diese Seite per Mail weiterempfehlen
     


Gehe zu:  
Neues Thema eröffnen Neue Antwort erstellen

Programmstruktur zur serielle Kommunikation

 

PPhallo

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 10.05.2019, 17:57     Titel: Programmstruktur zur serielle Kommunikation
  Antworten mit Zitat      
Hallo, ich komme gerade mit einer Programmstruktur nicht weiter, und wollte mal eine Meinung von "Profis" einholen. Ich selbst beschäftige mich noch nicht sehr lange mit Konzepten der OOP.

Grundlegend ist die Kommunikation zu einem Modulträger, der bis zu vier Wechselrichter (Module) verschiedener Bautypen fassen kann, zu realisieren. Durch setzen der RTS und DTR Pins (rs232 Schnittstelle) wird das gewünschte Modul adressiert, woraufhin der Befehl geschickt wird. Es kommt immer der gespiegelte Befehl für Fehlererkennung zurück (TxD/RxD).

Jetzt ist es so gedacht, dass eine Klasse "Modulträger" durch Aufruf die serielle Schnittstelle initialisiert und ein Attribut als handle für Instanzen der bis zu vier verbauten "Modularten" bereitstellt. Modularten haben eigene Klassen und erben von einer gemeinsamen Klasse "Modul", welche für alle die Methode zur Befehlsrückgabe an das Modulträgerobjekt mit der richtigen DTR/RTS Kennung und die Modulinfoabfrage bereitstellt.

Mein Ziel ist es nun, dass alles Modul im realen Modulträger mit einer Methode erkannt werden können. Dazu muss für jeden Platz, bzw. jede RTS/ DTR Kodierung einmal die Modulinfo abfragen werden.

Gibt es vielleicht Meinungen für einen präferierten/ möglichen Weg:
Es wird nacheinander die Instanz von „Modul“ mit der richtigen Kodierung erzeugt: obj.Module{i} = Modul(obj,i). Dann wird die Modulinfo abgefragt... kann nun bei Erkennung eines Typs die erbende Klasse (spezifisches Modul) aus der Elternklasse mit Attributübernahme instanziiert und gleichzeitig das Elternobjekt gelöscht werden; sich das Objekt also selbst „updaten“? (was ich am elegantesten erpfände)

Oder wird die Modulinfo am besten an das Modulträgerobjekt zurückgegeben und dort wird das Elternobjekt gelöscht und das Handle mit einem neuen Objekt aus der Klasse "Modularten" erzeugt; oder überschrieben?

Oder ist der Weg besser, dass vier Objekte der Klasse „Modul“ erzeugt werden, die dann wiederum nach Erkennung des Modultypen in Assoziationsbeziehung Objekte der „Modularten“ erzeugen?

Am Ende muss ja eine Methode/Befehl von dem Objekt der "Modularten" wieder an das Modulträgerobjekt zurückgegeben werden, also die Kommunikation zwischen den Objekten in beide Richtungen möglich sein.

Ich hoffe die Fragestellung ist einigermaßen erkenntlich, ein grobes UML Diagramm würde sonst helfen? Confused


LionW1
Forum-Newbie

Forum-Newbie


Beiträge: 3
Anmeldedatum: 14.05.19
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 14.05.2019, 16:50     Titel:
  Antworten mit Zitat      
Entschuldigt, habe Frage in neuem Post versucht zu konkretisieren: kann gelöscht werden.
Private Nachricht senden Benutzer-Profile anzeigen
 
Neues Thema eröffnen Neue Antwort erstellen



Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:

Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
.


goMatlab ist ein Teil des goForen-Labels
goForen.de goMATLAB.de goLaTeX.de


 Impressum  | Nutzungsbedingungen  | Datenschutz  | Werbung/Mediadaten | Studentenversion | FAQ | goMatlab RSS Button RSS


Copyright © 2007 - 2021 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
Partner: LabVIEWforum.de

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.