TC2 Zeiten für Signalwechsel aller Ausgänge ist Zykluszeitabhängig

Beiträge
5.752
Reaktionspunkte
1.201
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
wie heißt es doch, alle guten Dinge sind drei, hier kommt mein drittes und hoffentlich letztes Problem für heute.
Für einen anderen Test habe ich ein Lauflichtprogramm für ein CX5010 erstellt bei dem die Bits eines Words jeweils um ein Bit weiter rotieren. Was mir jetzt aufgefallen ist, war das je nach Zykluszeit die Zeitdauer die die CPU zum Umschalten aller Ausgänge braucht unterschiedlich lang ist. Mal ein Beispiel:
Im aktuellen Zyklus wird das Bit per ROL von 2 nach 3 verschoben, die Zykluszeit beträgt 1s. Nun geht an den Ausgängen zunächst Bit 2 auf false und ca. 500ms später geht Bit 3 auf true. Mir ist schon klar, dass das nicht unbedingt gleichzeitig passieren kann, aber das das so relativ lange dauert und die Zeit sich mit der Zykluszeit ändert ist für mich doch etwas unverständlich. Nicht das Missverständnisse aufkommen, ich meine nicht die Zeit die benötigt wird um ein Word komplett zu rotieren, die muss sich natürlich mit der Zykluszeit ändern, da pro Zyklus nur um ein Bit verschoben wird.

Von irgendwas mit Internetzugang gesendet.
 
Also wenn beide Ausgänge im selben Zyklus beschrieben werden, dann sollten sich doch die Ausgänge (so gut wie) gleichzeitig ändern?
Läuft den Bus jetzt auch mit 1s Zykluszeit? Da läufst du doch sogar in den Watchdog, oder nicht?

Kannst du den Code Ausschnitt mal posten?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Hack,
gerne, hier ist das Machwerk:
Code:
FUNCTION_BLOCK FB_Light
VAR_INPUT
 I_enDirection : EN_Direction;
END_VAR
VAR_OUTPUT
END_VAR
VAR
 wLightPos : WORD  := 16#0001;
END_VAR

Q_wLEDs := wLightPos;
xLED1 := wLightPos.0;
xLED2 := wLightPos.1;
xLED3 := wLightPos.2;
xLED4 := wLightPos.3;
xLED5 := wLightPos.4;
xLED6 := wLightPos.5;
xLED7 := wLightPos.6;
xLED8 := wLightPos.7;
xLED9 := wLightPos.8;
xLED10 := wLightPos.9;
xLED11 := wLightPos.10;
xLED12 := wLightPos.11;
xLED13 := wLightPos.12;
xLED14 := wLightPos.13;
xLED15 := wLightPos.14;
xLED16 := wLightPos.15;
IF I_enDirection = Forward THEN
 wLightPos := ROL(wLightPos, 1);
ELSIF I_enDirection = Backward THEN
 wLightPos := ROR(wLightPos, 1);
END_IF

Auf die Ausgangskarte (KL2809) ist Q_wLEDs gemappt jeweils mit einem um je Ausgang um 1 höheren Offset. Die Zeiten der Tasks in System Manager habe ich nicht geändert, lediglich im PLC Control habe ich die Zykluszeit unter Taskkonfiguration angepasst.
Die Binärvariablen sind für das TC Scope.

Gruß Oliver
 
Kann ich mir nicht wirklich erklären.

Es könnte sein, dass es echt am Bus liegt. Der Bus wird normalerweise über die verknüpfte Task getriggert. Normalerweise ist der Watchdog dort 100ms.
Ich hatte mit Zykluszeiten > 100ms auch schon Probleme.

Weiß aber nicht ob das die Lösung ist.

Grüße
 
Es könnte sein, dass es echt am Bus liegt. Der Bus wird normalerweise über die verknüpfte Task getriggert. Normalerweise ist der Watchdog dort 100ms.
Ich hatte mit Zykluszeiten > 100ms auch schon Probleme.
Selbst bei 100ms kann man noch halbwegs erkennen, dass erst der eine Ausgang aus und dann der andere an geht. Ich erwarte ja, wie gesagt, nicht, dass die Ausgänge gleichzeitig schalten, aber doch so schnell nach einander, dass man dies nicht mehr mit bloßem Auge erkennen kann und erst recht nicht, dass der Zeitraum sich mit der Zykluszeit ändert.
 
Das interessiert mich jetzt aber auch mal. Müsste sich ja einfach mit einem Speicher Oszi messen lassen. Wenn ich am Mo im Büro bin (und dran denke) kann ich das ja recht fix überprüfen. Bastel- und Spiel SPSen hängen genug an der Wand.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie erzeugst Du die 1s Wartezeit zwischen den Aufrufen des FB_Light?
Gibt es bei TC sowas wie eine Zuordnung des Prozessabbildes zu einer Task? Wie oft wird diese "E/A"-Task aufgerufen?
Besteht Dein Programm nur aus dem FB_Light oder gibt es noch wesentlich mehr Code? Schreiben womöglich noch weitere Programmteile auf die Ausgänge der Klemme?

Ich kenne Twincat nicht und ich kenne die KL2809 nicht, doch ich würde erwarten, daß alle Ausgänge der Klemme gleichzeitig schalten.

Harald
 
