# Fragen zu ACCON AGLink



## funkey (11 März 2011)

Hallo!
Bin gerade dabei die AGLink Library zu testen und ich bin beeindruckt wie bequem sich alles verwenden lässt.

Hab da aber vorläufig noch ein paar Fragen.

Bei dieser Library kann man zwischen PG, OP und Sonstiger Kommunikation wählen. Sonstige Kommunikation kann man ja bei LibNoDave und IPS7Lnk von Träger nicht auswählen. Gibt es da geschwindigkeitstechnische Unterschiede, oder warum wählt man eine bestimmte Kommunikationsart aus, also nach welchen Kriterien?

Wieviele Strukturen kann man den Funktionen ReadMix, .. übergeben. Da gibt es doch bestimmt eine Grenze, oder?

Welchen Vorteil bringt OptReadMix mit sich? Kann ich mir da wirklich einen Geschwindigkeitsvorteil erwarten, und wenn ja ab welcher Menge von Daten.
Sollte man grundsätzlich OptReadMix verwenden oder ist es bei wenigen Werten dann langsamer?

Vielen Dank im Voraus für jede nützliche Information!

Gruß funkey


----------



## Jochen Kühner (11 März 2011)

Du kannst auch zwischen PG und OP bei libnodave nicht wählen (ich hab das in meine abgeänderte Version eingebaut!). Auf der S7 kann man aber Verbindungen für PG und OP reservieren, und jenachdem als was du dich nun mit der SPS Verbinden willst, und es ist keine Verbindung mehr verfügbar, dann lässt sich dich nicht verbinden, Kommunikationsmäßig ist das gleich!

Zu den read funktion kann Ich dir leider nichts sagen, da Ich AGLink noch nicht, ausser zu testzwecken, verwendet habe!


----------



## Rainer Hönle (12 März 2011)

Die Einstellung PG, OP, und Sonstige wird benötigt, dass man eine andere Resource auf der SPS wählen kann wenn eine komplett belegt ist. Es gibt z.B. einen S7-Nachbau, der nur eine PG- und eine OP-Verbindung zulässt. Da ist es schon praktisch, wenn man die freie Wahl hat (ohne im Programm etwas ändern zumüssen). In der Geschwindigkeit habe ich bis jetzt keine Unterschiede festestellen können.

Es gibt keine Grenzen bei der Anzahl der Strukturen (ok, den Hauptspeicher). ACCON-AGLink handelt dies alles nacheinander ab und packt soviel Strukturen wie möglich in eine Anfrage.

Die optimierten Funktionen lohnen sich speziell, wenn es viele einzelne Operanden sind, die dicht beieinander liegen. Wenn zum Beispiel die acht Bits eines Bytes in acht separaten Strukturen hinterlegt sind, dann wird für die Anfrage daraus intern eine einzige generiert. Wenn je Struktur Werte aus unterschiedlichen Bereichen lesen soll, dann bringt die Optimierung nichts. Wichtig dabei ist, dass man sich nicht darum kümmern muss, was die SPS wirklich kann, dies erledigt ACCON-AGLink einfach im Hintergrund. Und die erzielbaren Geschwindigkeitsvorteile sind schon beachtlich.


----------



## Jochen Kühner (12 März 2011)

Rainer Hönle schrieb:


> Die Einstellung PG, OP, und Sonstige wird benötigt, dass man eine andere Resource auf der SPS wählen kann wenn eine komplett belegt ist. Es gibt z.B. einen S7-Nachbau, der nur eine PG- und eine OP-Verbindung zulässt. Da ist es schon praktisch, wenn man die freie Wahl hat (ohne im Programm etwas ändern zumüssen).



