Diverse Fragen zur PLC Zykluszeit und TC Basiszeit - TC2

O'Gigis · 7 Februar 2018

Thruser schrieb:
...
Bei der Zykluszeit von 0,1ms müßte die Gesamtzeit dann eigentlich 10,2ms sein. Auch dort kommen die beiden zusätzlichen Zyklen vor.
...
Gruß

Erstmal vielen Dank für die ausführliche Erläuterung! Mit den 10,2ms bin ich voll bei dir aber genau das ist momentan das Problem, es sind bei einer Zykluszeit von 0,1ms genau 10,0ms. Das kann man im TC Scope und in der Loggerausgabe auch gut am Zähler erkennen, die wird kontinuierlich in 100er Schritten hochgezählt (100 Zyklen a 0,1µs -> 10ms).

Ich habe gestern alles nochmals alles in einem separaten Projekt neu aufgebaut und da ist mir nochmals was aufgefallen was auch zuvor schon aufgetreten ist aber nicht weiter berücksichtigt wurde. Der 1. Zyklus verhält sich nochmals anders als alle weiteren nachfolgenden Zyklen:

Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 837 ms Loggerausgabe Zählerstand: 692
Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 827 ms Loggerausgabe Zählerstand: 592
Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 817 ms Loggerausgabe Zählerstand: 492
Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 807 ms Loggerausgabe Zählerstand: 392
Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 797 ms Loggerausgabe Zählerstand: 292
Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 787 ms Loggerausgabe Zählerstand: 192
Hint TCPLC.PlcAuxTask (801) 06.02.2018 14:19:02 777 ms Loggerausgabe Zählerstand: 92

Ab dem 2. Zyklus wird der Zähler immer in 100er Schritten hochgezählt, im 1. Zyklus erfolgt eine Ausgabe noch bevor die 100 Zyklen erreicht wurden. Dieses ist ebenfalls im Scope gut erkennbar und ist bei mir reproduzierbar. Nicht immer der gleiche Wert, bei meinem ersten Post (siehe Seite 1) beträgt der Zählerstand 97 bevor er anschliessend jeden Zyklus 100 hochzählt. Mein Jitter Warnung ist auf 100µs gestellt und hat nicht ausgelöst

Es bleibt merkwürdig

weißnix_ · 7 Februar 2018

Thruser schrieb:
Auch dort kommen die beiden zusätzlichen Zyklen vor.

Einspruch. Der Zyklenzähler sagt was anderes.

Thruser · 7 Februar 2018

Hallo,

bei dem zusätzlichen Zyklusbei der Timerauswertung kann es auch durch den Jitter dazu kommen das er nicht ausgeführt wird. Der zusätzliche Zyklus durch den benötigten Flankenwechsel für den Start ist aber durch den Programmaufbau gegeben.

Kannst Du sonst auch mal im Programm die Zykluszeit mitmessen? Da mußt Du dann aber die Funktion für µs aufrufen, nicht die ms.
neuer Wert = Zeit messen
alter Wert - neuer Wert
alter Wert = neuer Wert

Bei Scope Bild für 100µs finde ich komisch, daß die Variable i beim ersten Mal nach dem Wechsel von Flanke.in (-> 2Zyklen) und beim nächsten Mal vor dem Wechsel auf 0 gesetzt wird.

Gruß

/EDIT: und beobachte mal deinen Logger über einen längeren Zeitraum vielleicht bis 50 Zeilen ob sich da eventuell noch zusätzliche ms einfügen

O'Gigis · 7 Februar 2018

Ich habe den Logger schon über einen längeren Zeitraum beobachtet, 197 Zeilen genau. Wollte jetzt nicht alle hier posten

Es wird bis auf den ersten Zyklus der Zähler immer genau 100 hochgezählt, und da ich keine Jitter Warnung erhalten habe und die Zähler- Abweichung immer beim ersten Zyklus auftritt vermute ich hier mal keine Problem mit dem Jitter.

Ehrlich gesagt weiss ich gerade nicht welche Funktion du meinst wo ich die Zeit in µs messen soll, steh da gerade auf dem Schlauch

