JobManager / JobHandler erzeugen

OOP

Level-1
Beiträge
49
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Es geht um ein ähnliches Thema wie in meinem letzten Post.
Wir wollen ein Konzept erstellen, mit welchem einer Maschine diverse Jobs übergeben werden können, welche dann von einem JobHandler abgearbeitet werden sollen.

Nun ist es so, wir haben Bspw. Den Job MoveCylinder(Desination:=Workposition);
Dann haben wir eine Job
MoveAxis(Position:= 100, Velocity:= 50);

Diese Jobs sind natürlich unbegrenzt, da aber ein allgemein gültiger JobHandler erzeugt werden soll, welcher in einer Bibliothek landen soll, müssen wir es irgendwie abstrakter hin bekommen.

Es schwebte mir etwas vor wie:
JobHandler.AddJob(Jobbezeichnung, Daten);
Aber wie soll man die Daten übergeben, also jeder Job hat ja eine andere Anzahl an daten.
Hat jemand eine Idee, oder sowas schon mal gelöst?

Danke schon mal.
 
Ich nehme einmal an, dass dein "JobHandler" von einem PC (oder ähnlich) mit Daten versorgt werden soll und selbst aber auf der SPS laufen soll ...
Dazu würden mir 2 Möglichkeiten einfallen, da eine SPS kein Pendant zu Collections oder List(of T) kennt :
- Du überträgst in einen Datenbaustein immer einen gleich großen Datenblock, der dann deinem Maximalausbau entspricht.
- Du überträgst in einen Datenbaustein einen Datenblock, der die Information über seine Gesamtlänge beinhaltet.
Der Datenbaustein selbst wird als eine Art FIFO abgearbeitet. Hierbei wäre dann z.B. das erste Byte eine Verschlüsselung des auszuführenden Befehls (also 01 = MoveCylinder und 47 = MoveAxis usw.) und dann kämen die Daten.
Bei einem FIFO bzw. dessen Umsetzung ist die generelle Handhabung allerdings sehr viel einfacher wenn alle Datzensätze die gleiche (also ein feste) Größe haben.

Vielleicht hilft dir das als Ansatz ja schon mal weiter ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der JobHandler kann theoretisch von überall verfüllt werden, aktuell wollen wir ihn allerdings erst einmal von der SPS selbst befüllen. Sprich, ich weiß jetzt schon, dass ich sagen wir x Jobs habe, welche nacheinander passieren sollen.
Nun würde ich diese einfach adden und der JobHandler würde sie nacheinander ausführen.
Dachte auch schon an so einen Ansatz wie du geschrieben hast, aber dann müsste ich die Daten wieder erst irgendwo erstellen und könnte sie nicht an eine Methode übergeben.
Was ich mir vielleicht gedacht hatte ist ein Interface zu übergeben. Dem FB hinter dem Interface übergibt man dann alle Daten und dieser kann sie dann dem JobHandler übergeben.
Dann hätte man allerdings den einheitlichen Job ausgelagert.
 
Naja ... von der SPS her hast du selbstverständlich mehr Optionen, was du in dein FIFO übergibst.
Wenn allerdings "später einmal" der eigentliche Ablauf von einer Art Bediener-Eingabe her kommen soll, mal ungeachtet von wo nun genau (PC oder ein wie auch immer geartetes Bediengerät), muss das Ganze neutral sein - du brauchst also eine Art Interpreter, der aus einem Coder heraus "versteht" welchen Befehl er nun wirklich ausführen soll. Von daher kam mein Vorschlag ...

Für einen Add eines FB-Aufrufes mitsamt seinen Parametern sehe ich hingegen im Moment keine Optionen. An dieser Stelle hat eine SPS, mal unabhängig vom Hersteller, doch einen anderen Fokus.
Aber auch unter .Net geht das auch nicht "mal eben so" zu machen ...

Gruß
Larry
 
Ich habe es jetzt mal konzeptionell so gelöst. Mal sehen, wie es meinen Kollegen gefällt.

Habe einen JobHandler, welcher wie sein Name schon sagt alle Jobs handelt und beinhaltet.
Dieser hat verschiedene Methoden, bspw. SetJobXy(Position);

Diese Methoden geben alle ein Interface vom Typ IJobHandler zurück.
Dieses Erwartet die Methode „AddJob“ des Fbs JobManager.
Dieser stößt dann nacheinander die Jobs an. Was sagt ihr dazu?

Die Jobs können also alleine durch den handler bedient werden, oder eben durch den Manager, welcher den Habdler füttert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie machst du das mit den Rückmeldungen, die es ja für jeden einzelnen Job geben muß, also z.B. dass die Position XY erreicht wurde, oder dass der Zylinder am INI XY angekommen ist? Wird das Alles bei der Übergabe in den Daten zum Job abgelegt und mit übergeben? Was passiert, wenn ein Job nicht korrekt ausgeführt wird, also ein Luftzylinder nicht in Endlage geht? Gibt es einene Reset-Job, um wieder in Grundstellug zu kommen oder löst ihr das irgendwie anders? Für eine Maschine, deren Arbeitsablauf flexibel gestaltet werden soll, kann ich mir das ganz gut vorstellen. Allerdings hätte ich das wahrscheinlich eine Stufe "tiefer" gelöst, indem ich jede mögliche Aktion (mit Variablenübergabe) ausprogrammiere und dann an den Händler eine Liste mit der Aktionsreihenfolge übergebe. Wird dein Code denn zu warten und zu beobachten sein? Liegt wahrscheinlich daran, dass ich eben nicht aus der Hochsprachenprogrammierung komme und mit diesen Konzepten in der SPS nicht so viel anfangen kann. Interessant ist dein Ansatz allemal. Berichte hier ruhig weiter, mich interessiert, wie du das am Ende hinbekommst.
 
