Lesen und Schreiben grosser Datenmengen aus vielen S7 SPSen in zentr. Line PC

Burkhard

Level-2
Beiträge
161
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Zur Fertigungs-Steuerung sollen aus verteilten S7 SPSen grosse Datenmengen gelesen und geschrieben werden. Ein zentraler Fertigungs-PC soll diese Aufgabe uebernehmen.

Zwei Varianten sollen verglichen werden, hinsichtlich Datenvolumen und einfacher Handhabbarkeit.

1. OPC Server

In einem OPC Server werden beim Lesen und Schreiben saemtliche OPC-Items von allen verbundenen SPSen zyklisch aktualisiert. Selbst wenn man eine Aktualisierungs-Rate von 10ms eingibt, dann wird diese bei 15 SPS en und 50 Items pro SPS (500 Items, 1/3 DWORDs, 1/3 REAL und 1/3 STRING) niemals erreicht. Man hat eine resultierende Zykluszeit von ca. 500ms)

Eine Datenkommunikation mit einer so hohen Zykluszeit ist nicht erforderlich, da die Daten nicht so haeufigt beneotigt werden. Die meiste Zeit werden also nutzlose Daten durch das Netzwerk gesendet.

Da die Daten Ereignisorientiert benoetigt werden, kann fuer jede Station (SPS) ein Ereignis definiert werden, wann Daten gesendet oder empfangen werden sollen.

2. Kommunikations-Bibliothek, LibNoDava

Mit der Kommunikations-Bibliothek wird nur ein BIT-Trigger-Signal zyklisch aus der SPS gelesen. Ist das Trigger-Signal low, passiert gar nichts. Nur wenn das Trigger-Signal high ist, wird einmalig ein Paket Nutzdaten aus der jeweiligen SPS in den zentralen Line-PC gelesen oder gesendet. (15 SPSen = 15 Trigger-Signale)

Diese Event-Gesteuerte Kommunikation gewaerleistet eine perssere Performance der Datenuebertragung, weil nur dann Daten im Netzwerk gesendet werden, wenn dies erforderlich ist.

3. Meinung der Experten hier im Forum.

Meiner Meinung nach ist ein Libnodave-basiertes System besser. Ich weiss, dass man auch mit einem OPC Server ereignisgesteuert lesen und schreiben kann, dazu ist ein Baustein in der SPS erforderlich der GET oder PUT heisst. Dazu ist aber sowohl in der SPS eine Intelligenz aufzubauen, als auch auf der Seite des Line-PCs. Und ein OPC Server muss auch noch zusaetzlich konfiguriert werden.

Welches Verfahren ist eurer Meinung nach besser geeignet um ein solches System zur Betriebsdatenerfassung und Liniensteuerung aufzubauen? Ein OPC-Server basiertes system oder ein auf Libnodave basiertes System?
 
Zuletzt bearbeitet:
Hallo,

OPC ist m. E. dann von Vorteil

  1. wenn auch noch andere Systeme angebunden werden müssen
    (für die es auch eine OPC-Anbindung gibt)
  2. wenn schon ein OPC-Client für die Weiterverarbeitung
    der Daten vorhanden ist

Wenn die Lösung rein für die bestehende S7 sein soll, dann würde
ich eine Bibliothek wie Libnodave, ComDrvS7 oder AGLink nehmen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, es handelt sich nur um S7 SPSen aus denen gelesen und geschrieben werden soll.

Ist ein OPC Server eigentlich grundsaetzlich zyklisch oder kann er auch ereignis-orientiert sein? Die Zyklische Datenuebertragung ist meiner Meinung nach verschwendung von Netzwerk-Ressourcen, wenn Daten nicht zyklisch sondern ereignisorientiert benoetigt werden.
 
Die Frage pauschal zu beantworten ist schwierig.

Ein Aspekt ist das Netzwerk:
Wenn du pro Linie ein eigenes Netzwerk hast, dann wirst du mit den SPS-Daten das Netzwerk kaum auslasten können.
Hast du überwiegend S7-300 mit einem CP343 als Netzwerkbaugruppe, dann langweilt sich das Netzwerk bei 15 SPSen.
Hier ist der lahme Rückwandbus der 300er der Flaschenhals.
Bei der Verwendung der internen Netzwerkschnitte der CPU oder bei S7-400 oder S7-1500 sieht es anders aus.
Hier ist die Netzwerk-Kommunikation deutlichst schneller aber ein aktuelles Gigabit-Netzwerk hat mehr als ausreichend Leistung.

