Step 7 OPC Client Kommunikation mit S7-1500

canogretic

Level-2
Beiträge
14
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich hoffe mir kann hier jemand weiterhelfen. Ich bin relativ neu in die Thematik OPC und S7-1500 eingestiegen.
Hauptsächlich geht es im Augenblick erst einmal darum mittels OPC Daten aus der Steuerung abzugreifen und in eine Datenbank zu schreiben.
Grundsätzlich funktioniert das auch alles soweit, bis auf eine kleine Ausßnahme.
Laut Spezifikation seitens Siemens können bis zu 1000 Nodes per Read abgefragt werden. Heißt für mich erstmal das ich mit einer Anfrage 1000 Knoten des
OPC Servers gleichzeitig anfragen kann. Hierbei habe ich das Problem das meine Zykluszeit der Steuerung verhältnismäßig stark erhöht wird.
Diese Erhöhung kann ich nur eindämmen wenn ich die Anzahl der Knoten, welche gleichzeitig von Client angefragt werden, um den Faktor 200 kleiner mache.

Hat hier evtl. jemand mehr Erfahrung in dem Bereich oder kennt das Problem und kann mir einen Tipp geben?
Alle Versuche den Client zu Optimieren haben keine signifikaten Änderungen hervorgerufen.

Tia-Portal: V15.1
Modultyp: CPU 1507S
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt noch die OPC Server-Methoden. Ob das einfluss auf die anzahl der nodes und der zykluszeit hat kann ich aber nicht sagen.
nur mal als stichwort eingefügt.
 
Hallo
hier setzt unser Gateway an Zusätzliche HW Performance für OPC UA - Entlastung der. CPU

Vorverarbeitung inclusive. keine Knoten Beschränkung.

Saubere Trennung zwischen Steuerung und Datenbank.
 
Ich verwende den OPC Server direkt auf der CPU.
Nach erneutem Lesen der Client Konfigurationsbeschreibung und dem durchsehen der verlinkten Leistungsdatenberechnung ist mir aufgefallen, das ich innerhalb der Client Anwendung zwar
die einzelnen Nodes registriere, aber das Handle auf die Variable nie mehr nutze um die Werte zu lesen.
Somit erfolgt auch kein vernünftiges registeredRead.

Nach Umstellungen des Lesevorgangs auf die registrierten Knoten sah das deutlich besser aus und ich hatte in der Testumgebung bei 500 Varaiblen pro Read keine signifikante Änderung der Zykluszeit.
Das Ganze würde ich vermutlich im laufe des morgigen Tages am Produktivsystem testen können und anschließend davon berichten.
 
Optimierungen wären z.B. die Daten in UDTs / Structs / Arrays zusammenzufassen und diese dann über eine einzelne Node anzufragen. Ansonsten kannst du die Beeinflussung der Zykluszeit durch Kommunikationsaufgaben in den CPU Einstellungen begrenzen, dann dauern Abfragen allerdings länger.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielen Dank für die vielen Infos. Das Lesen der Knoten hat auf dem Produktivsystem durch das lesen der registrierten Variablen eine deutliche Verbesserung hervorgerufen und die VErbindung ist mir nicht sofort nach dem ersten read ausgestiegen. Falls noch Optimierungsbedarf besteht würde ich den Ansatz von @Häns folgen und die Daten in Einheiten zusammenfassen und die Beeinflussung der Zykluszeit begrenzen.
 
Hallo,

auch wenn es schon etwas spät ist, möchte ich noch einen "allgemeinen" Hinweis loswerden. Klar ist das Lesen/Schreiben bei OPC immer schon "Mengenaufrufe" gewesen sind, es sollte also immer so viel wie möglich in einem Aufruf zusammengefasst werden (bei der 1500 sind das 1000 Items pro Read) Beim OPC UA gibt es verschiedene Mittel, um die Performace zu steigern. Dazu muss man sich ein paar Fragen selber beantworten, um die optimale Verbesserung zu erziehlen.

1) immer wieder die selben Items lesen (z.B. um sie zyklisch in eine DB zu schreiben)
>> den "registered" Read verwenden, das Registrieren "kostet" auch, sollte man also nur einmal machen.

2) immer wieder "andere" Items lesen (z.B. Diagnose oder Anzeige von Werten in verschiedenen Bildern)
>> einmal alle zur Beobachtung anmelden (subscriben), und dann nur noch vom Cache lesen (gesteuert über MaxAge)
>> am Besten überhaupt nicht mehr "lesen" sondern nur noch auf "Änderungen" warten

3) Block lesen (z.B. Werte in Arrays zusammenfassen)
>> das reduziert zwar die "Anzahl" der Items (es ist dann nur noch ein "großes" Item) aber bedeutet mehr Aufwand auf der Clientseite wo man es wieder aufbröseln muss.
>> es eignet sich zum "Beobachten" (subscriben) nur bedingt, da sich nur ein "Element" des Arrays ändern muss, um das gesamte Array übertragen zu müssen
>> auch beim Schreiben muss man dann immer das gesamte Array beschreiben (es sei den der Server unterstützt IndexRange, was fast keiner tut)

Daher ist es immer eine Abwägung bezüglich des UseCase, welche "Optimierung" die beste ist. Bei der S7-1500 (und 1200) würde ich das "registrierte Lesen" zuerst versuchen.
 
Zurück
Oben