Sonstiges SPS Kommunikationsarten

V

Vladzzz_

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

ich arbeite derzeit an der Etablierung einer Kommunikationsverbindung zwischen einem PC und einer Siemens SPS (1500). Mein Ziel ist es, bestimmte Daten innerhalb eines Structs zu lesen und zu schreiben und diese Daten anschließend in C# in Visual Studio grafisch darzustellen. Anfangs habe ich OPC UA für die Kommunikation verwendet, fand diese Methode jedoch zu langsam. Daraufhin wechselte ich zu einer PUT/GET-Kommunikation unter Verwendung der S7.Net-Bibliothek in Visual Studio, stellte jedoch fest, dass diese Verbindung zu instabil ist. Die Übertragung der Werte variiert stark in ihrer Dauer beim Schreiben oder Lesen.

Nach vielen Versuchen überlege ich, ob ich eine eigene Kommunikationslösung mittels TCP/IP Blöcken implementieren oder stattdessen auf eine andere Technologie umsteigen sollte.

Ich wäre sehr dankbar für jeden Tipp oder Erfahrungsbericht zu diesem Thema.

Grüße,
Vladimir
 
Zuletzt bearbeitet:
Deltalogic's Accon AG Link unterstützt S7-1500, inklusiv symbolischer Zugriff und secure Verbindung:
www.deltalogic.de

Efficient communication between PC and controller

The communication library ACCON-AGLink enables data access to your SINUMERIK machine tool controllers, Siemens PLCs, also for TIA Portal projects.
www.deltalogic.de www.deltalogic.de

Diese Bibliotek soll wesentlich performanter sein als z.B OPC UA.
Es gibt ein Trial mit den man die Software ausprobieren kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
JesperMP schrieb:
Deltalogic's Accon AG Link unterstützt S7-1500, inklusiv symbolischer Zugriff und secure Verbindung:
www.deltalogic.de

Efficient communication between PC and controller

The communication library ACCON-AGLink enables data access to your SINUMERIK machine tool controllers, Siemens PLCs, also for TIA Portal projects.
www.deltalogic.de www.deltalogic.de

Diese Bibliotek soll wesentlich performanter sein als z.B OPC UA.
Es gibt ein Trial mit den man die Software ausprobieren kann.
Zum Vergrößern anklicken....
Okay danke! Ich werde es in meiner Firma brauchen, deshalb weiß ich nicht ob sie für sowas Geld ausgeben würden.
 
Die Preis ist wie 1 Tag Lohn.
Wenn du in weniger als 1 Tag selber etwas zusammenflixen kann, dann hurrah.
Ich glaube dass die Libnodave bassierte Biblioteken unterstützen nur nicht-optimierte Bausteine und keine security.
edit: Snap7 bassiert nicht auf Libnodave, aber die Einschränkungen sind dieselbe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie schnell muss das ganze denn sein? Mit OPC-UA haben wir schon unter Zykluszeit Daten ausgetauscht. War ein nur ein Handshake von Daten aber im Trace war die Rückmeldung zum gleichen Zeitpunkt da wie das Melden. Ggf. habt ihr die OPC Zeit nicht runter gestellt, Standard ist 1s aber bei einer größeren CPU kann man auf 50ms runter gehen.
 
Mit ACCON-AGLink must Du kein Zeitintervall angeben und kannst die Werte so schnell lesen, wie sie die Steuerung hergibt.
Welche Steuerung hast Du genau (MLFBNr)?
Wieviel Daten musst Du in welchem Zeitraster lesen?
Du kannst Dir einfach mal die Demoversion (über obigen Link) ansehen und prüfen, ob damit Deine Anforderungen erfüllt werden.
 
OPC-UA
blackpeat schrieb:
Wie schnell muss das ganze denn sein? Mit OPC-UA haben wir schon unter Zykluszeit Daten ausgetauscht. War ein nur ein Handshake von Daten aber im Trace war die Rückmeldung zum gleichen Zeitpunkt da wie das Melden. Ggf. habt ihr die OPC Zeit nicht runter gestellt, Standard ist 1s aber bei einer größeren CPU kann man auf 50ms runter gehen.
Zum Vergrößern anklicken....
Also eine 1515 kann eine Intervall von minimal 100ms.
1710967670340.png
Eine 1518 kann auf 10ms runter.
1710968494690.png
- für kurze Zykluszeiten teuer
- integriertes Security

Zusätzlich zu den genannten gibt es noch folgende Möglichkeiten.

TCP
Was auch geht, ist einfach TCP IP oder UDP.
- Flexibel, da man alles in der Hand hat
- Aufwendig, weil man alles in der Hand hat

