FB zum triggern von Umschalt-Variablen in anderen FB verwenden

[urlicht]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo verehrte Wissensgemeinde,
Da ich überwiegend Autodidakt in Sachen SPS bin, stehe ich mal wieder vor einem Verständnisproblem. Unser Leitsystem (iFix) tut sich wegen der asynchronen Übertragung schwer mit der Funktion "Tasten", wie es sie in der Visu-Entwicklung gibt. Die Anbindung ans PLS erfolgt über CoDeSys-OPC-Server.
Wegen der oben beschriebenen Eigenart verwende ich BOOL-Variablen zum Umschalten (Toggle). Diese werden bei Bedarf im Anwenderprogramm Flankengetriggert verarbeitet und nach der Erkennung zurückgesetzt. Ich habe mir dazu einen fbTastTrig geschrieben, der auch soweit funktioniert, sofern er beispielsweise wie im Anhang zusehen in einem Programm aufgerufen wird.
Die Variablen sind übrigens in einer GVL definiert, ("GVL_W" für "globale Variablen sschreiben").
Nun möchte ich den fbTastTrig in anderen FB verwenden. Als Beispiel habe ich mal einen fbTest angelegt. Hier soll ein BOOL-Eingang intern per TastTrig verarbeitet werden und zur Kontrolle gezählt werden.
Leider funktioniert das nicht und ich verstehe nicht recht, warum, bzw. wie ich zum Ziel komme. Fernziel ist, das Flankentriggern in vielen meiner Standard-FB zu implementieren.
Ich hoffe auf Denkanstösse und Ideen. Danke im Voraus.

 

[Heinileini]

Die FlankenMerker (z.B. fbTastTrig_0) müssen ihren Inhalt bis zur Abfrage im nächsten Zyklus beibehalten. Temporäre (lokale) Variablen sind ungeeignet.

PS:
Was meinst Du mit "Die Variablen sind übrigens in einer GVL definiert, ("GVL_W" für "globale Variablen schreiben")."? Welche Variablen? Andere Variablen, die nur "zufällig" denselben Namen haben?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

In Deinem fbTest_0 wird nicht der InOut "In" verwendet sondern eine lokale Variable "In_test". Die beim Aufruf an fbTest_0.In angeschaltete Variable i_toggle_fbtest hat keinen Einfluß auf den fbTastTrig
Oder was genau meinst Du mit "funktioniert nicht"?

Warum eigentlich so umständlich R_TRIG und RS verwenden?
Wenn Du in Deinem fbTastTrig den Eingang sowieso immer rücksetzt, dann reicht es doch, den Eingangswert an den Ausgang (Imp) zu kopieren und danach den Eingang (Ein) rückzusetzen.
Ich weiß nicht wie das in Codesys aussieht ... ich meine es etwa so:

    +------+
Ein-| MOVE |-Imp
    +------+

    +------+
  0-| MOVE |-Ein
    +------+

Harald

 

[urlicht]

Hallo Heinileini,
Danke für Deine Antwort. Zunächst zu den GVL: Wie aus den Screenshots hervorgehen sollte, sind in den fbTastTrig und fbTest die Variablen lokal definiert. Beim Aufruf von fbTest in PLC_PRG verwende ich globale Variablen, die sowohl in der Symbolkonfiguration, als auch in der Persitent-Konfiguration deklariert sind. Namensgleichheit mit lokalen Variablen habe ich bewusst vermieden.

Temporäre (lokale) Variablen sind ungeeignet.

Auch hier fehlt mir scheinbar noch das Verständnis. Ein flankengetriggerter Impuls, z.B. mit R_TRIG erzeugt doch nach meinem Verständnis ohnehin erst im Zyklus nach dem Zustandswechsel am Eingang seinen Impuls. Dann halt für genau einen Zyklus. Hier verstehe ich nicht ganz warum das lokal nicht funktionieren sollte. Wenn ich einen fbTastTrig direkt im PLC_PRG aufrufe und mit globalen Variablen füttere, funktioniert es ja auch. Erst, wenn ich den fbTastTrig innerhalb des fbTest verwende, funktioniert es offensichtlich nicht nach außen. Wie könnte denn dann eine Lösung aussehen?
Grüße

 

[oliver.tonn]

Die FlankenMerker (z.B. fbTastTrig_0) müssen ihren Inhalt bis zur Abfrage im nächsten Zyklus beibehalten. Temporäre (lokale) Variablen sind ungeeignet.

Äh Heinileini, kann es sein, dass Du FC und FB verwechselst? Beim FC (Funktion) geht nach dem Aufruf alles wieder auf Anfang, aber doch nicht bei einem FB (Funktionsblock).
Hier ist es wie Harald schreibt, der TE verwendet die falsche Variable.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch hier fehlt mir scheinbar noch das Verständnis. Ein flankengetriggerter Impuls, z.B. mit R_TRIG erzeugt doch nach meinem Verständnis ohnehin erst im Zyklus nach dem Zustandswechsel am Eingang seinen Impuls. Dann halt für genau einen Zyklus. Hier verstehe ich nicht ganz warum das lokal nicht funktionieren sollte. Wenn ich einen fbTastTrig direkt im PLC_PRG aufrufe und mit globalen Variablen füttere, funktioniert es ja auch. Erst, wenn ich den fbTastTrig innerhalb des fbTest verwende, funktioniert es offensichtlich nicht nach außen.

