TwinCAT am PC (WinXP) Timer (TP) läuft zu schnell

[ludi81]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe ein komisches Problem. Und zwar habe ich ein kleines Programm erstellt, welches ein Ausgang kontinuierlich ein und ausschaltet.
z.B Ausgang ist für 1 Sekunde high, dann für 1 Sekunde low usw.
Als Timer verwende ich zwei TP Bausteine.

Das ganze scheint ja zu funktionieren, aber obwohl ich t#1s verwende ist es keine Sekunde, sondern vielleicht 500 ms. Also mir kommt vor, dass das System keine Echtzeit hat. Wenn ich bei einem TP Baustein mir die Werte anzeigen lasse, sehe ich, dass die Startzeit immer um 2 Sekunden erhöht wird --> das stimmt also.
Wenn ich jetzt z.b die Timer auf 10 Sekunden stelle. Wird immer um 20 Sekunden erhöht (Anzeige), aber wenn ich mit der Uhr stoppe sehe ich, dass es nur zirka 5 Sekunden low und danach 5 Sekunden high ist.

Zum Testen habe ich noch einen anderen Rechner verwendet (alter Notebook), hier war es genau umgekehrt. Obwohl ich 1 Sekunde einstelle, dauert es hier etwa 2 Sekunden.
Kann mir hier jemand helfen? Was mache ich falsch?

LG Ludi

 

[h_matthias]

Guten Morgen

Am Besten wäre es, wenn Du einen Auschnitt aus Deinem Programm hier zeigen würdest.
So wird eine Hilfe sonst schwierig.

Matthias

 

[ludi81]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich glaube kaum das der Fehler im Programm ist, denn bei einer Steuerung (CX9010) stimmt die Zeit.

Aber vielleicht irre ich mich ja:
Prinzipiell habe ich den WARTEN block von folgendem Beispiel verwendet.
Beckhoff Information System - German

FUNCTION_BLOCK WARTEN(*Dieser Funktionsbaustein kann zum warten verwendet werden*)
VAR_INPUT
	ZEIT:TIME;
END_VAR
VAR_OUTPUT
	OK:BOOL:=FALSE;
END_VAR
VAR
	ZAB:TP;
END_VAR


	LD		ZEIT
	ST		ZAB.PT


	LD		ZAB.Q
	JMPC	marke


	CAL		ZAB(IN:=FALSE)
	LD		ZEIT
	ST		ZAB.PT
	CAL		ZAB(IN:=TRUE)
	JMP		ende


marke:
	CAL		ZAB


ende:
	LDN		ZAB.Q
	ST		OK
	RET

Verwenden tue ich es so:

