TIA Alternative Snap7 gesucht

Stoky

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

wir sind Maschinenbauer und in unseren Maschinen kommt fast immer ein PC und eine Siemens SPS (mittlerweile immer eine 1500er CPU, z.B. 1512SP-F) zum Einsatz. Der PC muss sehr schnell Daten aus einem SPS DB lesen und auch sehr schnell in den DB schreiben. Man hat sich hier vor längerer Zeit für Snap7 entschieden. Das funktioniert sehr gut, hat aber einen gravierenden Nachteil: Der DB darf nicht optimiert sein. Da wir gerne die Möglichkeit hätten Software Units einzusetzen um parallel arbeiten zu können, suchen wir jetzt eine Alternative zu Snap7 die sehr schnell ist, aber optimierte DBs kann. OPC UA als gängige Lösung ist zu langsam. Ich habe leider keine harten Zahlen für euch, da die Kollegen das nur durch ausprobieren ermittelt haben.

Kennt ihr vielleicht eine Alternative zu Snap7 mit der ein PC auch auf einen optimierten, automatisch nummerierten SPS DB zugreifen kann (lesen+schreiben) und das sehr schnell?

Gruß Stoky
 
OPC UA wäre eine Alternative, falls die Entwickler leidensfähig sind. Die Standard S7-1500 aktualisieren aber nur alle 100ms. Falls ihr das nutzt, könnt ihr die Simatic-Interfaces deaktivieren und nur den Teil via OPC UA anbieten, auf den zugegriffen werden soll. OPC UA kann auch auf optimierte Datenstrukturen zugreifen.

Alternativ könnte man noch MQTT einsetzen (LMQTT), aber erfordert einen MQTT-Broker im Netzwerk (auf dem PC mit Mosquitto).

ModbusTCP wäre auch noch eine vernünftige Lösung. Ob es dafür eine freie Bibliothek gibt, weiß ich aber nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Vertreibler kann vermutlich auch keine Garantie geben.
Oder schlimmer, er garantiert alles was du fragst, ohne zu wissen ob es geht.
ACCON AGLink kann man kostenlos testen. Dann bekommt man realen Bescheid ob es geht oder nicht.
 
Hallo zusammen,

wir sind Maschinenbauer und in unseren Maschinen kommt fast immer ein PC und eine Siemens SPS (mittlerweile immer eine 1500er CPU, z.B. 1512SP-F) zum Einsatz. Der PC muss sehr schnell Daten aus einem SPS DB lesen und auch sehr schnell in den DB schreiben. Man hat sich hier vor längerer Zeit für Snap7 entschieden. Das funktioniert sehr gut, hat aber einen gravierenden Nachteil: Der DB darf nicht optimiert sein. Da wir gerne die Möglichkeit hätten Software Units einzusetzen um parallel arbeiten zu können, suchen wir jetzt eine Alternative zu Snap7 die sehr schnell ist, aber optimierte DBs kann. OPC UA als gängige Lösung ist zu langsam. Ich habe leider keine harten Zahlen für euch, da die Kollegen das nur durch ausprobieren ermittelt haben.

Kennt ihr vielleicht eine Alternative zu Snap7 mit der ein PC auch auf einen optimierten, automatisch nummerierten SPS DB zugreifen kann (lesen+schreiben) und das sehr schnell?

Gruß Stoky
Kannst du kurz skizzieren um welche Datenmengen und welche Abtastzeiten es geht?
 
Kannst du kurz skizzieren um welche Datenmengen und welche Abtastzeiten es geht?
Ich bin noch ganz neu hier in der Firma, aber soweit ich weiß handelt es sich nicht um riesige Datenmengen, sondern um höchsten ein paar hundert Byte. Da versuche ich aber mal morgen noch nachzuhaken. Bei den Zeiten gilt das Gleiche. Bisher habe ich nur als Infos bekommen, dass OPC UA zu langsam ist und Snap7 schnell genug. Genaue Zeiten sind wohl nicht bekannt.

Vielleicht relevant als Hintergrund Info: Ich bin eingestellt worden um die Standardisierung und Modernisierung der Software voran zu bringen. Und das Snap7 ist aktuell einer der Bremsklötze.

OPC UA wäre eine Alternative, falls die Entwickler leidensfähig sind. Die Standard S7-1500 aktualisieren aber nur alle 100ms. Falls ihr das nutzt, könnt ihr die Simatic-Interfaces deaktivieren und nur den Teil via OPC UA anbieten, auf den zugegriffen werden soll. OPC UA kann auch auf optimierte Datenstrukturen zugreifen.
Wie gesagt, OPC UA ist bereits verworfen worden, weil es zu langsam ist. Dabei ist es wohl so, dass die Lese-/Schreibzeit stark schwankt, manchmal ausreichend ist, und manchmal zu lang.

