Bit von Flanke auf Globale Variable

[Passion4Automation]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich programmiere in CS 2.3.
Ich habe eine Frage bzgl. Globaler Variablen.

Wenn ich jetzt im Task 1 ein Bit vom R_TRIG.Q auf eine Globale Variable verweise und diese Globale Variable im Task 2 verarbeiten will, klappt das nicht.
Der Grund ist, dass eine Flanke nur einen Zyklus lang True liefert und die Globalen Variablen erst im darauf folgenden Zyklus aktualisiert werden.
Soweit ist jetzt mein Wissensstand.

Das Problem löse ich zurzeit indem ich die Flanke mit einer Ausschaltverzögerung versehe z.B. 200ms. Dann funktioniert das.

Wie macht Ihr sowas? Gibt es bessere Ansätze oder mache ich grundlegend was falsch?

Danke.

 

[oliver.tonn]

Eine mögliche Lösung wäre die Globale Variable nicht direkt vom Flankenbaustein setzen zu lassen, sondern per If-Abfrage. Sobald Du die Variable im anderen Task bearbeitet hast setzt dieser sie wieder zurück.

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich löse dies immer mit einem Handshake. Der Sender (der den Impuls erzeugt) setzt ein Bit. der Empfänger liest das Bit und setzt ein Quitt Bit. Der Sender liest das Quitt Bit und löscht das Bit & das Quitt Bit. Somit weis der Sender ob sein Impuls angekommen ist und wann er einen neuen Senden kann.
Ich denke es geht um eine Kommunikation mit einer Visu. Dort implementiere ich das Ganze in einen FB und ein Word. Somit lassen sich 8 Impulse fehlerfrei übertragen. (Auch wenns mal etwas länger dauert)
Holger

 

[PN/DP]

Kommunikation zwischen verschiedenen Task oder Prozessen sollte immer zeitunkritisch mit Handshake realisiert werden.

Harald

 

[Heinileini]

Ich löse dies immer mit einem Handshake. Der Sender (der den Impuls erzeugt) setzt ein Bit. der Empfänger liest das Bit und setzt ein Quitt Bit. Der Sender liest das Quitt Bit und löscht das Bit & das Quitt Bit. Somit weis der Sender ob sein Impuls angekommen ist und wann er einen neuen Senden kann.

Wenn man - wie oliver.tonn vorgeschlagen hat - in Task2 das Bit rücksetzt, so kann man in Task1 auch sehen/abfragen, ob Task2 das Bit zur Kenntnis genommen hat - sofern das Bit nicht auch anderweitig "plattgemacht" wird.
Das (ohne eigenes QuittierBit) mag bei vielen Anwendungen schon als HandShake genügen ...

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man - wie oliver.tonn vorgeschlagen hat - in Task2 das Bit rücksetzt, so kann man in Task1 auch sehen/abfragen, ob Task2 das Bit zur Kenntnis genommen hat - sofern das Bit nicht auch anderweitig "plattgemacht" wird.
Das (ohne eigenes QuittierBit) mag bei vielen Anwendungen schon als HandShake genügen ...

Da hast du völlig recht. Wenn man sich aber die anderen Beiträge des TE ansieht geht es sicherlich um eine Kopplung zu anderem Gerät (Visu ...). Da ist eine Quitt besser.

 

[Passion4Automation]

Danke für Eure Unterstützung.
Die Methode mit dem Handshake finde ich gut.

Bei mir geht es um eine Gebäude Sps. Ich habe einen Logiktask (Sender) und einen Task wo der Dali Bus (Empfänger) drüber läuft.

Das muss ich mal ausprobieren.

 

[Passion4Automation]

Ich muss das Thema nochmal aufgreifen, da ich es noch nicht komplett verstehe.

Also ich übergebe ein Bit aus Rtrig. Q aus einem Task mit prio 7 auf eine globale Variable. Der Task in dem die GV verarbeitet wird, hat prio 6. Manchmal funktioniert die Übergabe und der Empfänger Task verarbeitet die Globale Variable, manchmal klappt es aber nicht.

Ich verstehe den Zusammenhang noch nicht ganz. Wie lange ist die Globale Variable auf true? Ich denke so lange bis der Zyklus beendet ist weil sie ja von einem Rtrig kommt?
Aber wenn das so, sollte doch das gar nicht funktionieren.

Könnte mir jemand kurz nochmal erklären wie lange die globalen Variablen die aus Flanken gebildet werden true sind und ab wann diese true sind.