Der Impuls (der sog. "ImpulsMerker"), also das "Ergebnis" von R_TRIG darf durchaus in eine lokale Variable geschrieben werden, nicht jedoch das "Gedächtnis" der R_TRIG-Funktion, der sog. "FlankenMerker". R_TRIG kann die Flanke nur dann detektieren, wenn der Zustand der auf Flanke zu prüfenden Variablen noch vom vorausgehenden Zyklus zum Vergleichen mit dem aktuellen Zustand zur Verfügung steht.
Ob es sinnvoll ist, sei dahingestellt: Du kannst natürlich eine globale Variable in eine temporäre kopieren und die temporäre als FlankenMerker benutzen, aber nur, wenn Du dann auch den aktuellen Zustand der temporären wieder in die globale zurück kopierst.
Was meinst Du mit "funktioniert es offensichtlich nicht nach außen"?

@Oliver
Ich habe mich weder auf FC noch auf FB bezogen, sondern nur allgemeingültig gesagt, dass ein FlankenMerker seinen Zustand bis zum nächsten Aufruf unverändert beibehalten muss und, dass deshalb temporäre Variablen ungeeignet sind. Diese Bemerkung mag überflüssig gewesen sein, aber in diesem Forum konnten wir immer wieder erleben, dass das Verständnis der FlankenErkennung immer wieder an genau diesem Aspekt scheitert.

 

[oliver.tonn]

Kann es sein, dass Du eher im Siemens-Bereich unterwegs bist Heinileini? So etwas wie einen Flankenmerker wie bei Siemens, der außerhalb des FBs noch als Variable selber angelegt werden muss gibt es im Codesys-Universum nicht. Solange der Flanken-FB nicht in einer Funktion deklariert wurde gibt es nichts zu beachten, außer das die Eingangsvariable natürlich bei jedem Aufruf aktuell sein muss.

 

[PN/DP]

Temporäre (lokale) Variablen sind ungeeignet.

Auch hier fehlt mir scheinbar noch das Verständnis.

Temporäre Variablen werden unter VAR_TEMP deklariert/angelegt. Diese Variablen können sich nichts bis zum nächsten Aufruf merken, weil nach dem Bausteindurchlauf der belegte Speicherplatz für die Verwendung durch andere Programmteile freigegeben wird. (Je nach Programmiersystem werden diese Variablen bei jedem neuen Aufruf des Bausteins neu initialisiert, oder haben einen unbestimmten Inhalt.)

Ein flankengetriggerter Impuls, z.B. mit R_TRIG erzeugt doch nach meinem Verständnis ohnehin erst im Zyklus nach dem Zustandswechsel am Eingang seinen Impuls.

Das ist falsch. Der Ausgang Q zeigt sofort nach Aufruf des R_TRIG den Wechsel zum 1-Zustand des Eingangs CLK an.

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann es sein, dass Du eher im Siemens-Bereich unterwegs bist Heinileini? So etwas wie einen Flankenmerker wie bei Siemens, der außerhalb des FBs noch als Variable selber angelegt werden muss gibt es im Codesys-Universum nicht. Solange der Flanken-FB nicht in einer Funktion deklariert wurde gibt es nichts zu beachten, außer das die Eingangsvariable natürlich bei jedem Aufruf aktuell sein muss.

Du hast ja sooo Recht Oliver, ich bin definitiv Siemens-geschädigt - aber tätig bin ich nicht einmal mehr im Siemens-Bereich.
Man sollte schon etwas genauer hinsehen, dann wäre sogar mir klar geworden, dass es weder einer vorgefertigten FlankenErkennung noch eines SR-FFs bedarf.
Ein := Imp;
Imp := 0;
hätte schon genügt - ganz ohne KopfZerbrechen über jegliche "explizite" FlankenMerker.

Deine Ausführung über die automatisch richtige FlankenMerkerVergabe bei CodeSüß habe ich leider nicht verstanden - muss mich da mal ein Bisschen einlesen . . .

Gruss, Heinileini

 

[oliver.tonn]

Hallo Heinileini,
kein Problem, dafür ist Siemens für mich (leider) immer noch ein Buch mit sieben Siegenln. Ich muss endlich mal wieder Zeit finden für meinem Siemens-Testaufbau.
Zu Deinem Verständnisproblem versuche ich mal Licht ins Dunkel zu bringen. Soweit ich das richtig sehe muss bei Siemens nicht nur ein Flanken-FB instanziert werden, sondern auch eine Variable deklariert werden in der der vorherige Zustand abgelegt wird. Wenn man diese nun als TEMP-Variable deklariert funktioniert die Flankenerkennung nicht, da die Variable in jedem Zyklus ihren alten Wert vergisst. Im Codesys-Universum ist dies nicht so, da gibt es auch die Trennung zwischen FB und Daten über DBs wie bei Siemens nicht. Die Daten zu einem FB (und auch FC) sind in diesen integriert. Ein Flankenbaustein muss deshalb auch nur mit dem auszuwertenden Signal gefüttert werden und gibt an seinem Ausgang für einen Zyklus aus, dass einen Flanke erkannt wurde. Dies geschieht, wie Harald schon richtig schrieb, direkt nach dem Aufruf des FBs im selben Zyklus. Die Variable in der der vorherige Zustand des Eingangs gespeichert wird (der Flankenmerker) wird vom Entwickler des FBs deklariert und ist in diesen integriert.
Den einzigen Fehler den man machen kann ist, den Flanken-FB ohne irgendwelche Tricks in einer Funktion zu deklarieren, das würde dann tatsächlich nicht funktionieren, weil eine Funktion bei jedem Aufruf zurück auf Anfang geht.