TwinCAT: zwei Buskoppler mit unterschiedlicher Zykluszeit

[haarry09]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich habe in einem SPS-Projekt zunächst eine Task (100ms) erstellt und Variablen daraus mit einem EtherCAT-Buskoppler verknüpft.
Nun habe ich eine zweite Task (1ms) erstellt und möchte dessen Variablen mit einem zweiten Buskoppler verknüpfen.

Sync Units wurden alle auf die neue Task gelegt, aber die Variablen bleiben immer in der PLC Instance des ersten Tasks und werden somit nicht so häufig aktualisiert wie gewünscht. Analogwerte ändern sich nur jeden 100. Zyklus. Veringere ich die Zykluszeit des ersten Tasks auch auf 1ms, dann werden diese auch entsprechend häufig aktualisiert.

Wo findet außerhalb der Sync Unit noch eine Zuordnung von Task/POU zu EA statt?

Viele Grüße
David

 

[Stadtranduser]

Analogwerte ändern sich immer nur nach der Wandlungzeit des AD Wandlers frühestens. Welche Analogkarte hast Du denn?
Ausserdem mussten zumindest in TC2 die entsprechenden Varoablen in der Hardware auch den entsprechenden Tasks zugeordnet werden. Es genügt nicht, die Varoablen einfach in der PLC in einem anderen Zyklus zu verarbeiten.

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sync Units wurden alle auf die neue Task gelegt, aber die Variablen bleiben immer in der PLC Instance des ersten Tasks und werden somit nicht so häufig aktualisiert wie gewünscht.

Ausserdem mussten zumindest in TC2 die entsprechenden Varoablen in der Hardware auch den entsprechenden Tasks zugeordnet werden.

Im TC3 funktioniert die automatische Erkennung, welche Variable zu welchem Task gehört eigentlich ganz gut - meiner Erfahrung nach. Ich würde noch mal die Aufrufpfade der Fast-Task-Variablen prüfen, dass die wirklich im schnellen Task gelesen werden, danach alles übersetzen und ggf. die TMC noch mal manuell neu einlesen.

Das man die Variablem beim TC3 so wie beim TC2 manuell dem PLC-Task zuordnen kann, wüsste ich nicht. Jedenfalls habe ich das bisher noch nicht gefunden.

Was die AD-Wandler betrifft, glaube ich nicht, dass die 100ms brauchen, vielleicht 2 oder 3ms.

 

[haarry09]

Die GVL war tatsächlich an den falschen Task verknüpft und die automatische Erkennung hat wohl nicht richtig funktioniert.
Die manuelle Zuweisung über das Attribut TcContextName hat nun geholfen.

Siehe:

Beckhoff Information System - German

Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbus

infosys.beckhoff.com

 

[Stadtranduser]

Was die AD-Wandler betrifft,

Spannung und Temperatur waren langsamer. Strom war schnell.

 

[PatrickSt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was mir letztens noch aufgefallen ist:
Wenn man Input-Variablen z.B. in Main_Fast anlegt, sie aber im Programm noch kein einziges mal nutzt, dann werden sie beim erstellen des Projekts nicht dem Task zugeordet, zu dem Main_Fast gehört, sondern landen automatisch im langsamsten Task, den es gerade so gibt. Erst nachdem sie im Projekt genutzt werden, sind sie dann im Fast_Task.

Das kann auch sehr verwirrend sein.

Ob das ein Bug oder Feature ist hab ich noch nicht rausgefunden.

 

[asci25]

Nicht der Ort, wo eine Variable deklariert ist, sondern der Aufruf der Variablen zählt. Du kannst addressbehaftete Slow-Task und Fast-Task Variablen im selben Baustein deklarieren. Erst der Task-Pfad des Aufrufes entscheidet, welchem Task es letztendlich zugeordnet wird. Der 1. Task ist dabei nur der Default-Task.
Das hat den Vorteil, das man in einen Baustein Bereiche für sowohl den Fast-Task als auch den Slow-Task haben kann. Das wiederum sind enorme Vorteile, wenn man richtig objektorientiert programmiert. Man kann richtige Objekte erstellen, die von mehreren Tasks durchlaufen werden und dafür die Einsprungpunkte mitbringen.

Das ist ein Feature. Auf keinen Fall ein Bug.

Wenn man allerdings exzessiv GVL's oder den Bausteintyp PRG für einfache Datentypen einsetzt, ist man noch nicht auf dem Weg der Objektorientierung - dann kann man den unschätzbaren Vorteil noch nicht so ganz sehen.

Bis z.B. Siemens oder die anderen solche Möglichkeiten bieten, werden wohl noch Jahre bis Jahrzehnte vergehen. Das war letztendlich der Grund, warum ich nur noch mit Beckhoff arbeite.

 

[oliver.tonn]

Nicht der Ort, wo eine Variable deklariert ist, sondern der Aufruf der Variablen zählt. Du kannst addressbehaftete Slow-Task und Fast-Task Variablen im selben Baustein deklarieren. Erst der Task-Pfad des Aufrufes entscheidet, welchem Task es letztendlich zugeordnet wird. Der 1. Task ist dabei nur der Default-Task.
Das hat den Vorteil, das man in einen Baustein Bereiche für sowohl den Fast-Task als auch den Slow-Task haben kann. Das wiederum sind enorme Vorteile, wenn man richtig objektorientiert programmiert. Man kann richtige Objekte erstellen, die von mehreren Tasks durchlaufen werden und dafür die Einsprungpunkte mitbringen.

Gilt das denn auch für I/O-Variablen? Kann ich mir im Moment schwer vorstellen, weiß es aber auch nicht. Darum ging es dem OP aber.

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gilt das denn auch für I/O-Variablen? Kann ich mir im Moment schwer vorstellen, weiß es aber auch nicht. Darum ging es dem OP aber.

... Du kannst addressbehaftete Slow-Task und Fast-Task Variablen im selben Baustein deklarieren. ...

Ich bezog mich auf adressbehaftete Variablen, das sind u.a I/O-Variablen. Ich wüsste auch nicht, warum das für die anderen Variablen relevant wäre, weil die kommunizieren ja auch nicht mit ihrer Umwelt.

Ich arbeite ständig mit unterschiedlichen Task's.

Eine GVL kann man nicht einer Task zuordnen - zumindest wüsste ich nicht wie. Und Bausteine können von mehren Tasks aufgerufen werden, siehe Eigenschaften, Methoden und Aktionen. Die bieten also auch keine zuverlässige Referenz auf den Task.

Es bleibt also nur der Aufrufpfad der Variable. Oder das Pragma.