Um die Verwirrung perfekt zu machen, ich habe den Code mal weiter angepasst. Ich messe noch zusätzlich über die Time-Funktion die Zeit zwischen den Logger-Ausgaben

Code:

...

Timer_Ausgabe.IN     := TRUE;
Timer_Ausgabe.PT     := T#10ms;


IF Timer_Ausgabe.Q THEN
    Time_DIff := TIME() - M_Time_Diff;
    M_Time_Diff := TIME();
    Timer_Ausgabe.IN := FALSE;
    Text :=CONCAT(' Loggerausgabe Zählerstand: ',INT_TO_STRING(Zaehler));
    Text := CONCAT(Text,' Time_Diff: ');
    Text :=CONCAT(Text,TIME_TO_STRING(Time_Diff));
    ADSLOGSTR( msgCtrlMask := ADSLOG_MSGTYPE_HINT OR ADSLOG_MSGTYPE_LOG, msgFmtStr := '%s', strArg := Text);
END_IF


Zaehler := Zaehler+1;
IF Zaehler = 1000 THEN
    Zaehler := 0;
END_IF


Timer_Ausgabe();

...

Dann erhalte ich folgende Ausgaben:

...
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 83 ms Loggerausgabe Zählerstand: 795 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 73 ms Loggerausgabe Zählerstand: 695 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 63 ms Loggerausgabe Zählerstand: 595 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 53 ms Loggerausgabe Zählerstand: 495 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 43 ms Loggerausgabe Zählerstand: 395 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 33 ms Loggerausgabe Zählerstand: 295 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 23 ms Loggerausgabe Zählerstand: 195 Time_Diff: T#10ms
Hint TCPLC.PlcAuxTask (801) 07.02.2018 11:28:25 13 ms Loggerausgabe Zählerstand: 95 Time_Diff: T#10ms
...

Wie kann der Zähler 95 betragen und die gemessene Zeit über Timer() 10ms ??????

weißnix_ · 7 Februar 2018

Im ersten Zyklus kann es u.U. zu Zykluszeitüberschreitungen kommen. D.h. ich würde bei den ersten Zyklen sowas vermuten. Dadurch werden in den ersten 10ms einige Zyklen ausgelassen.
Sowas beobachte ich gelegentlich, wenn ich an einem CX9020 parallel mit dem Programmiergerät draufhänge, das speziell nach einem Programmneustart einige wenige Zykluszeitüberschreitungen angezeigt werden.

Zykluszeitüberschreitung heißt: Der Main-Zyklus konnte nicht im geplanten Taskzyklus ausgeführt werden. D.h. der nächste Taskzyklus verpasst seinen Starttrigger und wird erst im übernächsten "Zeitschlitz" ausgeführt.
Genaugenommen würde das in Deinem Fall die ersten 10 Taskzyklen betrefffen, sodass real nur 5 ausgeführt werden. So würde ich mir jetzt die 5 fehlenden Zyklen erklären.

O'Gigis · 7 Februar 2018

An für sich klingt deine Erklärung Plausibel! Wo kann ich denn sehen, dass eine Zyklusüberschreitung stattgefunden?

weißnix_ · 7 Februar 2018

Im Online-Reiter der entsprechenden SPS-Task (Systemmanager) unter dem Zeitdiagramm ist mE. der Zähler.

infosys schreibt dazu:
Wie kann man die Echtzeiteinstellung vornehmen und wie bemerkt man Last - Überschreitungen?

In den Systemeinstellungen (über das TwinCAT Symbol in der Taskbar erreichbar) kann die Echtzeitlast - Grenze eingestellt werden, dort ist auch die aktuelle Lastanzeige vorhanden.
Überschreitungen der eingestellten Lastgrenze führt dazu, dass die SPS - Programme nicht rechtzeitig zum nächsten Aufruf abgeschlossen sind. TwinCAT bietet eine Anzeige der genutzten und Einstellung der verfügbaren Rechenkapazität zur Systemeinstellung.
Zusätzlich kann ein SPS Programm so lange benötigen, dass es innerhalb der eingestellten Zykluszeit (Taskeigenschaften) nicht fertig wird: Es wird ein Zyklusaufruf "verspätet" ausgeführt, die Zykluszeitüberschreitung wird mittels Systemmerker angezeigt: eine Reaktion kann programmiert werden. Für Windows Programme kann eine Meldung generiert werden.