(I)RT
Wenn noch kürzere Zyklen notwendig sind, könnte man noch den Rechner mit einem CP16xx ausstatten und eine (I)RT Verbindung nutzen.
- Aufwendig und teuer
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja. Es kommt drauf an wie schnell und zuverlässig das Ganze sein soll.
UDP kannst du knicken wenn du Echtzeit brauchst. Die Priorität in der CPU für TCP/IP bzw. UDP ist intern relativ niedrig, vor allem im Vergleich zur Priorität in der man die Bausteine aufrufen kann..
Wir haben mit UDP teils Telegrammausfälle von 20ms alle paar Stunden, ein Jitter von 2, 3ms ist relativ normal, zuverlässig 1ms funktioniert nur auf dem Papier.

Wenn du es zuverlässig, einfach mit guter Diagnose willst, führt eigentlich kein Weg an ProfiNet vorbei.

Und teuer... Ja ein CP1616 kostet Geld, aber du arbeitest auch nicht umsonst.
Es ist meist billiger eine etablierte Lösung zu nehmen, die man in einem Tag laufen hat, statt sich was Eigenes zu überlegen und Tage bzw. Wochen mit Programm und Systemtest zu verbringen.
So zumindest meine Erfahrung aus 14 Jahren und einigen Rollen rückwärts, wo wir die Eigenlösung dann doch für teuer Geld gegen Standard getauscht haben, weil's einfach nicht zuverlässig lief... Doppelt teuer...

Was an einem CP1616 allerdings aufwendig sein soll? Das ist kein Standardprodukt, einbauen, installieren, läuft.
 
xMisterDx schrieb:
Was an einem CP1616 allerdings aufwendig sein soll?
Zum Vergrößern anklicken....
Aufwendig ist das suchen und finden von ein PC mit PCI Steckplatz. Vor einige Jahren hätte ich auch ein CP1616 empfohlen, inzwischen doch eher eine gute Software Stack.
Für PC <-> SPS Kommunikation muss es nicht zwingend < 1 msec Prozessdaten Austausch sein.
 
MQTT ist hingegen nur zyklusabhängig.
Vorteil: du kannst dir das so zusammenbasteln wie du es brauchst, Clients gibt es für jede Umgebung genauso wie Broker auch. JSON als Formatierung eignet sich auch gut zur direkten Weiterverarbeitung
Nachteil: Du musst es dir selbst zusammenbasteln. Was allerdings nicht so aufwendig ist wie es klingt.

Wir nutzen Mosquitto als Broker.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für all die guten Antworten. OPCUA würde auf jeden Fall rausfallen da 100ms zu langsam sind. TCP bzw. UDP würde auch gehen, die Frage ist wie gesagt wie stabil es dann wird wenn ich es selber mache. MQTT ist der derzeitige Favorit. Ich hab auch gesehen, dass eine weitere Aufgabe in der Firma wäre mittels SQL Datenbank paar Daten auszutauschen, glaubt ihr ich könnte die beiden Sachen vereinen (Visualisierung mittels SQL Datenbank daten) oder sollte ich die beiden lieber Trennen (jetzt nur Datenaustausch Zeittechnisch gesehen)? Nochmals danke.
 
DCDCDC schrieb:
Grafana biete SQL und auch MQTT Support an, darüber könntest du die Daten visualisieren, von beiden Datenquellen.
Zum Vergrößern anklicken....
Sehr guter Punkt. Die eigentliche Aufgabe für den SQL Server ist es nicht etwas zu visualisieren, nur um Informationen auszutauschen. Die Frage war kann ich die zu visualiesierenden Daten gleich mit auf den SQL server ziehen damit ich nicht 2 sachen hab?
 
DCDCDC schrieb:
Wie ist denn der Weg der Daten den du gehen möchtest?

SPS -> MQTT -> SQL -> VISU

Oder doch anders?

Einen weg den wir hier schon umgesetzt haben ist, SPS -> MQTT -> Nodered -> Influxdb -> Grafana


Zum Vergrößern anklicken....
Also mit bis jetzt wäre es: (immer gleicher PC)

SPS -> MQTT -> PC -> VISU
-> SQL -> PC -> Datenabfrage

Die Idee wäre:
SPS -> SQL -> PC -> VISU/Datenabfrage

Wäre die VISU in dieser Version träge?
 

Similar threads

I
TIA S7-1517 MB_Client verschiedene Adressbereiche auslesen,
Antworten
13
Aufrufe
914
NOBS
N
J
TIA Größerer Datenaustausch S7-1200 mit S7-300
2
Antworten
21
Aufrufe
2K
Holzmichl
H
M
DWord, Int und Byte in ein Struct von Array of Byte kopieren oder verschieben
Antworten
1
Aufrufe
396
Oberchefe
O
H
TIA S7 1200 CM1241 Modbus Receive Buffer
Antworten
3
Aufrufe
1K
HandsomeHans
H
ChristianVogel
TIA Kommunikation mit PNOZ B0 über DPRD-DAT / DPWR-DAT im FB nach CPU-Tausch gestört
Antworten
6
Aufrufe
814
ChristianVogel
ChristianVogel
Zurück
Oben