Verhalten R_TRIG bei Start

[hbeck001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

erst einmal: Hallo! Habe bisher hier nur mitgelessen (und das immer sehr hilfreich gefunden ), aber jetzt bin ich in der Situation, selbst einmal etwas zu fragen:

Wie verhält sich bei Codesys ein R_TRIG beim "Start" der Steuerung, wenn dessen Eingang auf TRUE geklemmt ist?

Folgendes Beispiel:

g_status.trigOptik(CLK := g_IxOptischFrei);

(* TEST *)
IF g_status.trigOptik.Q THEN intOptikFlanken := intOptikFlanken + 1; END_IF

g_IxOptischFrei ist Öffner am (Hardware-)Eingang, also beim Einschalten bzw. Start der Steuerung auf TRUE.
Nach Start bzw. Einschalten wird intOptikFlanken = 1 gesetzt, also kommt der R_TRIG einmal, obwohl es keine Flanke gab.
Soll das so sein? Ich habe hier ein Steuerungssystem eines anderen Herstellers (kein Codesys), dessen Trigger sich bei Start anders verhalten, sie zählen bei Beispiel analog zu dem obigen erst bei der ersten "echten" Flanke.
Um ehrlich zu sein finde ich letzteres Verhalten bei einem Trigger eher angebracht. Oder mache ich bei Codesys etwas falsch?

Danke und Gruß,
Hans

 

[MSB]

Da R_TRIG laut Variablen in der Bibliothek nur normale Variablen verwendet,
also nicht von Haus auf Remanent (Retain) arbeitet, ist es ein ganz normales Verhalten, das im ersten Zyklus bei konstant anliegendem IN eine Flanke kommt.

Hier solltest du nun also die Instanz des R_TRIG in einen Remanenten Bereich verlegen!

VAR_RETAIN
myR_TRIG : R_TRIG ;
END_VAR

Mfg
Manuel

 

[trinitaucher]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Baustein R_TRIG ist doch eindeutig definiert:
http://infosys.beckhoff.com/index.p...clibstandard/html/tcplclibstandard_r_trig.htm
Es gibt einen internen Merker, der beim ersten Start auf FALSE steht. Wenn dieser Merker, sprich die ganze Funktion, nicht remanent gespeichert werden, erfolgt der erste Aufruf immer mit diesem Merker = FALSE.
Andernfalls müsste der Baustein ja selbst unterscheiden, ob es wirklich ein "erster Start" (Kaltstart) der Steuerung ist.

Wenn du die Flankendetektion beim Kaltstart verhindern willst, würde ich eine boolsche Hilfsvariable (First-Start-Bit) mit Initialwert = TRUE deklarieren, die am Ende des Codes auf FALSE gesetzt wird. Die dann als Bedingung am Eingang des R_TRIG auswerten.

 

[hbeck001]

Hmm, R_TRIG als Retain würde ja erst beim zweiten Start helfen... der Vorschlag hat mich aber auf folgende Idee für die Deklaration gebracht:

trigOptik : R_TRIG := (M := TRUE);

Und siehe da: jetzt tut es exakt wie bei der anderen Steurung Erst die erste "echte" Flanke am Eingang wird erkannt.
Sollte ja keine Probleme geben, oder?

 

[Werner29]

Wenn es dich nicht stört, dass diese Initialisierung nicht 61131-3-konform ist, dann darfst du das bei CODESYS so machen.

 

[hbeck001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du die Flankendetektion beim Kaltstart verhindern willst, würde ich eine boolsche Hilfsvariable (First-Start-Bit) mit Initialwert = TRUE deklarieren, die am Ende des Codes auf FALSE gesetzt wird. Die dann als Bedingung am Eingang des R_TRIG auswerten.

Verstehe ich nicht ganz: damit würde doch die ungewollte Flanke dann lediglich nicht beim ersten Zyklus nach einschalten kommen, sondern beim zweiten. Oder habe ich dich falsch verstanden?

 

[hbeck001]

Wenn es dich nicht stört, dass diese Initialisierung nicht 61131-3-konform ist, dann darfst du das bei CODESYS so machen.

Danke für die Bestätigung! Ja, momentan stört es mich nicht.

Kann ich generell davon ausgehen, dass "Konstruktionen", die nicht 61131-3-konform sind, über die sich aber CODESYS nicht beschwert, dann auch so funktionieren wie beobachtet?

 

[Werner29]

Na ja, da ich jeden Tag Fehler behebe und immer wieder feststelle, dass sich jemand genau auf diesen Fehler verlassen hat,
möchte ich an dieser Stelle keinen Blankoscheck ausstellen.
Wir geben uns jedenfalls viel Mühe, jede Änderung abhängig von der eingestellten Compilerversion einzubauen.
Das heisst, wenn man ein Projekt mit Version 3.5.3.60 so erstellt hat, dann sollte sich dieses Projekt in allen zukünftigen Versionen
gleich verhalten, wenn man 3.5.3.60 als Compilerversion einstellt.
Also wenn wir gezwungen sind, eine neue Fehlermeldung auszugeben, dann wird die nur für eine neue Compilerversion ausgegeben.

Wenn man 100% sichergehen will, muss man das Projekt mit der Version bearbeiten mit der es erstellt wurde.

 

[hbeck001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, klingt nachvollziehbar. Werde dann im Zweifelsfall einfach nachfragen.