Anderer Aspekt ist die Software:
Wenn du auf reines Eventhandling verwendest, dann musst du einen aufwendigeren Handshake sowohl bei den SPSen als auch beim PC vorsehen.
Bei Störungen können Telegramme "verschluckt" werden. Du musst also Mechanismen für Timeouts und Telegramm-Wiederholung programmieren.
OPC als standardmässig rein pollendes Verfahren ist hier unempfindlicher.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Burkhard,
ich hatte dich oben so verstanden, dass Du auf bestimmte Daten reagieren möchtest und daraufhin z.B. wieder Datensätze lesen oder in die SPS schreiben möchtest.
Nun ist es beim OPC-Server so, dass Du auf die Reihenfolge in der er Daten liest oder schreibt keinen Einfluss hast. Da macht der OPC-Server so wie er programmiert wurde, aus Deiner Sicht also nicht vorhersehbar und chaotisch. Auch ist es rechenaufwändig eine OPC-Subscription immer wieder aktiv und inaktiv zu schalten.

Wenn Du nur auf Siemens S7 zugreift kannst Du ruhig auf die Zwischenschicht OPC verzichten. Wir haben mit dem direkten Zugriff über eine Library schon diverse Projekte problemlos durchgeführt.
Libnodave ist durchaus geeignet, besser und aktueller ist noch der Fork von Jochen Kühner.
Die kostenpflichtigen Librarys bieten Dir darüber hinaus auch direkten Support und sind normalerweiser immer auf dem neuesten Stand.
Du hast nicht geschrieben in welcher Programmiersprache Du Deine Applikation umsetzen möchtest. Wir haben z.B. bei uns nun seit Jahren Dotnet oder Java zusammen mit plccom www.plccom.de im Einsatz und sind hiermit sehr zufrieden, große Datenmengen sind kein Problem da die Zugriffe vorher optimiert werden. Die Auswahl ist aber eher Geschmackssache, es gibt auch große Preisunterschiede.

Bei Verwendung einer S7-Library hast Du die Verarbeitungsreihenfolge und den Zugriff auf die SPS selbst in der Hand, bei OPC hast Du da nur wenig Einfluss, es sei denn dass Du ohne Subscription direkt liest und schreibst, das ist dann aber wieder langsamer und nicht für große Datenmengen geeignet.

Fazit: Empfehlung pro Library und direkter Zugriff :cool:

Gruß yogi
 
Zuletzt bearbeitet:
Als Programmiersprache kommt für mich eigentlich nur vb.net in Frage, da ich hier die meisten Erfahrungen habe. Ich verwende auch sehr viel Multi-Threading-Programmierung, ich denke, dass kann ich beim parallelen Lesen aus verschiedenen SPSen ganz gut verwenden. Dazu kommt noch eine Datenbank-Anbindung auf der anderen Seite, denn die Anwendung ist eine Linien-Steuerung, wo an der Maschinenstation eine Seriennummer eingescannt wird, dann wird ein Triggersignal gesetzt, das wird zyklisch vom Linien-PC gelesen. Ist das Trigger-Signal high, wird die Seriennummer dann vom Linien-PC gelesen, dann wird in einer Datenbank nachgesehen ob diese Seriennummer in die Station darf und dann wird eine Freigabe oder Sperrung an die SPS zurück gesendet.

Ich bin auch für die Kommunikations-Library und die Programmierung von Handshakes zwischen Linien-PC und SPSen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
In einem OPC Server werden beim Lesen und Schreiben saemtliche OPC-Items von allen verbundenen SPSen zyklisch aktualisiert. Selbst wenn man eine Aktualisierungs-Rate von 10ms eingibt, dann wird diese bei 15 SPS en und 50 Items pro SPS (500 Items, 1/3 DWORDs, 1/3 REAL und 1/3 STRING) niemals erreicht. Man hat eine resultierende Zykluszeit von ca. 500ms)

Hallo,
hier hast du m.E. einen Gedankenfehler.
Die genannte Anzahl von Variablen wirst du NIEMALS (egal mit welchem System) in 10 ms aktualisiert bekommen - in 500 ms insgesamt denke ich ist das schon machbar.
Bei dem Datenblock ist es m.E. nicht unbedingt von Vorteil, mit einem Trigger zu arbeiten - das macht eher bei größeren Datenmengen (z.B. Kurven oder so) Sinn. Du mußt ja dafür auch in der SPS etwas haben, dass die Wertänderung jeder der Variablen erkennt und dann den Trigger setzt. Nun muß dein Daten-Sammler den Trigger abfragen und bei TRUE den Datenblock lesen und anschließend den Trigger wieder löschen.
Ich denke mal, dass du hier auch genauso gut (wenn es ja sowieso nicht so superschnell werden muss) zyklisch und nacheinander von jeder der SPS'en die Daten (alle) einlesen kannst.
OPC würde ich auch nicht machen. Welche der genannten Bibliotheken du hier aber nimmst ist (glaube ich) eher ein philosophisches Thema.

Gruß
Larry
 
Zurück
Oben