Bitte such mal nach den entsprechenden Systemmerkern, dann kannst Du das direkt in Deiner Loggerausgabe mit verwursten. Sofern sich das dann klärt ist für mich das 1ms Phänomen bei gleichem Programm eigentlich viel interessanter. Für mich war bisher noch keine schlüssige Erklärung dabei. Deshalb würde ich gerne mal wissen, an welchen Stellen in welcher Reihenfolge Du die Zykluszeit manipulierst. Für einen Zyklus zuviel hätte ich ja eine (schwache) Erklärung. Aber zwei Zyklen ziehen mir definitiv den Teppich weg...
Auch die Taskprioritätenliste ist interessant.

O'Gigis · 8 Februar 2018

Hm, ich weiss nicht genau wo ich suchen muss. Habe im TC System Manager diesen Reiter gefunden:

Da wird keine Überschreitung angezeigt. Baue den Systemmerker gerne in die PLC ein wenn du mir sagst wo ich den finde

Die Taskprioritätenliste ist folgende:

Code:

Priorität	Zyklus				               Task		       Kommentar
1			
2			
3				
4		'Boost Priority'		                       PLC Run-Time 1 'TON_Zyklus'
5	1.000 Standard (Task 0)		               PLC Run-Time 1 'TON_Zyklus'
6			
7			
8			
9		>Task 1<			                        PLC Run-Time 1 'TON_Zyklus'
10		>Task 2<			                        PLC Run-Time 1 'TON_Zyklus'
11		>Task 3<			                        PLC Run-Time 1 'TON_Zyklus'
12		Communication Task (Port 801)	        PLC Run-Time 1 'TON_Zyklus'
13		>Boost Priority<		                        PLC Run-Time 2
14		>Task 0<			                        PLC Run-Time 2
15		>Task 1<			                        PLC Run-Time 2
16		>Task 2<			                        PLC Run-Time 2
17		>Task 3<			                        PLC Run-Time 2
18		>Communication Task< (Port 811)	PLC Run-Time 2
19		>Boost Priority<		                        PLC Run-Time 3
20		>Task 0<			                        PLC Run-Time 3
21		>Task 1<			                        PLC Run-Time 3
22		>Task 2<			                        PLC Run-Time 3
23		>Task 3<			                        PLC Run-Time 3
24		>Communication Task< (Port 821)	PLC Run-Time 3
25		>Boost Priority<		                        PLC Run-Time 4
26		>Task 0<			                        PLC Run-Time 4
27		>Task 1<			                        PLC Run-Time 4
28		>Task 2<			                        PLC Run-Time 4
29		>Task 3<			                        PLC Run-Time 4
30		>Communication Task< (Port 831)	PLC Run-Time 4
30             >Communication Task< (Port 831)      PLC Run-Time 4

Prioritätsmanagment war zuerst auf Manuell und dann auf Automatisch gestellt.

weißnix_ · 8 Februar 2018

Ist implizit global definiert.
Findest Du online in der globalen Variablenliste.

SystemTaskInfoArr[1].cycleTimeExceeded (bool) sollte richtig sein. Schau einfach online unter Global vars-->SystemTaskInfoArr nach, was da so zur Verfügung steht.

O'Gigis · 8 Februar 2018

Tja, die Idee war gut und die Erinnerung setzt auch langsam wieder ein

Habe den Code abgeändert:

Code:

PROGRAM MAIN
VAR
	Zaehler: INT;
	Text 	: STRING;
	Timer_Ausgabe : TON;
	fCycleTime			: REAL;	
	idx					: BYTE;
	fbGetCurTaskIdx		: GETCURTASKINDEX;
	strSystemTaskInfo	        : SYSTEMTASKINFOTYPE;
	cycleTime				: UDINT;
	bError				: BOOL;
END_VAR

fbGetCurTaskIdx();
idx :=fbGetCurTaskIdx.index;
strSystemTaskInfo := SystemTaskInfoArr[idx];
cycleTime :=strSystemTaskInfo.cycleTime;
fCycleTime := UDINT_TO_REAL(cycleTime);


