# Schneller(!) Treiber für S7 <--> C# gesucht



## kpf (19 September 2012)

Hallo,

ich suche einen extrem schnellen Treiber, um aus meinem C#-Programm mit einer S7 zu kommunizieren.
Der Treiber muss eigentlich nicht viel können (nur halt schnell sein):
- nur S7-300/400 bzw. VIPA-300, CPU oder CP
- nur Ethernet
- 1 PC zu bis zu 4 Steuerungen
- Protokoll S7 bzw. RFC1006 (d.h. möglichst ohne Programmierung in der S7)
- nur DBs lesen und schreiben
- Datenmengen: sowohl wenige Wörter als auch große Blöcke (mehrere K Wörter), die Geschwindigkeit ist insbesondere bei den kleinen Telegrammen wichtig
- am Besten eine dll für C#/.NET
- darf ruhig etwas kosten

Beim Googeln findet man ja hunderte Treiber, und da ist natürlich jeder der Schnellste ... 
OPC scheidet wohl aus.

Wie sind denn Eure (positiven/negativen) Erfahrungen diesbezüglich mit den verschiedenen Produkten? Was könnt Ihr empfehlen?

Grüße
kpf


----------



## JesperMP (19 September 2012)

Es gibt www.indi-an.de und www.deltalogic.de. Glaube du kannst probieren und später bezahlen wenn du dich für einer entscheidest.

Mehrere K-Wörter wäre ein Problem. Am mindestens bei S7-300 gibt es eine Grenze bei 244 Bytes (oder in die Nähe davon, bin nicht 100% sicher wo es liegt) was der CPU in einen Sende-Auftrag senden kann. Mehre Daten müssen in mehere "Pakete" zerteilt werden.


----------



## rostiger Nagel (19 September 2012)

Auch wenn es nicht ganz in dein Auswahlkriterium passt, bestünde
nicht die Möglichkeit einen Siemens IPC zu nutzen. Dort könntest du 
mit der ODK Software direkt über C#./.NET auf die S7 Soft SPS zugreifen. 
Damit können dann zyklisch Daten ausgetauscht werden, dieses wird oft genutzt
wenn man alle anderen S7 Steuerungen zu langsam sind.


----------



## Jochen Kühner (19 September 2012)

