# Beckhoff - Problem mit ADS-DLL (Visual c++)



## Beta6 (23 September 2008)

Hallo,
ich versuche zur Zeit per ADS-DLL einen Wert von meiner EL3702 (AD-Wandler) einzulesen und ihn auf der EL4732 (DA-Wandler) auszugeben. Dieser Vorgang soll alle 50µs ausgeführt werden (So ist auch die Zykluszeit im System Manager von Beckhoff eingestellt).

Nun habe ich folgendes Problem:
ich habe mit einer Notification-Funktion (AdsSyncAddDeviceNotificationReq) ein Callback-Programm aufgerufen, dass zuerst den Wert vom AD-Wandler auslesen und danach auf der EL4732 ausgeben soll. 
Der Wert wird ohne Probleme ausgelesen, doch beim Ausgeben kommt es zu einer sehr starken Verzögerung (circa 1s) und ein ADS-Fehlercode erscheint der besagt "timeout elapsed". Dann wird der Wert jedoch trotzdem ausgegeben. 

Folgendes habe ich ausprobiert:
 - Wenn ich die Ausgabe-Funktion einzeln ausführe funktioniert sie   
    einwandfrei und schnell.
 - Wenn ich das komplette Programm ohne die Ausgabe-Funktion starte 
    funktioniert auch alles 

Deshalb verstehe ich nicht, warum ich einen Timeout bekomme wenn ich die Ausgabe-Funktion mit in das Callback-Programm kopiere. 

Kann es sein, dass das Callback-Programm an die eine Variable (in meinem Fall die des AD-Wandlers) gebunden ist und deshalb es problematisch ist in ihm die Variable des DA-Wandlers anzusprechen? Wenn dem so sein sollte wie erreiche ich dann diesen Zylkus von 50µs vom möglichst schnellen einlesen und ausgeben? 
Naja war nur eine Vermutung, vielleicht habt ihr ja eine Idee, woran es liegen könnte. Für den Fall, dass es ein programmier-technisches Problem ist, habe ich den Quellcode in den Anhang als .doc-Datei kopiert.







*@font-face 	{font-family:Calibri; 	mso-font-alt:"Century Gothic"; 	mso-font-charset:0; 	mso-generic-font-family:swiss; 	mso-font-pitch:variable; 	mso-font-signature:-1610611985 1073750139 0 0 159 0;}  /* Style Definitions */  p.MsoNormal, li.MsoNormal, div.MsoNormal 	{mso-style-parent:""; 	margin-top:0cm; 	margin-right:0cm; 	margin-bottom:10.0pt; 	margin-left:0cm; 	line-height:115%; 	mso-pagination:widow-orphan; 	font-size:11.0pt; 	font-family:Calibri; 	mso-fareast-font-family:Calibri; 	mso-bidi-font-family:"Times New Roman"; 	mso-fareast-language:EN-US;} @page Section1 	{size:612.0pt 792.0pt; 	margin:70.85pt 70.85pt 2.0cm 70.85pt; 	mso-header-margin:36.0pt; 	mso-footer-margin:36.0pt; 	mso-paper-source:0;} div.Section[FONT=&quot][/FONT]


----------



## Neals (23 September 2008)

Warum schreibst du extra ein externes NICHT ECHTZEITFÄHIGES Programm?
Das Programm ist abhängig von deinem Betriebssystem, wenn Windows gerade irgendwelche sinnfreien Dienste startet, kannst du extreme Verzögerungen haben und wirst in den seltensten Fällen Zykluszeiten von 50us erhalten.

Schreib doch einfach ein Steuerungsprogramm in dem deine Abläufte bearbeitet werden oder implementiere C-Code der von TwinCAT abgearbeitet wird.


----------



## trinitaucher (24 September 2008)

Nutzt du Windows XP oder CE? Bei CE gibt's den sog. "TC Timer" schau mal im Information System nach.
Der erlaub mit CE unter Nutzung des TwinCAT-Timers echtzeitfähige Programme.

Andernfalls bewegst du dich außerhalb der TwinCAT-Echtzeit.


----------



## Beta6 (24 September 2008)

Ich benutze Windows XP ... 
Die Klemmen sollen auf jeden fall per ADS angesprochen werden, weil ich gerne schauen wollte ob es einen Unterschied zwischen PLC und ADS von der Latenz her gibt. Und ich habe nicht wirklich andere Funktionen gefunden, mit denen ich Funktionen in einem bestimmten Zeitraum starten kann


----------



## trinitaucher (24 September 2008)

Beta6 schrieb:


> Ich benutze Windows XP ...
> Die Klemmen sollen auf jeden fall per ADS angesprochen werden, *weil ich gerne schauen wollte ob es einen Unterschied zwischen PLC und ADS von der Latenz her gibt.* Und ich habe nicht wirklich andere Funktionen gefunden, mit denen ich Funktionen in einem bestimmten Zeitraum starten kann


Da haste die Antwort 
Win XP => "keine" Echtzeit
Win CE => Echtzeit mittels TcTimer

Alles außerhalb der TwinCAT PLC ist auf Windows angewiesen. CE ist per se echtzeitfähig, XP nicht. Bei CE kann unter CE die TwinCAT Zeitbasis genutzt werden (TcTimer).
Wenn's hart echtzeitfähig sein soll, dann am besten über PLC


----------



## Beta6 (24 September 2008)