Alternativ könnte man noch MQTT einsetzen (LMQTT), aber erfordert einen MQTT-Broker im Netzwerk (auf dem PC mit Mosquitto).

ModbusTCP wäre auch noch eine vernünftige Lösung. Ob es dafür eine freie Bibliothek gibt, weiß ich aber nicht.
Da bin ich noch nie drüber gestolpert, schaue ich mir aber mal an. Danke.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn schon MQTT eine Möglichkeit wäre, was ist mit einem einfachen TCP/IP Stream, ich denke der ist auch schnell unterwegs.
Wenn die Daten im gesamten bekannt sind und sich nicht über zu viele Bereiche aufteilen, wäre das vermutlich die schnellste und einfachste Lösung.
 
MQTT hat den Vor- und Nachteil, dass es keine feste Struktur hat. Wenn man das nutzt, kann man sich seine eigene Hierarchie und das Nachrichtenformat aussuchen. Es werden Bytes übertragen. Man muss dann beim Empfänger diese Struktur nachbilden und daran denken, dass die S7 Big Endian als Bytereihenfolge nutzt.

Wenn man ständig an der Anlage etwas verändert, braucht man ab hier nicht mehr weiterzulesen.......


Jedenfalls muss die CPU dann das Senden der MQTT Nachrichten veranlassen. Der Broker empfängt das und alle verbundenen Clients können diese Nachrichten abonnieren und sie verarbeiten.

Der Payload muss als Array of Bytes vorliegen. Das kann man z.B. erreichen, indem man die Optimierung des zu sendenden DBs deaktiviert und darauf ein BLKMOV ausführt. Der Bereich, in den man hineinkopiert, muss ein Array of Bytes sein. Das kann dann mittels LMQTT versendet werden.

MQTT ist speziell für die Kommunikation zwischen Maschinen entwickelt worden, wird aber mittlerweile für viel für IoT eingesetzt. Dadurch, dass die Frames so einfach aufgebaut sind, ist es ziemlich leicht es auf z.B: auf Mikrocontroller zu implementieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie gesagt, OPC UA ist bereits verworfen worden, weil es zu langsam ist. Dabei ist es wohl so, dass die Lese-/Schreibzeit stark schwankt, manchmal ausreichend ist, und manchmal zu lang.
Liest sich für mich irgendwie so als hätte da jemand versucht das Subscription-Konzept von OPC-UA für klassisches Polling zu vergewohltätigen, um sich anschließend über die 💩 Performance zu wundern...

Anyway, als Alternative zu Snap7 mit Unterstüzung von optimierten DBs wäre mir das Teil von DeltaLogic am geläufigsten.
Performance ist, soweit wir das bisher im Einsatz hatten, mit der gewohnten S7-Kommunikation vergleichbar.
 
Mal so eine Frage reingeworfen:
Warum muss der nicht optimierte Baustein denn unbedingt weg?
Was erhofft man sich dadurch?
Ist man dem Mythos auf den Leim gegangen, dass eine S7 ab dem ersten nicht optimierten Baustein nur noch die hälfte so schnell läuft?

Vielleicht ein bisschen am Thema Vorbei, aber es gibt da von AUTEM, den SPS Analyzer. Autem ist mal von Siemens beauftragt worden und hat in Eigenregie ein Tool gebaut, das die Anabolika Variante des Siemens Trace darstellt. Irgendwann wurden die leider von Siemens fallen gelassen wie eine heisse Kartoffel. Deswegen sind die neuen Verschlüsselungsmechanismen der SPSsen nicht mehr voll unterstützt. Ob man mit einer Art API die Werte lesen und schreiben kann, weiß ich nicht, die Abtastung der SPS ging aber extrem schnell.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum muss der nicht optimierte Baustein denn unbedingt weg?

Da ein direkter Speicherzugriff auf den optimierten Bereich keine Kenntnis darüber hat, wie die Struktur optimiert (gepackt) worden ist.

Was erhofft man sich dadurch?
Wenn man via PUT/GET auf Speicherbereiche zugreifen will, so dürfen diese nicht optimiert sein.