IF strSystemTaskInfo.cycleTimeExceeded THEN
	bError := TRUE;
END_IF


Timer_Ausgabe.IN 	:= TRUE;
Timer_Ausgabe.PT 	:= T#10ms;


IF Timer_Ausgabe.Q THEN
	Timer_Ausgabe.IN := FALSE;
	Text :=CONCAT(' Loggerausgabe Zählerstand: ',INT_TO_STRING(Zaehler));
	Text := CONCAT(Text,' Task Zykluszeit: ');[QUOTE][/QUOTE]
	Text := CONCAT(Text,REAL_TO_STRING(strSystemTaskInfo.lastExecTime));
	ADSLOGSTR( msgCtrlMask := ADSLOG_MSGTYPE_HINT OR ADSLOG_MSGTYPE_LOG, msgFmtStr := '%s', strArg := Text);
END_IF


Zaehler := Zaehler+1;
IF Zaehler = 1000 THEN
	Zaehler := 0;
END_IF


Timer_Ausgabe();

Bei bError habe ich einen Breakpoint gesetzt, der wurde nicht ausgelöst.

Die Logger Ausgabe sieht jetzt so aus:

Type Server (Port) Timestamp Meldung
...
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 707 ms Loggerausgabe Zählerstand: 993 Task Zykluszeit: 4
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 697 ms Loggerausgabe Zählerstand: 893 Task Zykluszeit: 3
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 687 ms Loggerausgabe Zählerstand: 793 Task Zykluszeit: 3
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 677 ms Loggerausgabe Zählerstand: 693 Task Zykluszeit: 5
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 667 ms Loggerausgabe Zählerstand: 593 Task Zykluszeit: 3
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 657 ms Loggerausgabe Zählerstand: 493 Task Zykluszeit: 4
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 647 ms Loggerausgabe Zählerstand: 393 Task Zykluszeit: 4
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 637 ms Loggerausgabe Zählerstand: 293 Task Zykluszeit: 3
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 627 ms Loggerausgabe Zählerstand: 193 Task Zykluszeit: 2
Hint TCPLC.PlcAuxTask (801) 08.02.2018 11:51:24 617 ms Loggerausgabe Zählerstand: 93 Task Zykluszeit: 3
...

Hinter Zykluszeit wird die Zykluszeit für den letzten Zyklus in Vielfachen von 100 ns angegeben.

Wenn ich es oft genug probiere kommt auch mal ein Versuch zustande bei dem der erste Zählerstand 100 beträgt ... tja, so langsam gehen einem die Ideen aus.

weißnix_ · 8 Februar 2018

berror auf Breakpoint is ja ganz schick, aber ich hätt es wohl auf einen Zähler verdrahtet.
Die Zykluszeit im Logger is ja auch ganz schick, aber interessiert Dich die letzte oder die höchste?
Meine ANfangsvermutung wäre ja, das es bei den ersten SPS-Zyklen zu unregelmäßigkeiten kommt - warum auch immer.

O'Gigis · 8 Februar 2018

Kann dir da nicht ganz folgen, wenn jetzt mehrere Zyklen durch Zeitüberschreitung ausgefallen wären wäre dadurch der Zähler verringert worden, das ist ja die Vermutung. An der Stelle hätte der Breakpoint auslösen müssen da über strSystemTaskInfo.cycleTimeExceeded dieses angezeigt wird. Über die Zykluszeit kann ich sehen, das keine Erhöhung im ersten Zyklus aufgetreten in dem der Zähler nicht 100 beträgt.

Unabhängig davon habe ich habe das Ganze mit dem Zähler nochmals gemacht, der Zähler zählt korrekt soll heissen es gibt keine Probleme mit den Ablauf der Zyklen - die laufen alle korrekt durch.

Das Problem liegt woanders und zwar beim Timer-Baustein.