zeitEin(ZEIT:=t#1s); enmalig
zeitEin(); kontinuierlich
zeitEin.OK -> Abbruchbedingung

Das gesamte Testprojekt ist im Anhang.

Danke für eure Hilfe
Ludi

 

[mkd]

Hi,

ich meine mich zu erinnern, das es etwas mit dem Powermanagement bei einem Notebook zu tuen hat.
Man konnte da etwas in der Windows Registrierung anpassen damit Timer laufen.

Mal bei Beckhoff anfragen, sonst kann ich morgen mal auf meinem Dienstrechner nachschauen. Ich hatte mir da mal etwas notiert.

Gruß

 

[PN/DP]

Als Timer verwende ich zwei TP Bausteine.

Ich habe kein TwinCAT, kann mit Deiner ZIP also nichts anfangen.
Wichtig wäre es, die Aufrufe Deiner 2 Zeitgeber zu sehen (in PLC_PRG ?).

Rufst Du auch 2 verschiedene Instanzen der TP-Bausteine auf? Oder rufst Du womöglich zweimal die gleiche Instanz des FB WARTEN auf?
Das von Dir beschriebene Verhalten ist typisch wenn ein Timer im Zyklus zweimal aufgerufen wird.

PS: Auch wenn der WARTEN-Baustein aus einem Beckhoff-Beispiel stammt - ich mag diese Art Programmierung mit Sprüngen und 3x CALL des TP überhaupt nicht. Ich würde den FB WARTEN etwa so schreiben:

FUNCTION_BLOCK WARTEN
VAR_INPUT
	ZEIT:TIME;
END_VAR
VAR_OUTPUT
	OK : BOOL;
END_VAR
VAR
	ZAB : TP;
	ZAB_EN : BOOL;
END_VAR

	LDN		ZAB.Q
	ST		ZAB_EN

	CAL		ZAB(IN:=ZAB_EN, PT:=ZEIT)

	LDN		ZAB.Q
	ST		OK
	RET

Harald

 

[ludi81]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Mkd,

wenn es dir keine Umstände macht wäre ich dir für deine Infos dankbar.
Wenn nicht, werde ich einfach mal bei Beckhoff anrufen.

Schöne Grüße

 

[ludi81]

Hallo Harald,

also mein Hauptprogramm sieht so aus wie im Bild.

In der Eingangsaktion "ein" steht:

out1 := TRUE;
zeitEin(ZEIT:=t#1s);

In der "ein" Funktion steht:

zeitEin();

In der Eingangsaktion "aus" steht:

out1 := FALSE;
zeitAus(ZEIT:=t#1s)

In der "aus" Funktion steht:

zeitAus();

Also hier habe ich keine Funktion doppelt verwendet. Ich kann es mir auch irgendwie nicht damit erklären, denn die Startzeit von TP geht ja richtig weiter, aber es ist einfach alles zu schnell.

Vielen Dank

 

[PN/DP]

Hmm, mit Grafcet/Ablaufsprache bei Codesys kenne ich mich nicht wirklich aus.

Wenn ich Dein Bild und Deine Erklärung richtig verstanden habe, dann werden Deine Zeitgeber (zeitEin, zeitAus) nur in dem jeweiligen Schritt aufgerufen ... hmm ... bedingte Bearbeitung von Timern ist so eine Sache, da muß man höllisch aufpassen, daß die Timer richtig funktionieren. Ist aber hinzukriegen, wenn es nicht anders geht. Deshalb also die "komische" Programmierung des FB WARTEN, wenn man partout keinen Start- bzw. Reset-Eingang herausführen will ... (ich finde diesen Beispielcode aber sowas von an der Praxis vorbei!!! :roll

Ich nehme mal an, die "Eingangsaktion" eines Schrittes wird nur einmal beim Aktivieren des Schrittes aufgerufen. Dann werden die Timer jeweils nur im Aktivierungszyklus zweimal aufgerufen und die Zeit wird um einen Zyklus zu kurz - aber nicht um eine halbe Sekunde.

Jetzt wäre es interessant zu wissen, wie die TP-Bausteine intern funktionieren. Was passiert, wenn die lange nicht aufgerufen werden? Ich schätze, die Timer laufen intern trotzdem weiter und wenn sie in der Eingangsaktion vermeintlich neu gestartet werden, ist in Wahrheit schon eine halbe Sekunde abgelaufen. Das würde das merkwürdige Verhalten bei Dir erklären.

--> Ich schätze, Du MUSST in Deinem Programm in jedem sequentiellen Schritt immer die gleiche Instanz von WARTEN benutzen (PS: nicht in Parallelschritten!). Also nur eine WARTEN-Instanz, nicht zeitEin() und zeitAus(). Und den Aufruf der WARTEN-Instanz in den Eingangsaktionen weglassen. Am besten die ganze Eingangsaktion weglassen.

Ich würde das ganze mal so ändern:

Im Hauptprogramm

VAR
	warte : WARTEN;
END_VAR

Funktion "ein" (hat keine Eingangsaktion)

out1 := TRUE;
warte(ZEIT:=t#1s);

Funktion "aus" (hat keine Eingangsaktion)

out1 := FALSE;
warte(ZEIT:=t#1s);

Verbesserung: Um ganz sicher zu gehen, daß der Timer im FB WARTEN beim ersten Mal und nach längerer Nichtbenutzung neu startet, würde ich den FB WARTEN sogar umschreiben und TON statt TP benutzen und ein Freigabe- oder Restart-Signal als INPUT oder IN_OUT herausführen. Dann kann man auch mehrere Zeitgeber-Instanzen benutzen und auch verschiedene Instanzen in Parallelschritten. Dann macht ein Neustarten der Zeitgeber in Eingangsaktionen Sinn.

Harald

 

[ludi81]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Harald,

ich habe alles genau so geändert wie du geschrieben hast, es hat aber immer noch das gleiche Problem. Da es ja bei einem CX9010 funktioniert, glaube ich dass es eher so was ist wie MKD geschrieben hat.
Oder wie auch hier beschrieben wird: http://www.sps-forum.de/beckhoff-co...ncat-echtzeit-ethernet-nicht-intel-karte.html
Bei mir ist es aber viel schneller, deshalb glaube ich, dass was mit dem Hyperthreading zu tun hat.
Weiß jemand wie ich das alles deaktivieren kann?

Danke

 

[Cassandra]

...ich finde diesen Beispielcode aber sowas von an der Praxis vorbei!!! :roll:...

*ACK*

Hallo Ihr,

Die Ampelschaltung ist wahrscheinlich aus dem ursprünglichen CoDeSys- Handbuch übernommen. Der Versuch war, in einem „kleinen Projekt“ alle Programmiersprachen aufzuführen. Das ist nicht einfach, könnte aber bestimmt eleganter umgesetzt werden.
Ganz bestimmt sollte man damit nicht den Aufbau für größere Projekte ableiten...

Zum Zeitproblem:
http://www.sps-forum.de/beckhoff-codesys-iec61131/23819-ton-1-sekunde-dauert-ca-3-sekunden.html

LG Cassandra

 

[ludi81]

Hallo Cassandra,
Ich habe aber gerade das andere Problem. Bei mir dauert eine Sekunde vielleicht 0.5 Sekunden. Und mein System ist nie ausgelastet.
Ludi

 

[ludi81]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Cassandra,

ich habe genau das andere Problem. Bei mir ist eine Sekunde vielleicht 0.5 Sekunden. Also zu schnell, nicht zu langsam. Bei meinem älteren Notebook ist es zu langsam nicht zu schnell. Ich werde ich am Abend noch einmal mit dem Powermanagement rumspielen.

Schöne Grüße

 

[Itus]

Hallo Zusammen, Hab letzthin genau das Gleiche festgestellt, jedoch mit Motion Bausteinen. Hab eine Anfrage an den Beckhoff Support geschickt, aber noch keine Antwort erhalten. Auf dem PC läuft es bei mir "real time" auf einem CX1020 dann schon. Hab mich etwas durch die InfoSys gelesen und bin auf folgendes gestossen. [h=1]TS1110 | TwinCAT Simulation Manager[/h] Der TwinCAT Simulation Manager ist ein Werkzeug zur einfachen Konfiguration einer Simulationsumgebung, das sich in die TwinCAT-Systemumgebung integriert. Er unterstützt das Erzeugen einer „virtuellen Maschine“, die in ihrem zeitlichen Verhalten einer realen entspricht. Ich gehe davon aus, dass dieses Supplement Abhilfe schaffen könnten. Gruss Itus

 

[ludi81]

Hallo Itus,

ich kann mir nicht vorstellen, dass man den TwinCAT Simulator Manager dafür braucht. Denn bei TwinCAT steht folgender Satz dabei:

Das Beckhoff-TwinCAT-Softwaresystem verwandelt nahezu jeden kompatiblen PC in eine Echtzeitsteuerung mit Multi-SPS-System, NC-Achsregelung, Programmierumgebung und Bedienstation. TwinCAT substituiert herkömmliche SPS- und NC/CNC-Steuerungen sowie Bediengeräte:
Hat sonst noch jemand eine Idee? ​

 

[Bl000b3r]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich dachte es ist bereits geklärt, dass ein Laptop durch sein Energiemanagment den takt dynamisch verwaltet und somit TwinCAt keine konstante zeitbasis hat ... ?

 

[mkd]

Zum Thema zu langsamer Timer / Powermanagement:

Wenn es zu Echtzeitproblemen bei Verwendung von Beckhoff TwinCAT kommt, kann es sein, dass das Power Management des Rechners zugreift und den Prozessor runtertaktet. Mit einem entsprechenden Eintrag in der Regedit kann man verhindern dass das Power Management greift.
AffintyMask bestimmt auf welchem Core TwinCAT läuft.
Die Idle Task sorgt für eine 100% Auslastung der CPU allerdings mit der Idle Priorität.
Beide Schlüssel müssen die gleiche Wertigkeit haben.

 

[ludi81]

Hallo MKD,

vielen Dank für diese Informationen.
Das löst das Problem bei meinem alten Rechner, dort wo die Zeit zu langsam war. Aber bei diesem Rechner funktioniert irgendwie die Kommunikation mit dem EtherCAT Koppler (1100) nicht. Er kann hier nicht kommunizieren.
Bei meinem schnelleren Notebook (Virtuelle Maschine in meinem MacPro). Hier funktioniert die Kommunikation mit dem Koppler, aber eine Sekunde ist in Wirklichkeit vielleicht 0.5 Sekunden.

Vielen Dank

 

[trinitaucher]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Simulation Manager ist, wie der Name schon sagt, ein extra Tool zum Aufbau einer Simulationsumgebung, um für Programme z.B. die Hardware simulieren zu können.
Hilft nichts bei dem Problem mit schwankender Echtzeit. Das liegt an der Hardware des PCs. Der Simulation Manager wäre genauso betroffen.

Es gibt wohl kaum noch PCs die out of the box mit TwinCAT die volle Echtzeitfähigkeit gewährleisten können. Das ist ja auch nen bisschen Know-How von Beckhoff, denke ich mal, dass deren eigene PCs mit TwinCAT lauffähig sind.

 

[PN/DP]

Bei all den "Echtzeit"-Problemen von Beckhoff möchte ich erinnern, daß in dem Problem hier nicht die Zeiten zu langsam ablaufen, sondern zu schnell. Ich bin nach wie vor der Meinung, die Ursache dafür steckt in dem Anwenderprogramm in der falschen Nutzung der TP-Timer (wegen der nur bedingten Ausführung und Auswertung in der Schrittkette).

Kann denn irgendwer mit Ahnung mal das Projekt aus Beitrag #3 testen und eine Aussage machen, ob es bei ihm läuft oder die gleichen Symptome hat?

Harald

 

[ludi81]

Hallo,

vielen Dank für eure Kommentare. Ich habe am Dienstag noch mit Beckhoff telefoniert und einiges erfahren.
Prinzipiell unterstützen sie keine Notebooks bzw. Virtuelle Maschinen.
Das Notebook reduziert aus Stromspargründen die Taktfrequenz der CPU --> dadurch wird es langsamer --> dieses Problem kann mit mit dem Idle Task (wie oben beschrieben) meistens lösen.
Virtuelle Maschinen reichen die RealTime Clock nicht als Hardware weiter, sondern simulieren sie. Dadurch kann es auch sein, dass der Timer schneller wird. Weiters werden die neuen Prozessoren auch kurzzeitig übertacktet.

Das Programm funktioniert übrigens einwandfrei, ich habe es mit einer Beckhoff Hardware getestet und es hat auf Anhieb funktioniert.

Danke noch einmal.