Randinformation:

Task prio 6: Zykluszeit 50ms. AVG ca 6ms
Task prio 7: Zykluszeit 50ms. AVG ca 15ms

Danke

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Könnte mir jemand kurz nochmal erklären wie lange die globalen Variablen die aus Flanken gebildet werden true sind und ab wann diese true sind.

Ich beginne zu verstehen, dass ich Dich bisher nicht verstanden hatte.
Du hast in einer Task eine FlankenErkennung und willst das Ergebnis (den "ImpulsMerker") in einer anderen Task mit abweichender ZyklusZeit abfragen?
Nur in der anderen Task oder u.a. auch in der anderen Task?
Was spricht dagegen, die FlankenAuswertung in der Task vorzunehmen, in der sie auch abgefragt/wirksam werden soll?
Der ImpulsMerker steht in der Task mit der FlankenAuswertung genau 1 Zyklus lang an, wenn die FlankenAuswertung jeden Zyklus durchlaufen wird.
In einer anderen, schnelleren Task steht der ImpulsMerker deshalb länger an, als die ZyklusZeit der schnelleren Task beträgt: die Abfrage kann somit zu viele Flanken feststellen.
In einer anderen, langsameren Task steht der ImpulsMerker deshalb nicht so lange an, wie die ZyklusZeit der langsameren Task beträgt: die Abfrage kann somit Flanken "übersehen".
Also Deinen "ÜbergabeImpulsMerker" in der Task mit der FlankenAuswertung setzen und in der abfragenden Task direkt nach der Abfrage rücksetzen.
Wenn zeitweise häufiger Flanken erkannt werden, als sie in der anderen Task abgearbeitet werden können: evtl. statt eines Bits einen ZählWert über geben? Bei jeder erkannten Flanke Zähler + 1, bei jeder abgearbeiteten Zähler - 1?

 

[Passion4Automation]

Hi,

ich beginne es jetzt zu verstehen

Du hast in einer Task eine FlankenErkennung und willst das Ergebnis (den "ImpulsMerker") in einer anderen Task mit abweichender ZyklusZeit abfragen?
Nur in der anderen Task oder u.a. auch in der anderen Task?
Was spricht dagegen, die FlankenAuswertung in der Task vorzunehmen, in der sie auch abgefragt/wirksam werden soll?

Ja in der Task in der der Impulse erzeugt wird und ebenso in der anderen.
Ich steuere damit Bausteine an, die Impulse zum schalten brauchen, deswegen ist es aufwendig wenn ich ein dauerhaftes true auf eine GV lege und die flanke dann in den jeweiligen Tasks instanziere.

Ich denke das ich jetzt kapiert habe was in meinem Code falsch läuft.

Ich setze jetzt eine Aktion unter das PRG der anderen Task und mache das vom Code her so:
(*Am Zyklus Ende globale Var ruecksetzen*)
Gx_Zentral_Befehl:= false;

Im erzeugenden Task speichere ich die Flanke mit einer if Abfrage.

Ich glaube das ist der einfachste Weg und die globale Variable wird sicher im anderen Zyklus abgearbeitet.

 

[Heinileini]

In der Task, die nicht die FlankenAuswertung macht, würde ich ganz am Anfang der Task
1. den globalen ImpulsMerker in einen für diese Task relevanten ImpulsMerker kopieren und dann
2. den globalen ImpulsMerker löschen/rücksetzen
dann hast Du einen "lokalen" ImpulsMerker, der in dieser Task 1 Zyklus lang ansteht und kannst ihn in dieser Task auch an mehreren Stellen abfragen.

PS:
In der Task mit der FlankenAuswertung:
1. die FlankenAuswertung macht einen für diese Task "lokalen" ImpulsMerker, der in dieser Task abgefragt wird und
2. setzt den globalen ImpulsMerker, der nur für die Übergabe an die andere Task benutzt wird.

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Randinformation:
Task prio 6: Zykluszeit 50ms. AVG ca 6ms
Task prio 7: Zykluszeit 50ms. AVG ca 15ms

Aber wozu überhaupt 2 Tasks mit gleicher Zykluszeit?

 

[Passion4Automation]

Ich erstelle eine zweite variable für den zweiten Task, damit ich mir die interne variable vom Sender Task platt mache.

Bei den ZyklusZeiten habe ich mich verschrieben, der Task mit der prio 7 hat 35ms als Zeit eingestellt.