Ist man dem Mythos auf den Leim gegangen, dass eine S7 ab dem ersten nicht optimierten Baustein nur noch die hälfte so schnell läuft?
Es geht nur um die Möglichkeit auf die Rohdaten zugreifen zu können und wenn man das nicht braucht, muss man nichts ändern. Die Optimierung ist bei jedem Baustein automatisch aktiv.

Wenn Datenstruktur optimiert worden ist, passt sie besser in den Cache des Prozessors, da sie kleiner ist und kann entsprechend schneller verarbeitet werden. Nicht optimierte Bereiche benötigen mehr Speicher. Boolean werden noch zusammengefasst und das Alignment sind 2 Byte, also ein Wort. Was jetzt genau bei der Optimierung wie zusammengefasst wird, ist mir aber unbekannt.

OPC UA kann mit optimierten DBs umgehen.
 
Warum muss der nicht optimierte Baustein denn unbedingt weg?

Das ist die Begründung:
Der DB darf nicht optimiert sein. Da wir gerne die Möglichkeit hätten Software Units einzusetzen um parallel arbeiten zu können, suchen wir jetzt eine Alternative zu Snap7 die sehr schnell ist, aber optimierte DBs kann.
Ich weis nicht ob es stimmt, wenn man Software Units einsetzt, dann muss man sich auf optimierte Daten begrenzen.
 
Ich weis nicht ob es stimmt, wenn man Software Units einsetzt, dann muss man sich auf optimierte Daten begrenzen.
Das ist so.

Wenn ihr sowohl die Gewalt über die SPS als auch über den PC habt, könntet ihr doch auch eine TCP Verbindung nutzen, oder?
Dann könntet ihr auch daten aktiv von der Steuerung senden und müsstet nicht pollend arbeiten.
 
Wenn eh ein IPC drin ist vllt. die Soft SPS von Siemens und da dann das ODK nutzen das schafft Datenaustausch in Zykluszeit der SPS.

War bei uns soweit ich weiß auch nicht teurer als irgendein IPC und HW CPU.
Ohne es jetzt nochmal zu überprüfen, aber allein die Lizenzkosten für die Soft SPSen sind meiner Erinnerung nach deutlich höher als die bisher komplette eingesetzte Hardware (1512SP-F + 1212C + PC) zusammen. Das ist wirtschaftlich nicht umsetzbar.

Mal so eine Frage reingeworfen:
Warum muss der nicht optimierte Baustein denn unbedingt weg?
Was erhofft man sich dadurch?
Ist man dem Mythos auf den Leim gegangen, dass eine S7 ab dem ersten nicht optimierten Baustein nur noch die hälfte so schnell läuft?
Wie schon im ersten Beitrag geschrieben unter anderem um Software Units verwenden zu können. Die lassen nur optimierte Bausteine zu. Über Units kann man denken was man möchte, für mich sind sie endlich eine praktisch funktionierende Alternative zum Multiuser.

Bei TCP-Verbindung muss man schon beim programmieren planen und wissen, welche Daten man nachher haben will, und kann sie nicht erst zur Laufzeit herauspicken.
Das ist hier leider nur bedingt der Fall. Es gibt zwar mittlerweile einen halbwegs standardisierten Schnittstellenaufbau, aber da wird doch immer noch dran gewerkelt.


Ich habe das Thema nochmal intern angestoßen. Da aktuell aber nicht alle Beteiligten im Hause sind wird es da wohl noch ein bisschen dauern bis ich neue Informationen bekomme. Schon mal vielen Dank für all die Anregungen und Erfahrungsberichte!
 
Kennt ihr vielleicht eine Alternative zu Snap7 mit der ein PC auch auf einen optimierten, automatisch nummerierten SPS DB zugreifen kann (lesen+schreiben) und das sehr schnell?

Hallo, hier noch eine Antwort auf Deine Frage zu einer Alternative.
Du hast leider nicht geschrieben, in welcher Programmierumgebung Ihr Euer Projekt durchführt. Nun, sollte es sich in der .net oder java- Welt sein, probiert gerne als Alternative unsere PLCCom-Komponente aus.
Hiermit ist auch der Zugriff auf optimierte Datenbausteine möglich, die Komponente wurde vor nicht allzu langer Zeit auch auf zusätzliche Performance getrimmt.
Bei Interesse, probiere es gerne einmal aus, eine Beschreibung und den Download findest Du hier: https://www.indi-an.com/de/plccom/for-s7/fuers7-uebersicht/
Unser Support hilft auch gerne weiter, falls Du Hilfe bei der Umsetzung benötigst. Das als zusätzliche Information auf Deine Eingangsfrage....
 
Zurück
Oben