Okay Danke! Trotzdem verstehe ich nicht warum mein Programm nicht funktioniert. Ich habe zwischenzeitlich den Zyklus hochgesetzt (bis auf 1s) und es gab das gleiche Problem, dass beim ausgeben die fehlermeldung mit dem timeout kommt und sich die ausgabe weiter verzögert. Also schätze ich dass es zusätzlich zum handicap mit XP noch ein fehler mit der Logik des Programms oder dem Programm selber geben müsste.


----------



## trinitaucher (24 September 2008)

Was du für ne TwinCAT Zykluszeit einstellst ist für Windows-Programme völlig unerheblich! TwinCAT arbeitet unabhängig von Windows !!! Zykluszeit bezieht sich ausschließlich auf die PLC, es sei denn, du nutz den TcTimer mit einer Zeit von z.B. 100µs. Aber auch dann hat die SPS-Zyklszeit damit nichts zu tun, es ist dann einfach eine Art "zweite Task".

Das Problem wird Windows XP sein. Oder eine Eigenart deines Programms...
Ohne CE wird das mit deinem Test nichts... oder du hast schon das Ergebnis präsentiert bekommen


----------



## Neals (25 September 2008)

Du könntest ja ne Notification auf ne boolsche Variable in der PLC legen und diese dann toogeln. Dann müsstest du ja jeden Zyklus ne Meldung bekommen, mit der du dann deine Abläufe starten kannst.

War nur ne kurze Idea ;-)


----------



## Beta6 (26 September 2008)

:-D die Idee war mir auch gerade gekommen. Ich probiere das jetzt einfach nochmal aus, vielelicht klappt es dann zumindest ohne Fehlermeldung


----------



## Beta6 (26 September 2008)

Sooo,

also ich kann nun sagen dass man es wirklich vergessen kann mit ADS einen lese/schreib-zylkus im mikrosekundenbereich zu erreichen! Ich habe selber mit einer Funktion die Zeit ausgelesen und damit ein Programm geschrieben das funktioniert hatte, nur war es von den gewollten 50µs um Welten entfernt! 
Der Schreib Prozess konnte ungefähr nur alle 1-2ms ablaufen, was in meinem Fall leider viiiieeeel zu viel ist  ... trotzdem danke für die mithilfe und ich probiere es nun mit R3IO ^^


----------



## trinitaucher (26 September 2008)

Aber die gewünschte Reaktion bekommste schon mit einem SPS-Programm hin, oder?
Oder funktioniert das auch nicht mit den 50µs?


----------



## Beta6 (30 September 2008)

Naja, die Latenz ist mit ~130µs sehr hart an der Grenze für unser Aufgabenbereich. Deshalb probieren wir alle Möglichkeiten aus


----------



## trinitaucher (30 September 2008)

Nochmals... wenn ihr in einem *SPS-Programm* und im System Manager als Basiszeit 50µs einstellt, werden dann die Werte eingehalten und bleibt die "Systemlatenz" dann unter 4..5µs (zu sehen im System Manager unter "System-Konfiguration" => "Echtzeit-Einstellung" => "Online")?
Wenn die Systemauslastung dann schon jenseits der 50% steigt, könnte es sowieso schwierig werden mit der ganzen Aktion.

An welcher Stelle lest ihr die "Latenzzeiten" ab?


----------



## Beta6 (10 Oktober 2008)

Ja, die angezeigte System-Latenzzeit ist sehr niedrig (liegt sogar noch unter 2µs). Dennoch haben wir eine ziemlich hohe Gesamtverzögerung. Wir speisen das von einem Funktionsgenerator erzeugtes Signal ein und überprüfen die Verzögerung mithilfe eines Oszilloskopes (1. Kanal direkt mit am Funktionsgenerator, 2. Kanal am Ausgang des DA-Wandlers.


----------



## drfunfrock (10 Oktober 2008)

Beta6 schrieb:


> Ja, die angezeigte System-Latenzzeit ist sehr niedrig (liegt sogar noch unter 2µs). Dennoch haben wir eine ziemlich hohe Gesamtverzögerung. Wir speisen das von einem Funktionsgenerator erzeugtes Signal ein und überprüfen die Verzögerung mithilfe eines Oszilloskopes (1. Kanal direkt mit am Funktionsgenerator, 2. Kanal am Ausgang des DA-Wandlers.




Das wirst du nicht verhindern können. Immerhin hast du es nicht mit High-Speed-Signalwegen zu tun. Dann kommt noch die Wandlung dazu, Kommunikation und von der Änderung des Signals bis dass der Prozess  die Daten bekommt, kann ein Zyklus vergehen.


----------



## Realtimer (16 Oktober 2008)

drfunfrock schrieb:


> Das wirst du nicht verhindern können. Immerhin hast du es nicht mit High-Speed-Signalwegen zu tun. Dann kommt noch die Wandlung dazu, Kommunikation und von der Änderung des Signals bis dass der Prozess die Daten bekommt, kann ein Zyklus vergehen.


 
Das mit den High-Speed-Signalwegen verstehe ich nicht. Ich dachte immer, dass der Strom nicht viel langsamer als Licht läuft. Und wenn man langsame ADC's einsetzt und für die Wandlung lang braucht ist es auch nicht optimal. Ein Zyklus darf doch vergehen, für die paar Signale sollten sich doch 50 µs ausgehen, wie es die Werbung verspricht. Beta2 spricht aber von einer Latenz von 130 µs. Irgendwas hat's da noch.

LG

Realtimer


----------