Type Server (Port) Timestamp Meldung
...
Type Server (Port) Timestamp Meldung
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms Loggerausgabe Zählerstand: 97 Task Zykluszeit: 34 cylcleCount: 97
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms ETT#10ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms cycleCoun: 96
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms cycleCoun: 95
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms cycleCoun: 94
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms cycleCoun: 93
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms cycleCoun: 92
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 840 ms cycleCoun: 91
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 90
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 89
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 88
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 87
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#9ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 86
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#8ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 85
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#8ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 84
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#8ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 83
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#8ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 82
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms ETT#8ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 839 ms cycleCoun: 81
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 838 ms ETT#8ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 838 ms cycleCoun: 80
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 832 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 832 ms cycleCoun: 13
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 832 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 832 ms cycleCoun: 12
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 832 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 832 ms cycleCoun: 11
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 10
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 9
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 8
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 7
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#1ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 6
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#0ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 5
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#0ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 4
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#0ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 3
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#0ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 2
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms ETT#0ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 831 ms cycleCoun: 1
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 830 ms ETT#0ms
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 830 ms cycleCoun: 0
Hint TCPLC.PlcAuxTask (801) 08.02.2018 16:49:34 830 ms firstCycle: TRUE

...

Ich habe mir zu jedem Zyklus die abgelaufene Zeit beim Timer mit ausgegeben. Bereits nach 6 Zyklen wird mir eine abgelaufene Zeit von 1ms angezeigt - das ist definitiv nicht korrekt und der Grund für die Abweichung des Zähles bei der ersten Ausgabe!

Klärt aber immer noch nicht das unterschiedliche Ausgabeverhalten von 12ms und 10ms bei einer Zykluszeit von 1ms und 100µs. Nachdem was ich jetzt gesehen habe tippe ich doch ganz stark auf den Timer-Baustein als Ursache dafür!

weißnix_ · 8 Februar 2018

Sehr schön analysiert.
Das wäre jetzt der Punkt, mal den Beckhoff-Support ins Boot zu holen.
Möglicherweise behebt ein Twincat-Update das Problem.

Da Du ja offensichtlich massig Zeit hast könntest Du ja basierend auf den verschiedenen Systembasiszeiten einen eigenen Timer programmieren. Hat der das Problem auch ist die Basisfunktion kaputt. Als Basis wird ja vermutlich die Twincat-Systemzeit benutzt.

O'Gigis · 9 Februar 2018

Danke, werde den Support anschreiben. Ich dachte TC2 wird nicht mehr weiter supported also es kommen keine weiteren Updates?

Ich habe ja zuvor mal die Differenz zwischen den Ausgaben über die TIME() Funktion mit ausgegeben und der Zyklenzähler hat bei einem Stand von 95 Zyklen 10ms ausgebeben.

Diverse Fragen zur PLC Zykluszeit und TC Basiszeit - TC2

Das sieht also sehr danach aus, dass was mit der Bssiszeit nicht stimmt die dann wohl auch der Timer-Baustein verwendet. Ich denke ich brauche da nicht einen eigenen Timer-Baustein programmieren, sooooo viel Zeit habe ich nun auch nicht

oliver.tonn · 9 Februar 2018

Doch, es wird noch supported und es kommt noch mindestens ein Update, denn die Lösung des Problems mit dem Spectre/Meltdown Update von MS steht noch aus. Es werden ja auch immer noch SPSen mit TC2 verkauft.

O'Gigis · 9 Februar 2018

Bin ein paar Jahre draussen und mein letzter Stand war der, dass TC2 zwar weiter verkauft aber mit dem erscheinen von TC3 nicht mehr supported werden soll, also keine Updates mehr kommen. Nun gut, schauen wir mal was jetzt dabei raus kommt - ich werde berichten

Thruser · 11 Februar 2018

Hi,

war 'n paar Tage mit was anderem beschäftigt.

Bei den 1ms Zykluszeit kann ich mir das Verhalten wie weiter oben schon gezeigt erklären. Warum es sich dann bei den 100µs anders verhält nicht. 100µs ist ja auch schon sehr sportlich. Kenn mich mit Beckhoff nicht aus, habe eigentlich nur mit Wago oder Siemens 300 zu tun. Da arbeitet man ja eher im ms Bereich.

