FB als Kommunikationsbasis

Hallo,
Ich würde gerne einmal eure Meinung hören.
Habe mir folgendes überlegt.
Ich habe in einer Maschine mehrer Stationen, diese greifen ineinander.
Wenn diese miteinander "reden", so könnte man natürlich ein und Ausgänge als Signal eines fbs nehmen um Zustände abzufragen, aber ich dachte mir folgendes.
Jede Station hat als extended den Typ "Handshake".
Dieser beinhaltet die Methoden request und acknowledge.
Station1 hat an ihrem fb zusätzlich einen in_out vom Typ Handshake mit dem Namen "Folgestation".
Wenn Station1 nun fertig ist, so ruft sie Folgestation.request(1, this); auf.
Wenn die folgestation bereit für Handshake 1 ist, so gibt sie an den mitgelieferten Pointer zu einem Typ Handshake ein requeststation^.acknoledge(1); zurück.
Station1 weiß nun, dass Station2 bereit ist.
Usw..... was haltet ihr davon?
Dachte mir man kann auch klasse Abläufe damit realisieren....
Bspw. Roboter1 fordert Roboter2 an.
Dieser bestätigt und fährt zu Roboter1.
Dort angekommen fragt er Roboter1 an, ob er seine Greifer öffnet, dieser bestätigt. Dann fragt wieder Roboter1 an. Bitte Teil in Greifer fahren... Roboter2 bestätigt. Dann fragt er an... bitter Greifer schließen..... etc. also immer im Wechsel einen request senden.
Hat jemand Erfahrung mit sowas?

Bisher, also in TC2, habe ich für sowas immer eine Datenaustauschstruktur in der übergeordeten POU, die den untergeordneten POUs als VAR_IN_OUT übergeben wird. Ich habe auch bei TC3 noch nicht den Wunsch verspürt, daran etwas zu ändern. Interfaces und Methoden schön und gut, aber irgendwann willst Du Deine Konstrukte doch auch an einer realen Maschine einsetzen. Da wirst Du beim Debuggen ganz schön ins Schwitzen kommen, weil sich die temporären Variablen von Methoden online nicht beobachten lassen. Ohne Breakpoints sind solche Programme kaum zu debuggen, aber das Programm auf einen Breakpoint laufen zu lassen und die Maschine ungesteuert sich selbst überlassen, ist verdammt gefährlich.

StructuredTrash schrieb:

Da wirst Du beim Debuggen ganz schön ins Schwitzen kommen, weil sich die temporären Variablen von Methoden online nicht beobachten lassen.

Zum Vergrößern anklicken....

Dafür finde ich den "Flow Control"-Modus ganz praktisch, da zeigt der die Belegung der temporären (und normalen) Variablen genau zum Zeitpunkt der Abarbeitung an, und nicht wie das normale Beobachten den Zustand zwischen den Zyklen. Außerdem sieht man ganz gut, welche Codepfade durchlaufen werden.

Wo hat der TE denn etwas von temporären Variablen geschrieben? Er möchte IN_OUT Variablen nutzen und die sind, soweit ich mich nicht irre, nicht temporär und behalten ihren Wert.
Allerdings wird hier beim Kunden auch eine Struktur zur Kommunikation genutzt und die einzelnen Stationen befinden sich als Unter-FB in einem Anlagen-FB der die Daten weiterleitet und eventuell auch noch steuernd eingreift.

Objektorientierung schön und gut, aber:
Es muß für einen "normalen" Instandhalter einfach nachvollziehbar bleiben.
Was einem als Programmierer vielleicht Zeit und Aufwand spart, holt einen vielleicht nachher bei einem Maschinenstillstand ein.

Gruß
Blockmove

@oliver.tonn
Der TE möchte den Folgestations-FB als VAR_IN_OUT übergeben, um so dessen Request-Methode aufrufen zu können. Inwieweit der Aufruf der Methode anschliessend nachvollziehbar ist, dazu hat er nichts geschrieben.

@Blockmove
*ACK*
Das "vielleicht" kannst Du weglassen, und die ersten Gelegenheiten, sich am Kopf zu kratzen, werden wohl schon bei der IBN eintreten.
Als TC3 erschien, habe ich im ersten Überschwang meine alte TC2-Bibliothek darauf umgeschrieben und dabei alle alten Zöpfe abgeschnitten. Also weg mit statischen VAR_INPUT/OUTPUT, her mit Eigenschaften und Methoden. Das Ergebnis war erschreckend, man sieht einfach zu wenig. Seitdem hinterlässt jede meiner Methoden eine eindeutige Spur in den statischen Variablen ihres FBs, die den Aufruf belegt. Ich glaube, mittlerweile einen gangbaren Weg gefunden zu haben. Zyklische Funktionalität bleibt ganz traditionell im FB, Methoden nur für ereignisgesteuerte Vorgänge, z. B. bei Schrittwechseln einer Schrittkette. Dabei erledigt jede Methode ihren Job in einem einzigen Aufruf. Ich habe gerade mit der IBN eines Programms nach diesem Muster begonnen, mal sehen, wie sich das bewährt.

StructuredTrash schrieb:

Das Ergebnis war erschreckend, man sieht einfach zu wenig.

Zum Vergrößern anklicken....

Genau darin besteht heute oft die Problematik.
Die meisten Dinge werden an einer ordentlich programmierten Anlage in der Visu angezeigt und diagnostiziert.
Aber irgendwann tritt der Fall auf, dass nicht dierichtige Meldung auf der Visu erscheint und dann wird es spannend.
Der normale Instandhalter sucht quasi rückwärts.
Also welche Bewegung muß ausgeführt werden?
Welche Aktoren und Sensoren sind daran beteiligt?
Welches BMK geht auf welche SPS-Adresse?
Wo finde ich diese im SPS-Programm?
Wenn man sich dann durch x verschachtelte Bausteine graben muß, dann ist es seither schon ungemütlich.
Wenn man sich jetzt aber durch Objekte inkl. Vererbung quälen muß, dann kann ganz schnell Frust aufkommen.

Immer daran denken, dass wir Programme nicht zum Selbstzweck schreiben sondern damit der Kunde mit Anlagen Geld verdienen kann.

Gruß
Blockmove