Bastel- und Spiel SPSen hängen genug an der Wand.
Das möchte ich mal von mir behaupten können, aber da ich das Ganze privat kaufe ist das Ge1ldsäckel recht schnell leer. An mein Testrack soll noch eine S7-314C mit DP und PN und noch 1-2 Beckhoff CPU mit TC2 und NCI und eine mit TC3, dazu noch etwas Peripherie und IOs., aber eins nach dem Anderen.
 
Hallo Harald,
Wie erzeugst Du die 1s Wartezeit zwischen den Aufrufen des FB_Light?
Es ist nicht genau eine Sekunde, die Zykluszeit des Tasks steht auf einer Sekunde, dem Task ist das Programm Main zugeordnet und das ruft den FB auf.
Gibt es bei TC sowas wie eine Zuordnung des Prozessabbildes zu einer Task? Wie oft wird diese "E/A"-Task aufgerufen?
Ich muss gestehen, dass dies Nebensächlichkeiten (also für mich) sind mit denen ich mich bei den Kunden nie beschäftigen musste und sie leider auch nie gelernt habe. Bei meinen Projekten arbeite ich immer "nur" zu. Es gibt im System Manager noch eine I/O Idle-Task, die steht aber bei 1ms und sollte, falls diese die I/Os steuert, schnell genug sein, es sei denn die Leistung meiner Augen hat sich plötzlich extrem erhöht und ich kann Wechsel kleiner 1ms erkennen. ;-)
Schreiben womöglich noch weitere Programmteile auf die Ausgänge der Klemme?
Es ist, wie gesagt, nur ein Spielprogramm. Es gibt im Main nur den einen FB Aufruf und sonst nichts.
...doch ich würde erwarten, daß alle Ausgänge der Klemme gleichzeitig schalten.
Ich auch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich hab das bei mir gerade getestet. Bei mir passiert das Ein und Ausschalten gleichzeitig, wie es soll.
Aber ich verwende EL Klemmen, habe keine KL hier.

Eventuell sonst in dr Konfig was verstellt?

Grüße
 
Ich muss gestehen, dass dies Nebensächlichkeiten (also für mich) sind mit denen ich mich bei den Kunden nie beschäftigen musste und sie leider auch nie gelernt habe. Bei meinen Projekten arbeite ich immer "nur" zu. Es gibt im System Manager noch eine I/O Idle-Task, die steht aber bei 1ms und sollte, falls diese die I/Os steuert, schnell genug sein, es sei denn die Leistung meiner Augen hat sich plötzlich extrem erhöht und ich kann Wechsel kleiner 1ms erkennen. ;-)

Ja, die Zuodnung E/A zu Task gibt es: Zu finden unter Systemmanager-->SPS-Konfiguration
So nur eine Task vorhanden, sind also die E/A dieser Task zugeordnet. Ich warte gerade noch auf eine fehlende Klemme, dann könnte ich in einer EL/BK/KL-Mischkonfiguration mal versuchen, Dein Problem nachzuvollziehen.
 
Die Ursache dieses Problems ist wohl auch die Ursache eines anderen Problems von mir das in dem folgenden Thread behandelt wird:
http://www.sps-forum.de/codesys-und...n-vom-cx5010-nur-im-freerun-angesprochen.html

Standardmäßig sind wohl die "Programme" für das IO-Handling der Standard-Task zugeordnet und diese hatte ich in diesem Beispiel auf 1 Sekunde gesetzt, was das System wohl nicht so mag. Lösche ich diese Task und erstelle selber welche wird das IO-Handling einer anderen zugeordnet, leider weiß ich nicht welcher und ob/wie ich das Handling einer bestimmten Task zuordnen kann.

Nochmals vielen Dank an alle die sich Gedanken zu dem Problem gemacht haben.

Nachtrag: Habe die Zuordnung von der weißnix_ geschrieben hatte gefunden, allerdings erfolgt diese ja quasi automatisch beim Verknüpfen der IOs zu Variablen. Kann man dies ändern? Soweit die Variablen in einem PRG oder FB sind ist das ja noch klar, dann muss man das PRG der entsprechenden Task zuordnen, aber wie sieht das bei globalen Variablen aus? Kann man die Zuordnung von diesen zu einer Task im Nachhinein noch ändern?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Zuordnung der E/A-Verknüpfungen kannst Du beliebig zu einer Task vornehmen, unabhängig von dem in der Task bearbeiteten Programm.
Die Verknüpfungen kannst Du per drag'n drop auch auf eine andere task verschieben.
Solange die Task, auf der die E/A's liegen schneller ist als die Task, die die Variablen benötigt, hast Du kein Problem (Nyquist-Shannon nicht ignorieren!)
 
Ob die Verknüpfungen dann im Programm global definiert sind oder nicht, spielt nur für die Programmlogik eine Rolle, nicht jedoch für das Einlesen. Das Einlesen des Prozessabbilds erfolgt immer im Zyklus der Zuordnung gemäß Systemmanager.

Das kann bei schwächeren Systemen durchaus ausgenutzt werden. Ich hatte da mal eine Anwendung auf einem CX9010, wo ich versehentlich einer zeitkritischen schnellen Task alle E/A's zugeordnet habe. Das Ergebnis waren Zykluszeitüberschreitungen. (Mein erstes TC-Projekt)
Es hat eine Weile gebraucht, bis ich verstanden hatte, warum mein Programm so Scheiße funktioniert.
Nachdem ich der schnellen Task nur die benötigten E/A's zugeordnet habe, war die Zykluszeit wie erwartet eingehalten worden.
 
Zurück
Oben