TON Verhalten (rising edge)

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

Twincat 3 Engineering Build 4024.60
Twincat 3 Runtime Build 4024.7

Ich bekomme alle 2s ein Heartbeat Signal per MQTT welches ich auswerte.

// Evaluate heartbeat topic 
    ELSIF FIND(sTopicRcv,sMQTTTopicHeartbeat) > 0 THEN
            xHeartbeat:= TRUE;
    END_IF

Bevor ich das Topic subscribe und den Inhalt auswerte (handle_mqtt_messages, setze ich es auf false:

IF bEnableMQTT THEN
    xHeartbeat:= FALSE; // Reset heartbeat every cycle
  fbMqttClient.Execute(bEnableMQTT);
    handle_mqtt_messages(iDeltaTime);

Ich hab jetzt mal den Zähler genommen und quick and dirty einen Workaround daraus gestrickt:

IF xHeartbeat THEN
    iCount:= 1;
END_IF

// Evaluate heartbeat from nope
IF iCount <> 0 THEN
    TON_Heartbeat(IN:= NOT xHeartbeat, PT:= T#2M, Q=> xTwincatRestart);
END_IF;

Das Bit wird im statischen Bereich mit false initialisiert:

VAR_STAT
    xHeartbeat        : BOOL := FALSE;

Der TON ist auch im statischen Bereich

Wieso reagiert mein TON auf ein nicht vorhandenes rising edge Signal?

 

[Rabi]

Du hast beim IN Parameter ein NOT bHeartbeat anstatt des xHeartbeat.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

xHeartbeat war mal bHeartbeat..

 

[asci25]

Wieso reagiert mein TON auf ein nicht vorhandenes rising edge Signal?

TON reagiert schon mal gar nicht auf eine Flanke. Der braucht ein statisches Signal am Eingang IN, das länger auf true steht, als die Zeit am Eingang PT ist.

Was ich nicht sehen kann, ist die Aufrufreihenfolge, die bHeatbeat setzt und zurück setzt. Aber alles scheint bedingt zu sein. Da wird die Variable schon ab und zu mal mit false in den Timer gehen.

Nebenfrage, warum nimmst Du VAR_STAT statt VAR. Hat das irgend einen Grund?

 

[asci25]

Vielleicht willst Du aber eigentlich einen TOF nehmen.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

TON reagiert schon mal gar nicht auf eine Flanke. Der braucht ein statisches Signal am Eingang IN, das länger auf true steht, als die Zeit am Eingang PT ist.

Was ich nicht sehen kann, ist die Aufrufreihenfolge, die bHeatbeat setzt und zurück setzt. Aber alles scheint bedingt zu sein. Da wird die Variable schon ab und zu mal mit false in den Timer gehen.

Nebenfrage, warum nimmst Du VAR_STAT statt VAR. Hat das irgend einen Grund?

In der Library steht aber etwas von rising edge?


Mir geht es eigentlich nur um dieses Phänomen beim Neustart, wenn die Variable noch nicht ein einziges mal True war (Count = 0).

Der Timer, egal welcher muss mit xHeartbeat = FALSE abgefragt werden.

xHeartbeat wird TRUE gesetzt wenn ich über Mqtt das Topic abfrage. Davor wird es aber noch mal im Code auf FALSE gesetzt

xHeartbeat wird auch mit = FALSE intialisiert.

Das VAR_STAT war schon so vor meiner Zeit.

Aufrufreihenfolge:

FB_MAIN:

IF bEnableMQTT THEN
    xHeartbeat:= FALSE; // Reset heartbeat every cycle
  fbMqttClient.Execute(bEnableMQTT);
    handle_mqtt_messages(iDeltaTime);
    ...
END_IF

Innerhalb handle_mqtt_messages passier dann:

// Evaluate heartbeat topic
    ELSIF FIND(sTopicRcv,sMQTTTopicHeartbeat) > 0 THEN
            xHeartbeat:= TRUE;
    END_IF

Etwas später im FB_MAIN (damit kann ich verhindern aktuell, dass direkt beim Hochlauf der Timer schon aktiv ist):

IF xHeartbeat THEN
    iCount:= 1;
END_IF

// Evaluate heartbeat from nope
IF iCount <> 0 THEN
    TON_Heartbeat(IN:= NOT xHeartbeat, PT:= T#2M, Q=> xTwincatRestart);
END_IF;

 

[asci25]

Ruf mal den Timer ohne Bedingungen auf. Sonst kann der sich nicht zurücksetzen.

 

[DCDCDC]

Doch kann er, habe ich schon getestet

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Erstmal ist es bei bestimmten Bausteinen ein NoGo diese bedingt aufzurufen, da sich hier schnell Fehler einschleichen können, dazu gehören Timer- und Flankenbausteine.
Außerhalb der Bedingung den FB aufrufen und innerhalb nur noch deren Eingänge setzen.
Die Beschreibung ist etwas missverständlich stimmt aber im Grunde. Bei einer steigenden Flanke an IN wird der Timer gestartet und bei einer fallenden gestoppt. Sobald Du IN auf FALSE setzt und er vorher auf TRUE war, hast Du eine fallende Flanke.
Auch Dein geschildertes Phänomen ist keins, wenn man darüber nachdenkt. Woher soll der TON FB beim ersten Durchlauf wissen, welchen Zustand er vorher hatte? Das geht nicht, daher geht er davon aus, dass vorher der Eingang FALSE war und schon hast Du, wenn IN beim ersten Aufruf TRUE ist eine steigende Flanke.

 

[DCDCDC]

Dass es ein Nogo ist weiß ich selbst, habs ja als dirty workaround bezeichnet.

Das Problem ist, dass der Heartbeat von einem System kommt, welches nicht immer aktiv ist.. ergo würde sich die Runtime alle zwei Minuten neustarten, solange das System nicht läuft.. das will ich natürlich verhindern, quasi nach Hochlaufen den Timer ignorieren, bis das erste Heartbeat Signal kommt und damit/danach erst die Auswertung machen.

 

[oliver.tonn]

Dass es ein Nogo ist weiß ich selbst, habs ja als dirty workaround bezeichnet.

Das Problem ist, dass der Heartbeat von einem System kommt, welches nicht immer aktiv ist.. ergo würde sich die Runtime alle zwei Minuten neustarten, solange das System nicht läuft.. das will ich natürlich verhindern, quasi nach Hochlaufen den Timer ignorieren, bis das erste Heartbeat Signal kommt und damit/danach erst die Auswertung machen.

Dann nutz doch ein Flag als zusätzliche Bedingung, z.B. xFirstHeartbeat. Das wird beim ersten Heartbeat TRUE und als zusätzliche Bedingung für den Timer genutzt.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Merci, probiere ich mal aus die Tage

 

[samus]

Achtung bei VAR_Stat!!

Diese Variablen sind für alle Instanzen dieses Bausteins identisch. Einfach gesagt ein VAR_Global, einfach nur für diesen Typ Bausteine.
Wenn du mehrere Instanzen dieses Bausteins hast, können durchaus solche Phänomene auftreten.

Infosys

Gruss Samus

 

[DCDCDC]

Baustein hat nur eine Instanz, habs jetzt wie von @oliver.tonn angestossen umgesetzt

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Baustein hat nur eine Instanz, habs jetzt wie von @oliver.tonn angestossen umgesetzt

Das mit dem STAT hatte ich übersehen.
Warum nutzt Du diese Deklarationsform?
Bei Siemens gibt es STATIC und TEMP, aber das Siemens STATIC entspricht nicht dem STAT im Codesys Universum, hier verhalten sich alle innerhalb von VAR/END_VAR deklarierten Variablen bei FBs und PRGs wie Variablen die bei Siemens unter STATIC deklariert wurden.

 

[DCDCDC]

Das mit dem STAT hatte ich übersehen.
Warum nutzt Du diese Deklarationsform?
Bei Siemens gibt es STATIC und TEMP, aber das Siemens STATIC entspricht nicht dem STAT im Codesys Universum, hier verhalten sich alle innerhalb von VAR/END_VAR deklarierten Variablen bei FBs und PRGs wie Variablen die bei Siemens unter STATIC deklariert wurden.

Das war schon vor meiner Zeit so drin