Daher hab Ich es in meiner angepassten Version von libnodave so geändert das man dies beidem Erzeugen einer neuen Connection mit angeben kann. (Ich habe aber die Syntax vom normalen daveNewConnection nicht geändert, sondern eine neue Funktion (daveNewExtenedConnection) eingebaut. Mit dieser werden z.B. auch Routing Verbindungen aufgebaut.



Rainer Hönle schrieb:


> Die optimierten Funktionen lohnen sich speziell, wenn es viele einzelne Operanden sind, die dicht beieinander liegen. Wenn zum Beispiel die acht Bits eines Bytes in acht separaten Strukturen hinterlegt sind, dann wird für die Anfrage daraus intern eine einzige generiert. Wenn je Struktur Werte aus unterschiedlichen Bereichen lesen soll, dann bringt die Optimierung nichts. Wichtig dabei ist, dass man sich nicht darum kümmern muss, was die SPS wirklich kann, dies erledigt ACCON-AGLink einfach im Hintergrund. Und die erzielbaren Geschwindigkeitsvorteile sind schon beachtlich.


Zur Optimierung:
Seh Ich das richtig das es sich bis zu 4 Bytes zwischen 2 Variablen lohnt, trotzdem diese 4 Bytes mit zu lesen, da im Antworttelegramm, 4 Bytes an Header dazukommen würden! (So hatte Ich zumindest mal vor das optimieren in meiner Connection Library zu machen, und natürlich die Tags vorher sortieren!)


----------



## funkey (13 März 2011)

Vielen Dank für die hilfreichen Antworten.
Ich konnte das optimierte Auslesen jetzt erfolgreich testen (das Umsetzen der Funktionen nach AutoIt war gar nicht so einfach) und bin wirklich erstaunt über den Geschwindigkeitsvorteil.
Habe testhalber ca. 100 verschiedene Werte aus 4 SPSen (S7-300) ausgelesen. Das normale Lesen dauerte ~1000ms während das optimierte Auslesen nur ~300ms dauerte. Ich finde das beeindruckend wie gut diese Optimierung umgesetzt wurde.

Jetzt noch ein paar weitere Fragen:
Was stelle ich bei dem TimeOut beim Lesen am besten ein ich habe da jetzt immer 1000ms übergeben, was bewirkt dieser. In der XML-Datei steht ja auch ein TimeOut drinnen, wofür ist der? Außerdem wird der TimeOut vom Konfigurationstool nur für die erste AG-Nummer angepasst, habe die anderen direkt mit dem Editor geändert.

Wenn ich es nun noch schaffe die Daten asynchron zu lesen, dann dürfte der ganze Lesezyklus nur so lange dauern wie es dauert, die Daten von der langsamsten SPS (oder SPS mit den meisten auszulesenden Daten) zu holen, oder? Das wäre dann ja nochmal ein großer Geschwindigkeitssprung.

Ich werde mich wohl langsam mehr mit C(++) beschäftigen müssen um solche coolen Dinge in LibNoDave einbauen zu können. Ich weiß, Jochen hat da ja seine Connection Library, aber .NET kann ich mit AutoIt leider nicht nutzen.


----------



## argv_user (13 März 2011)

funkey schrieb:


> Wenn ich es nun noch schaffe die Daten asynchron zu lesen, dann dürfte der ganze Lesezyklus nur so lange dauern wie es dauert, die Daten von der langsamsten SPS (oder SPS mit den meisten auszulesenden Daten) zu holen, oder? Das wäre dann ja nochmal ein großer Geschwindigkeitssprung.



Leider musst Du die Zeiten aber dann doch noch addieren.
Das ist ja die Crux bei dem seriellen Zeug. Selbst Ethernet ist auch nur
ein serielles Bussystem. Auch da kommt alles schön eins nach dem anderen.

Aber ausprobieren kannste ja mal, und hier berichten.


----------



## Rainer Hönle (13 März 2011)

funkey schrieb:


> Jetzt noch ein paar weitere Fragen:
> Was stelle ich bei dem TimeOut beim Lesen am besten ein ich habe da jetzt immer 1000ms übergeben, was bewirkt dieser. In der XML-Datei steht ja auch ein TimeOut drinnen, wofür ist der? Außerdem wird der TimeOut vom Konfigurationstool nur für die erste AG-Nummer angepasst, habe die anderen direkt mit dem Editor geändert.


Mit dem Tiemoutwert kann einzelnen Funktionen direkt ein entsprechender Wert zuegordnet werden. Wird Hier 1 angegeben, wird der Standardtimeoutwert aus der Konfiguration synchron verwendet. Wird hier 0 angegeben, wir der Standardtimeoutwert aus der Konfiguration asynchron verwendet.



> Wenn ich es nun noch schaffe die Daten asynchron zu lesen, dann dürfte der ganze Lesezyklus nur so lange dauern wie es dauert, die Daten von der langsamsten SPS (oder SPS mit den meisten auszulesenden Daten) zu holen, oder? Das wäre dann ja nochmal ein großer Geschwindigkeitssprung.


Im Prinzip richtig, da sämtliche SPSen dann parallel abgefragt werden.



> Ich werde mich wohl langsam mehr mit C(++) beschäftigen müssen um solche coolen Dinge in LibNoDave einbauen zu können. Ich weiß, Jochen hat da ja seine Connection Library, aber .NET kann ich mit AutoIt leider nicht nutzen.


Zwischen libnodave und ACCON-AGLink gibt es konzeptionelle Unterschiede. Deshalb viel Spaß beim einbauen.


----------



## funkey (13 März 2011)

Rainer Hönle schrieb:


> Zwischen libnodave und ACCON-AGLink gibt es konzeptionelle Unterschiede. Deshalb viel Spaß beim einbauen.


 
Ich weiß, dass sich die beiden Libraries ziemlich unterscheiden, doch ich meinte hauptsächlich, dass in LibNoDave wichtige und vor allen bequeme Funktionen wie zum Beispiel AGL_Text2DataRW fehlen.

Was mir bei AGLink noch fehlt ist, das man Zeiten und Zähler nach einem ReadMix noch separat umwandeln muss. Den anderen Werten kann man ja die passende Struktur variabel mitgeben, damit gleich das Ergebnis stimmt (z.B. DWORD und FLOAT). 


Mit welchem Compiler kann man LibNoDave eigentlich ohne langes Nachdenken kompilieren, wenn man recht wenig Ahnung von der Materie hat?
Ich habe bei mir Code::Blocks und Dev-C++ installiert.


----------



## Jochen Kühner (13 März 2011)

funkey schrieb:


> Was mir bei AGLink noch fehlt ist, das man Zeiten und Zähler nach einem ReadMix noch separat umwandeln muss. Den anderen Werten kann man ja die passende Struktur variabel mitgeben, damit gleich das Ergebnis stimmt (z.B. DWORD und FLOAT).


Das hab Ich bei mir in die ConnectionLibrary eingebaut, d.h. jeder S7 Datentyp wird automatisch in einen .Net Datentyp umgewandelt. (z.B. Dword in Unit16, Time_Of_Day in DateTime, etc) und umgekehrt. 
Wie soll das AG Link aber bei Zeiten machen (ist ja keine reine .NET Lib), da gibt es ja von C keinen definierten Typ dafür (oder täusch Ich mich?)




funkey schrieb:


> Mit welchem Compiler kann man LibNoDave eigentlich ohne langes Nachdenken kompilieren, wenn man recht wenig Ahnung von der Materie hat?
> Ich habe bei mir Code::Blocks und Dev-C++ installiert.


Also Ich compiliere immer mit dem Microsoft Compiler, ist bei mir bei VS2010 dabei, aber galub der istauch im WindowsSDK enthalten! Anderen hab Ich noch nicht probiert (ok, GCC unter Linux)


----------

