Persistente Outputvariablen

[tuxwurst]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich habe hier ein Konstrukt im Kopf und frage mich, ob ich das so machen kann. Habe dazu nichts gefunden.
Die Idee ist, Persistente Statusvariablen zu kapseln, dass die nur auf definierte weise manipuliert werden können. also ungefähr so. Ich saug mir mal zu Anschauungszwecken ne statusID aus den Fingern:

FUNCTION_BLOCK SysStatus
VAR_INPUT
    //zum Variablen auslesen wird der code nicht ausgeführt.
    bExecute:                BOOL:=FALSE;

    //Nutzdaten
    addToStatusID:           INT;
    //...
END_VAR

VAR_OUTPUT PERSISTENT
    statusID: INT;
    //...
END_VAR
============================
//zum Variablen auslesen wird der code nicht ausgeführt.
IF NOT bExecute THEN
    RETURN;
END_IF

//manipuliere die Daten...
//statusID darf keine priemenzahlen beinhalten...irgendwas halt ;)

//bExecute zurücksetzen
bExecute := FALSE;

der Aufruf sähe dann so aus:

SysStatus(bExecute:=TRUE, addToStatusID:=3, [B]statusID=>[/B]);
IF SysStatus.statusID > 15 THEN                         //FB wird hier nicht ausgeführt (ist das mit dem bExecute eigentlich notwending?)
     //Juhuuuu! mach hier was...
END_IF

Wie seht ihr das? Brauche ich den Aufruf von statusID=> im Aufruf oder ist das Dank der persistenten Output Variablen überflüssig? Es geht natülich in Wahrheit um viel mehr als nur EINE Statusvariable.
Würdet ihr das Problem ähnlich lösen oder lieber völlig anders?

 

[PN/DP]

FB-Outputs müssen nicht beschaltet werden, sie müssen in ST beim Aufruf des FB auch nicht angegeben werden.
Es reicht zu schreiben: SysStatus(bExecute:=TRUE, addToStatusID:=3);

Wenn bei der Abarbeitung des FB den Outputs nichts zugewiesen wird, dann behalten die Outputs die Werte von der letzten Zuweisung bzw. von der Initialisierung.

Was Du mit dem PERSISTENT des/der Outputs erreichen willst und ob/wie das in Deiner speziellen SPS so wie gewollt funktioniert, kann man schlecht sagen ohne genauere Angaben von Dir.

Harald

 

[tuxwurst]

Zuviel Werbung?
-> Hier kostenlos registrieren

FB-Outputs müssen nicht beschaltet werden, sie müssen in ST beim Aufruf des FB auch nicht angegeben werden.
Es reicht zu schreiben: SysStatus(bExecute:=TRUE, addToStatusID:=3);

Danke für die Aufklärung.

Was Du mit dem PERSISTENT des/der Outputs erreichen willst und ob/wie das in Deiner speziellen SPS so wie gewollt funktioniert, kann man schlecht sagen ohne genauere Angaben von Dir.

Verstehe. Konkret geht es um eine Anlage mit Roboterarm, die Prüflinge hin und her trägt und in verschiedene Mess-Stationen einlegt bzw. entnimmt.

Die Befürchtung ist nun, dass nach einem Stromausfall die Anlage von vorn beginnt und dann versucht Prüflinge an vermeintlich leere Stationen zu legen. Daher sollten die Zustände der Stationen abgesichert werden, damit es nicht zu mechanischen Konflikten kommen kann.
Nun habe ich gelesen dass TwinCat(3) mit PERSISTENT markierte Variablen in einem Speicherbereich abgelgt, der auch nach einem Stromausfall seine Werte behält. Wenn ich das richtig sehe, funktioniert das auch bei der BK9100, die wir nutzen.

Die alternative Idee wäre, eine Datenbank mit einer USV daneben zustellen. Ich halte das für unnötigen Mehraufwand. Das obere Konstrukt war mein Lösungsansatz. Vlielleicht hat jemand noch eine bessere Idee oder das ist schon ganz ok so

 

[StructuredTrash]

Wirklich ein BK9100? Das ist doch nur ein Buskoppler, der gar keine Variablen hat.

Und wo immer der FB SysStatus wirklich steht: CodeSys/TwinCat können keine einzelnen Variablen eines FBs persistent speichern. Eine persistente Variable in einem FB macht den gesamten FB persistent. Kostet Speicher und beeinflusst natürlich auch das Startverhalten.

 

[tuxwurst]

Oh...Ich hab hier tatsächlich mit der Hardware was durch einander gebracht. Das müsste ich wohl dann noch mal abklären.

CodeSys/TwinCat können keine einzelnen Variablen eines FBs persistent speichern. Eine persistente Variable in einem FB macht den gesamten FB persistent. Kostet Speicher und beeinflusst natürlich auch das Startverhalten.

OK. Was wäre denn dein Alternativ Vorschlag zum FB? In einer FUN? Ich hatte nur gedacht, dass Objekt-ähnliche Datenkapslungen am besten in FBs funktionieren.

 

[plcSniffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deinen Ausgang statusID kannst du auf eine Globale Persistente Variabe legen. Beim Neustart der Steuerung liest du diese Variabe wieder in den FB zurück. Dafür bieten sich Properties (GET / SET) an.

 

[Guga]

zu Post #4 (Structured Trash).
Wenn das Schlüsselwort "Persistent" anstelle irgendwo im FB in der Typdefinition der Struktur aufgeführt wird dann sind nur die Instanzen der Variable und nicht der ganze FB der die Instanz definiert gespeichert.

So oder so... erst mal die HW-Basis klären incl. Info ob USV oder 1S-USV. Denn Persistent braucht Zeit sodass die Daten weggeschrieben werden.

Guga

 

[tuxwurst]

Dafür bieten sich Properties (GET / SET) an.

Das war ein ergiebiges Stichwort. Mal sehen, ob mich das da hin bringt, wohin ich hoffe. Danke.
[edit]aufgrund der komplexität der Statusvariablen bin ich jetzt statt properties bei methods hängen geblieben...alles fühlt sich auf einmal so nach heimat an. ich komm eher aus den objektorientierten höheren sprachen.[\edit]

So oder so... erst mal die HW-Basis klären incl. Info ob USV oder 1S-USV. Denn Persistent braucht Zeit sodass die Daten weggeschrieben werden.

Ja, ich weis... Mein Problem ist, ich befinde mich diese Woche noch im Blindflug. Der Kollege, der die Hardware zusammen gestellt hat, ist im Urlaub seit ich mich in die Anlage einarbeite und ran komme ich da bis dahin auch nicht :roll: Aber das wird sich dann am Montag hoffentlich schnell klären lassen. Die Zeit sollte ich tatsächlich nicht aus den Augen verlieren...Danke.