Du kannst auch libnodave verwenden, ist kostenlos! Oder s7net (http://s7net.codeplex.com/). Oder meinen LibNodave Wrapper (http://siemensplctoolboxlib.codeplex.com/)

ich denke wirklich große unterschiede gibts da in der Geschwindigkeit nicht, da dort eher die S7 der bremsende Teil ist! (Da du das S7 Protokoll verwenden willst!)

Bei meiner lib hast du noch den Vorteil, es Anfragen an einen den DB zusammengefasst wenn möglich. Ich glaube auch das aber AGLink auch so eine funktion integriert hat!

Das Problem beim S7 Protokoll sind halt die Begrenzung auf 240 (480 bei 400er) Bytes pro Anfrage und Antwort!


----------



## kpf (19 September 2012)

Danke erstmal für Eure Antworten.
@JesperMP: Deltalogic könnte eine Möglichkeit sein. Indian basiert, soweit ich erkennen kann auf Java (oder ist der.Net-Treiber nativ?) und fällt damit aus.
@rostiger Nagel: Siemens-PCs und Soft-SPS fallen leider aus, es gibt schon einige existierende Anlagen. Außerdem möchte ich genau den zyklischen Datenaustausch im Hintergrund vermeiden, das kostet zuviel Zeit. ich will nur immer GENAU die Daten lesen/schreiben, die ich brauche.
@Jochen Kühner: Bei libnodave habe ich etwas kalte Füße. Das liegt daran, dass wir einen entsprechenden Treiber jetzt im Einsatz haben - zugegeben ein paar Jahre alt und mit VB6 erstellt. Der ist sowas von schnarchlangsam, da kann ich die Bits auch zu Fuß über die Leitung tragen - und programmiert hat den kein Dummer (nein, nicht ich )! Das Zusammenfassen der DB-Zugriffe ist eher kontraproduktiv bzw. irrelevant, das würde ich sowieso abstellen wollen.
Danke an alle für den Hinweis, dass ich große Pakete zerlegen muss - daran hatte ich noch nicht gedacht. Vom Aufwand her ist es eigentlich egal, ob ich in der S7 oder im Treiber was mache, aber die Anlagen gibt es schon und da will ich möglichst wenig ins S7-Programm eingreifen - deswegen S7/RFC1006.

Was mich interessieren würde - gibt es irgendwo Vergleiche oder Erfahrungen z.B. Deltalogic vs. libnodave vs. S7net oder so?


----------



## Rainer Hönle (19 September 2012)

Es gibt sowohl bei *ACCON-AGLink* und bei libnodave Funktionen, die das Aufteilen der Pakete selbständig übernehmen.
Und das optimale Zusammenfassen von Daten kann den Transfer deutlich beschleunigen (AGL_ReadOpt etc. in ACCON-AGLink). Dies bringt natürlich nicht mehr so viel bis gar nichts (CPU-abhängig), wenn die Daten sowieso am Stück vorliegen.


----------



## Thomas_v2.1 (19 September 2012)

Wie Jochen schon geschrieben hat liegt bei der S7 Kommunikation das Nadelöhr auf S7 Seite.
Darum liegt die einzige Möglichkeit den Datenaustausch schneller zu machen die Daten möglichst optimal zu packen sodass wenige Telegramme zu Stande kommen.

Je nach CPU bestünde noch die Möglichkeit mehrere Aufträge parallel abzuschicken, aber ich habe noch keinen Treiber gesehen der davon Gebrauch macht (was aber natürlich nichts heißen muss). Es ist auch nicht unwahrscheinlich dass es keinen Geschwindigkeitsvorteil bringt dieses auszunutzen, denn die CPU der SPS kann nur einen Auftrag zur Zeit bearbeiten.

Wenn du libnodave verwendest bist du selbst dafür verantwortlich die Daten optimal in Telegramme zu packen. Wahrscheinlich ist das der Grund dafür dass eure Anwendung so langsam ist, oder VB ist daran schuld. Technisch gesehen gibt es nicht viel Möglichkeiten den Datenaustausch schneller als mit libnodave umzusetzen.

Mit dem Benchmark der bei libnodave dabei ist misst du dementsprechend hauptsächlich die Antwort-Geschwindigkeit der CPU und nicht die des Treibers.

Mit einem Benchmark zu messen wie gut ein Treiber die Daten packt wird schwierig, denn dazu müsstest du Details des Protokolls kennen um entsprechende Datenbereiche für so einen Test anzulegen. Ich kann dir nur sagen dass der S7-Treiber bei WinCC-flexible überhaupt nicht packt und somit von der Geschwindigkeit der langsamste überhaupt ist. Dem DAserver von Wonderware habe ich öfters beobachtet, und der optimiert wirklich sehr gut.

Von s7net würde ich zum aktuellen Zustand abraten: Keine echten Bit-Write Befehle, ISO-on-TCP Protokoll Ebene ist nicht vollständig implementiert sodass du z.B. mit einer WinAC nicht kommunizieren kannst, kein Aushandeln der PDU Größe, etc.


----------



## Jochen Kühner (19 September 2012)

kpf schrieb:


> @Jochen Kühner: Das Zusammenfassen der DB-Zugriffe ist eher kontraproduktiv bzw. irrelevant, das würde ich sowieso abstellen wollen.



Das ist in meiner DLL natürlich auch optional implementiert, also es kann benutzt werden, oder eben nicht! 



kpf schrieb:


> Danke an alle für den Hinweis, dass ich große Pakete zerlegen muss



Das macht bei mir auch die Bibliothek, dabei muss man natürlich beachten, das es dann keinen Konsistenz gibt, wobei es diese bei den neueren CPUs soweit Ich weis eh nicht mehr gibt, da die S7 Kommunikation azyklisch läuft!


----------



## Jochen Kühner (19 September 2012)

Rainer Hönle schrieb:


> Es gibt sowohl bei *ACCON-AGLink* und bei libnodave Funktionen, die das Aufteilen der Pakete selbständig übernehmen.



Wo gibts denn bei libnodave diese Möglichkeit? Es gibt dort doch nur eine Funktion um Bereich größer als eine PDU zu lesen, aber zum optimieren gibts doch keine, oder?


----------



## Jochen Kühner (19 September 2012)

@kpf:

nochwas: ich hab in meiner bibliothek ein beispielprogramm "readspeedtest", da kannst du messen wie schnell libnodave ist, und auch vergleichen was es an zeit kostet meine "high level" funktionen zu nutzen (fast kein unterschied).


----------



## Indi.An-er (20 September 2012)

Hallo kpf,
das es PLCcom nur für java gibt ist nicht ganz richtig.
Unsere Library PLCcom (www.indi-an.de) gibt es für .net oder java. Beide Varianten sind in ihrer Umgebung nativ. 
Die .net-Variante wurde in C# entwickelt und wird auch in dieser Umgebung weiter entwickelt. 
Ob die Geschwindigkeit passt kannst Du gerne 30 Tage kostenlos ausprobieren.
Für nichtkommerzielle Nutzung bleibt die Komponente sogar kostenlos.
Viel Spass beim Testen...


----------



## Rainer Hönle (20 September 2012)

Thomas_v2.1 schrieb:


> Je nach CPU bestünde noch die Möglichkeit mehrere Aufträge parallel abzuschicken, aber ich habe noch keinen Treiber gesehen der davon Gebrauch macht (was aber natürlich nichts heißen muss). Es ist auch nicht unwahrscheinlich dass es keinen Geschwindigkeitsvorteil bringt dieses auszunutzen, denn die CPU der SPS kann nur einen Auftrag zur Zeit bearbeiten.


ACCON-AGLink nutzt dieses Feature, wenn die Aufträge asynchron eingestellt oder die Optimierungefunktionen verwendet werden. Der Geschwindigkeitsvorteil liegt je nach CPU bei ca. 15-20 %.


----------



## Rainer Hönle (20 September 2012)

Jochen Kühner schrieb:


> Wo gibts denn bei libnodave diese Möglichkeit? Es gibt dort doch nur eine Funktion um Bereich größer als eine PDU zu lesen, aber zum optimieren gibts doch keine, oder?


Ich habe nicht geschrieben, dass libnodave optimiert sondern dass Pakete größer eine PDU-Size angefragt werden können.


----------



## WeissT (20 September 2012)

Hallo,


in unserem Treiber ComDrvS7 ist ein selbstoptimierende Funktion zum Lesen und Schreiben von Operanden in unterschiedlichen Operandenbereichen vorhanden. 
Der Treiber ist in DLL-Form für die verschiedenen PC-Sprachen (C++, C#, VB, VB.NET, Delphi usw.) vorhanden. 
Mit zahlreichen Beispielen wird die Funktionsweise gezeigt.


Die Demo-Version ist voll funktionsfähig und kann somit für den Test verwendet werden.
Anbei der Link auf den Download:
http://www.mhj-online.de/de/shop_co...sid=7ef5cf0945ac24a3dadfd7856cfd766f#ComDrvS7


Die Handbücher im PDF-Format werden mit installiert.


Gruss


----------



## kpf (20 September 2012)

Danke an alle!
Dann spiele ich mal mit siemensplctoolboxlib rum und messe die Geschwindigkeit. Mal sehen, ob das reicht.
Wie gesagt sind die großen Datenmengen nicht zeitkritisch, nur die einzelnen Wörter und kurze DBs < 100 Wörter.


----------