Bei 'ner Siemenssteuerung und mit den Siemenstimern wäre es was anderes, mit den IEC Timern müßte es sich dort aber auch wie bei den 1ms verhalten.

Beim normalen PC würde ich jetzt gucken, ob der Compiler eventuell Optimierungen vornimmt. Da müßte man jetzt mal bei Beckhoff oder 3S nachfragen.

Die Time Funkion löst ja leider nur in ms auf. Gibt es da keine Funktion die noch genauer auflöst? Gibt es villeicht eine Funktion die die Systemticks ausgibt?

Bei den 1ms könntest Du mal versuchen den Timer noch zusätzlich aufzurufen. Und zwar

IF Flanke.Q THEN
Flanke.IN := FALSE;
Flanke();
Flanke.IN := TRUE;
Flanke();
Text :=CONCAT(INT_TO_STRING(i),' Hallo');
ADSLOGSTR( msgCtrlMask := ADSLOG_MSGTYPE_HINT OR ADSLOG_MSGTYPE_LOG, msgFmtStr := '%s', strArg := Text);
END_IF

Aber vielleicht bekommst Du ja eine Antwort von Beckhoff.

Gruß

O'Gigis · 14 Februar 2018

N'Abend Zusammen

Das mit dem mehrmals aufrufen des Timers reduziert die Ausgabezeit von 12ms auf 11ms was nicht verwunderlich ist das der Timer beim Auslösen 2 mal in einem Zyklus aufgerufen wird.
Nach wie vor bleibt ungeklärt warum derselbe Code bei einer Zykluszeit von 1ms anders reagiert als bei einer Zykluszeit von 100µs. Habe noch nichts vom Support gehört, bin gespannt ob was kommt.

Wen es was Neues zu berichten gibt melde ich mich

Danke nochmals an Alle für die Hilfe und Unterstützung :s12:

O'Gigis · 16 März 2018

So, habe jetzt einen Antwort von Beckhoff erhalten:

Der TON-Baustein arbeitet mit dem Datentyp TIME, welcher eine Auslösung von 1 ms besitzt.
https://infosys.beckhoff.com/index..../9007201784156811.html&id=5932183810968498191

Somit wird die Startzeit auf "volle" Millisekunden gekürzt.
Hierdurch kommt die beoabachtete "Ungenauigkeit" bei Zykluszeiten < 1ms zustande.
In TC3 ist es möglich, mit den Baustein LTON nutzen, welcher auf Basis des Datentyps LTIME mit einer Nanosekunden-Auslösung arbeitet. Dieser ist ein hochauflösender Timer, u. a. für Zykluszeiten < 1ms.

https://infosys.beckhoff.com/index....plclibstandard_ton.htm&id=8907740595942748231
https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2529431947.html&id=

In TC2 werden wir diesen Baustein leider nicht anbieten.

Somit ist zumindest geklärt warum der Zählerstand zur Startzeit nicht immer 10 bis zum Ablauf der 1. ms des TON Bausteins beträgt.

Warum die Loggerausgabe bei einem eingestellten TON.ET = 10ms mit einer Zykluszeit von 1ms 12ms benötigt und mit einer Zykluszeit von 100us exakt 10.0 anstatt 10.2ms benötigt ist mir immer noch nicht klar. Ich sehe da keinen Zusammenhang zur "gekürzten" Startzeit, sieht das jemand anders und kann mir auf die Sprünge helfen?

Hack · 16 März 2018

Hallo,

ich habe es weiter vorne schon mal erwähnt. Du schreibst aus der Echtzeit (Kernel-Mode) über den ADS-Router in den Windows User-Mode. Dort bist du nicht mehr in der Echtzeit.

Soweit habe ich zumindest TwinCAT verstanden.

Grüße

Diverse Fragen zur PLC Zykluszeit und TC Basiszeit - TC2

Level-1

weißnix_

Guest

Level-2

Level-1

weißnix_

Guest

Level-1

weißnix_

Guest

Level-1

weißnix_

Guest

Level-1

weißnix_

Guest

Level-1

weißnix_

Guest

Level-1

Level-3

Level-1

Level-2

Level-1

Level-1

Level-2

Wir schützen deine Privatsphäre