Der Task mit prio 6 ist mit 50ms so hoch eingestellt damit ich mit dem Wago Dali Konfiguratior ohne Verbindungs Abbruch drauf zugreifen kann.

 

[StructuredTrash]

Bei den ZyklusZeiten habe ich mich verschrieben, der Task mit der prio 7 hat 35ms als Zeit eingestellt.
Der Task mit prio 6 ist mit 50ms so hoch eingestellt damit ich mit dem Wago Dali Konfiguratior ohne Verbindungs Abbruch drauf zugreifen kann.

Das ist eine ungünstige Konfiguration. Es ist schon ein bisschen zu spät, um ihre Konsequenz im Detail zu prüfen, aber ich vermute, dass Dein Konstrukt ohne Handshake deshalb mal funktioniert und mal nicht. Irgendwann wird Task 7 nicht am Anfang ihres 35 ms-Taktes bearbeitet, weil Task 6 dann noch am Rechnen ist und aufgrund ihrer höheren Priorität keinen Wechsel zu Task 7 zulässt. Die höher priorisierte Task sollte immer auch die kürzere Zykluszeit haben.
Ansonsten kann ich holgermaik, PN/DP und Heinileini nur zustimmen: Keine Intertask-Kommunikation ohne Handshake. Man weiss nie, was einem in die Quere kommt. Auf dem Rechner laufen ja nicht nur Deine beiden Anwenderprogramme, das System verlangt auch ein Häppchen der Rechenleistung.

 

[Passion4Automation]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi StructuredTrash,

den task mit prio 7 kann ich auch auf 60ms hochstellen. Nichts desto trotz werde ich die GV, s zwischen den tasks mit Handshake realisieren. Die höherpriorisierte Task macht die anderen platt und lässt sie ihre Arbeit erst wieder an der Abbruchstelle weiter machen wenn sie fertig ist, so verstehe ich das.

Wenn jetzt task mit prio 6 nach 10ms fertig ist, wird dann noch bis 50ms gewartet, oder wird gleich nach 10ms bei Task mit prio 7 weitergearbeitet?
Das is mir noch nicht ganz klar.

Danke

 

[StructuredTrash]

Sobald Task 6 fertig ist, kommt Task 7 dran. Wenn bis 50 ms gewartet würde, käme Task 7 niemals zum Zug, weil dann ja Task 6 schon wieder an der Reihe ist.

 

[Passion4Automation]

OK dann schaukelt sich das ganze auf bis der Task prio 7 mal nur z. B. 5ms zur Verfügung bekommt. Der Flanken Befehl kommt nicht raus und wenn er doch raus kommt würde er die 35ms true sein, so das ihn der Task prio 6 verarbeitet.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK dann schaukelt sich das ganze auf bis der Task prio 7 mal nur z. B. 5ms zur Verfügung bekommt. Der Flanken Befehl kommt nicht raus und wenn er doch raus kommt würde er die 35ms true sein, so das ihn der Task prio 6 verarbeitet.

Herzlich willkommen in der Welt der Tasks
Normalerweise sollte man - wenn es eine andere Möglichkeit gibt - Tasks vermeiden.
Das Datenhandling zwischen verschieden schnellen Tasks ist oft aufwendiger als der eigentliche Job im Task.
Aber das hast du ja in der Zwischenzeit selber gemerkt
Also vielleicht mal überlegen, ob du deine Programmstruktur anpassen kannst.

Gruß
Blockmove

 

[Passion4Automation]

Herzlich willkommen in der Welt der Tasks

Na ja, wieder was dazu gelernt.

Ich habe noch einen dritten sehr langsam Task, prio 30 entdeckt. Diese Konstellation läuft halt nicht.
Ich habe auf Empfehlung für Dali und seriell Karten eine extra Task mit hoher prio angelegt, dachte das ist gut.

Danke an alle, jetzt bin ich schlauer und kann mein Programm umbauen.

 

[Blockmove]

Na ja, wieder was dazu gelernt.

Ich habe noch einen dritten sehr langsam Task, prio 30 entdeckt. Diese Konstellation läuft halt nicht.
Ich habe auf Empfehlung für Dali und seriell Karten eine extra Task mit hoher prio angelegt, dachte das ist gut.

Danke an alle, jetzt bin ich schlauer und kann mein Programm umbauen.

Dali läuft bei mir ganz normal im PLC Task.