Berichte hier ruhig weiter, mich interessiert, wie du das am Ende hinbekommst.

Mich auch. Wobei das Ende nicht die Fertigstellung von Job Handler/Manager am Schreibtisch ist, sondern der Abschluss der ersten IBN einer damit gesteuerten Maschine. Und da bin ich skeptisch, ob am Ende ein Plus unter dem Strich bleibt. Bei laufendem Programm wird nicht viel zu sehen sein, weil die Daten der Methoden temporär sind. Und Breakpoints und Einzelschrittbearbeitung verbieten sich in der Regel an einer laufenden Maschine. Auf jeden Fall müssen die Daten, welchen Weg sie durch das Interface- und Methodengewusel auch nehmen, am Ende in statischen Strukturen landen, damit man sehen kann, was passiert ist. Und diese Daten sollten auch eine Rückverfolgung ihres Weges erlauben.
Ein weiteres Problem ist, dass die Fähigkeit zum Online Change leidet, wenn beim Hinzufügen von Variablen nicht nur Daten verschoben, sondern auch noch zig Interfaceadressen nachgezogen werden müssen. Ich habe das gerade bei der IBN einer Maschine erfahren müssen, bei der ich die TwinCat PLC HMI, also die CodeSys Target Visu einsetze. Die läuft ja als IEC-Programm im Laufzeitsystem der SPS, und auch wenn ihr Quellcode im Dunklen bleibt, kann man wohl davon ausgehen, dass sie die OOP-Fähigkeiten von CodeSys 3 sehr intensiv nutzt. Als Ergebnis ist ein Online Change mit Verschiebung von Daten praktisch nicht mehr möglich, weil der Feldbus-Watchdog zuschlägt.
Diese Probleme waren vorhersehbar, und dass 3S und Beckhoff den Anwender damit alleine lassen, ist schon enttäuschend.
 
Der grundsätzliche Ansatz ist nicht schlecht (vom Gedankengang her) - ich sehe hier aber auch das Problem der Wartbarkeit des Endergebnisses.
Aber ...
Man kann ja schon das Eine oder Andere machen damit das Ganze ggf. durchschaubarer wird ...
Jede einzelne Funktionalität müßte eine eigene Funktion werden. Dies gibt ständig ihren aktuellen Status aus. Hier könnte man sich z.B. sehr schön einer Enumeration bedienen (da wir ja nicht von Siemens reden). Damit läßt sich dann alles abbilden (und sogar allgemeingültig) - also "inaktiv", "gestartet", "Timeout", "Zielposition erreicht", "Fehler xyz" etc.
Somit wird dann natürlich jedes Kommando zu einem eigenen Baustein, der dann möglicherweise wieder andere Bausteine beinhaltet.

Mal losgelösst von Hochsprache oder wie-auch-immer-Code - Hochsprache im eigentlichen Sinn haben wir mit SCL / ST ja schon in der SPS. Das, was der TE hier vorhat, ist von der Funktionalität nichts anderes als eine "dynamische" Schrittkette - nur mal ein bißchen anders angegangen. Man muß hierbei natürlich beachten, dass die Mutter des SPS-Programms (unabhängig vom Hersteller) die ZYKLISCHE PROGRAMMBEARBEITUNG ist. Somit muss der "JobHandler" sein FIFO mit der Einzelaufträgen halt entsprechend überprüfen und bei einem nicht gewünschten Zustand (unabhängig vom aktuellen Schritt) entsprechend verzweigen. Man könnte aber hierbei auch mittels Parameterübergabe schon mitteilen, ob ggf. anders als allgemein verzweigt werden soll ...

Ich halte diesen Ansatz auf Aggregate-Ebene für durchaus praktikabel (wenn entsprechend umgesetzt) - nicht allerdings auf Maschinenebene (wegen der ggf. notwendigen Fehlersuche mit dem Programmiergerät weil am Anfang eben halt noch nicht alles komplett abgefangen und/oder berücksichtigt ist).

Gruß
Larry
 
Ja wenn du es auf die Maschinen Ebene runter brichst, könnte man ja auch sagen ein Job ist eine teilschrittkette
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Laut 3s werden die interfacewerte bei einem onlinechange nicht verändert.

Da ich das kaum glauben konnte, habe ich mal gerade einen kleinen Test gemacht.
Zunächst einen FB A ohne und einen FB B mit einem Interface. FB-Adressen und Interface beobachtet, dann in FB A eine weitere Variable deklariert. Ergebnis: Nur der FB A wurde verschoben.
Dann eine zweite Instanz von FB B im MAIN deklariert, wieder Adressen beobachtet und danach im FB B eine zusätzliche Variable deklariert. Dann werden die FB B-Instanzen verschoben und auch die Interfaces nachgeführt.
Die Aussage von 3S stimmt also nur so halb.
 
So,
Das Thema ist wieder aktiv und geht weiter.
Die Grundlage ist ein BaseJob, welcher von jedem Job extebded werden kann.
Dieser Base Job beinhaltet unter anderem einen standardisierte Statemachine (haben die PackML statemachine verwendet).
Der JobHandler erwartet bei der Methode „AddJob“ eine Reference auf einen BaseJob. Dies mal so zur oberflächlichen Info.
Erste Tests verliefen sehr gut.
Man kann nun für verschiedene automatische Abläufe einen Job erstellen und die Automatik sieht dann nur noch so aus.

JobHandler.AppendJob(FirstJob);
JobHandler.AppendJob(SecondJob);
.... usw.

Sehr geil.
 
Zurück
Oben