Open Source Treiber für 1200/1500 (S7commPlus)

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

bei den CPUs mit aktuellen Firmwareständen die TLS unterstützen, ist es auch möglich ohne spezielle Schlüssel mit den Steuerungen zu kommunizieren. Darum könnte man meiner Meinung nach ohne auf zu viele interne Informationen zugreifen zu müssen, auch eine Open Source Lösung erstellen.

Ich habe sozusagen ein "Proof of Concept" in C# geschrieben was grundsätzlich funktioniert, aber um flexibler bei so einer Bibliothek zu sein, ist es meiner Meinung nach sinnvoller hier eine Variante mit einer C-Api in Form einer .dll bereitzustellen, denn diese kann in annähernd allen anderen Programmiersprachen und auch unter anderen Architekturen verwendet werden.

Hat jemand überhaupt Interesse an so einer Bibliothek, entweder zum selber verwenden oder daran mitzuarbeiten? Aktuell habe ich selber dafür keine direkte Verwendung, aber es könnte sich ja als nützlich erweisen so etwas zur Verfügung zu haben. Und vielleicht ergibt sich auf dieser Basis dann ja noch das ein oder andere nützliche Werkzeug.

 

[Tschoke]

Ich bin mir nicht sicher ob sich der Aufwand lohnt es in C umzusetzen.
Mit .net standard ist man ja recht Architektur unabhängig.
Sprachunabhängig ist man im .net natürlich nicht.
Aber in C müsste man die Bibliothek ja auch je nach Sprache oder Architektur anders kompilieren, Wrapper schreiben oder sonsitiges...
Mich würde mal interessieren, was in diesem Umfeld so alles eingesetzt wird (an Architekturen und Sprachen).
Also meiner Erfahrung nach (heutzutage) meistens .net. Und manchmal noch JavaScript.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn dann in C++ schreiben mit einer C-Api, im Grunde so wie es auch bei Snap7 gemacht ist. Von Snap7 gibt es zwar auch eine komplette .Net managed Variante, die kann aber nicht alles was die andere Bibliothek kann.

Bei der .Net Variante lässt sich das eben nur auch in .Net nutzen, und nicht unter Python, Javascript (denke da an Node/NodeRed). Oder gibt es da eine Lösung?

Aktuell nutze ich für den TLS Teil die OpenSSL Bibliothek, d.h. komplett managed ist das so noch nicht. Ich weiß nicht ob die TLS Varianten in .Net dafür verwendbar sind. Bei OpenSSL lässt sich das über die BIOs von den Sockets trennen, das ist hier notwendig weil TLS auf IsoOnTCP aufgesetzt ist.

 

[Tschoke]

Ich gebe dir ja recht, dass es besser wäre...
Wie gesagt ich frage mich nur ob sich der Mehraufwand lohnt.
Hab grad mal gegoogelt.
Also in Javascript gibt es dafür edge.js und in Python pythonnet.
Hab mit beidem noch nicht gearbeitet. Also keine Ahnung wie gut das funktioniert.
Aber vielleicht hat da ja jemand anders Erfahrungen damit gemacht...

 

[Thomas_v2.1]

Was ich beispielsweise mit libnodave.dll gemacht habe, diese direkt in eine Excel-Anwendung zu integrieren damit der Kunde dort einfach Werte für Wochen und Jahresschaltuhren hinterlegen konnte, und die dann in einem Rutsch mit der SPS abzugleichen. Das fällt mit einer .Net Lösung ja auch schon mal flach.

Leider sind meine C++ Kenntnisse eher bescheiden, da bräuchte es auf jeden Fall jemandem der darin sattelfest ist, und zumindest das Grundkonstrukt vernünftig aufbaut.

 

[Tschoke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch das geht anscheinend:

.NET DLL in VBA (Excel)

I have spent the last 2 days trying to get a basic VB.NET dll that created to work in VBA. I have read every single post on this sight but i keep getting the same error. I create a VB.NET class (...

stackoverflow.com

 

[312C]

Auch das geht anscheinend:

.NET DLL in VBA (Excel)

I have spent the last 2 days trying to get a basic VB.NET dll that created to work in VBA. I have read every single post on this sight but i keep getting the same error. I create a VB.NET class (...

stackoverflow.com

COM Interop funktioniert leider nur mit dem alten .Net Framework (was ja früher oder später sterben wird und womit ja auch die Portabilität weg wäre) sinnvoll, weil .Net meines Wissens nach keine Typelibs mehr erstellt. Dann müsste man manuell die Interfaces in IDL definieren, was je nach Umfang des Projekts nicht ohne ist.

C++ mit verschiedenen Wrappern ist da denke ich doch noch das Mittel der Wahl.

Ich wäre auch an dem Projekt interessiert und würde auch auf jeden Fall Mitarbeit anbieten.

bräuchte es auf jeden Fall jemandem der darin sattelfest ist, und zumindest das Grundkonstrukt vernünftig aufbaut.

Ob ich das erfüllen kann, gerade im Hinblick auf das "vernünftig", kann ich aber schlecht beurteilen. Ich würde es aber auf jeden Fall versuchen wollen.

Viele Grüße,
Robert

 

[Thomas_v2.1]

Mal sehen wie wir da einen Anfang bekommen.

Mein aktueller Stand ist der:
Ich habe mir 2018/2019 einen rudimentären Treiber in C# für die Analyse und Erstellung des Wireshark Dissectors erstellt, der mit einer 1200er mit Firmware V2.2 kommunizieren konnte. Diese Steuerung benötigte aber keinerlei Authentifizierung, und das Protokoll ist in einigen Details anders als das der aktuellen Firmwareversionen, vor allem was das Browsen der Variablen angeht. Das habe ich aber nicht zu Ende entwickelt sondern auf dem Stand belassen.

Auf diesem Stand habe ich jetzt den TLS Teil aufgesetzt, nur um zu sehen ob es damit funktioniert. Darum ist dort kaum Fehlerbehandlung vorhanden, und es sind auch nicht alle neueren Informationen die seitdem im Wireshark Dissector eingeflossen sind dort nachgetragen. Es ist nicht sinnvoll, die .Net Variante jetzt bis zum Ende zu entwickeln und das dann auf C++ zu portieren.

Darum kann der Stand jetzt sich nur mit der Steuerung verbinden, den Variablenhaushalt auslesen (dort fehlt aber noch die Kombination von Unterstrukturen/UDTs), und Variablenwerte anhand der ausgelesenen IDs auslesen.

Der Vorteil ist, dass der Wireshark Dissector ich würde mal sagen zu 90% vollständig ist, sodass man sich da einiges ansehen kann wie etwas funktioniert. Meine Anwendung wirft auch den ausgehandelten TLS-Schlüssel in eine Textdatei aus, damit kann Wireshark dann auch die verschlüsselte Kommunikation dekodieren.

 

[Marvm]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich gebe dir ja recht, dass es besser wäre...
Wie gesagt ich frage mich nur ob sich der Mehraufwand lohnt.
Hab grad mal gegoogelt.
Also in Javascript gibt es dafür edge.js und in Python pythonnet.
Hab mit beidem noch nicht gearbeitet. Also keine Ahnung wie gut das funktioniert.
Aber vielleicht hat da ja jemand anders Erfahrungen damit gemacht...

Zur Info: Ich habe zum arbeiten mit TIA Openness in Python mithilfe von pythonnet gute Erfahrungen gemacht.

 

[Thomas_v2.1]

Ich werde die Tage mein .Net Projekt mal soweit aufarbeiten, dass es von jemand anderem zumindest einmal getestet werden kann. Ich habe nämlich bisher auch nur an einer 1200er Steuerung getestet, nicht dass sich da eine 1500er doch noch anders verhält. Vielleicht hat jemand die Gelegenheit das mal an einer 1500er mit aktueller Firmware die TLS unterstützt zu testen.

So umfangreich ist der Code letztendlich auch gar nicht, man muss nur alle möglichen Objekte, Attribute und Datentypen des Protokolls verarbeiten können, da es keine fixen Offsets gibt sondern alles aufeinander aufbaut. Da ich aufgrund begrenzter C# Kenntnisse nicht alle neuesten Funktionen nutze, lässt sich bestimmt auch vieles annähernd 1:1 nach C++ übernehmen.

Aktuell ist dann alles noch auf die neuen CPUs mit TLS unterstützender Firmware beschränkt. Und es darf auch kein CPU Passwort gesetzt sein, das habe ich mir auch noch nicht angesehen wie das funktioniert.

 

[312C]

Ich werde die Tage mein .Net Projekt mal soweit aufarbeiten, dass es von jemand anderem zumindest einmal getestet werden kann. Ich habe nämlich bisher auch nur an einer 1200er Steuerung getestet, nicht dass sich da eine 1500er doch noch anders verhält. Vielleicht hat jemand die Gelegenheit das mal an einer 1500er mit aktueller Firmware die TLS unterstützt zu testen.

So umfangreich ist der Code letztendlich auch gar nicht, man muss nur alle möglichen Objekte, Attribute und Datentypen des Protokolls verarbeiten können, da es keine fixen Offsets gibt sondern alles aufeinander aufbaut. Da ich aufgrund begrenzter C# Kenntnisse nicht alle neuesten Funktionen nutze, lässt sich bestimmt auch vieles annähernd 1:1 nach C++ übernehmen.

Aktuell ist dann alles noch auf die neuen CPUs mit TLS unterstützender Firmware beschränkt. Und es darf auch kein CPU Passwort gesetzt sein, das habe ich mir auch noch nicht angesehen wie das funktioniert.

Spontan hätte ich eine 1515 mit Firmware 2.9 da. Ich habe aber da noch keinerlei Kenntnisse, was das Protokoll an sich oder die Unterschiede der einzelnen FW-Stände diesbezüglich angeht. Ich habe mir gestern allerdings deinen Dissector mal runtergeladen und wollte mich da jetzt zunächst etwas einarbeiten. Zusätzlich den Code zum anschauen und schonmal ausprobieren kann dazu bestimmt nicht schaden. Außerdem hab ich mir, weil ich damit generell vorher (außer als Nutzer) noch nie in Kontakt war, mal die Windows-eigene SChannel TLS API angesehen und diese ausprobiert. Auch wenn für ein portables Projekt OpenSSL sinnvoller zu sein scheint.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für die, die daran Interesse haben, hänge ich eine Wireshark Beispielaufzeichnung an. Die TLS Schlüssel sind integriert, darum kann das direkt dekodiert werden. Es findet ein Verbindungsaufbau statt, dann lese ich einige Informationen über den Variablenhaushalt aus (explore), anschließend werden die Werte von zwei Datenbausteinvariablen gelesen.

 

[Jochen Kühner]

Hast du das Projekt denn schon irgendwo online? In C# könnte Ich mithelfen, in C++ müsste ich mich auch erst mal wieder einarbeiten.
Man könnte ja auch noch go, rust oder was anderes überlegen. Die können glaube alle in DLLs mit C Interface kompiliert werden.
Go läßt sich anscheinend recht einfach für alle möglichen Architekturen übersetzen.

 

[Jochen Kühner]

Ich würde die Connection gerne in meine Toolbox einbauen. Diese abstrahiert ja im Moment die PLC Connection über libnodave oder zu einer S5 über die gleiche API.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe das Projekt noch nicht online. Ich weiß nicht ob es zum jetzigen Stand schon sinnvoll ist als git öffentlich anzulegen, da gehört dann ja auch Lizenz mit dazu. Ich würde ja die LGPL bevorzugen.

Ich würde das vorerst in C# fortführen, damit erst einmal ein funktionsfähiges Grundkonstrukt steht. Denn einige Dinge muss ich auch noch selber ausprobieren wie es funktioniert, die Daten in Wireshark anzuzeigen ist eben noch etwas anderes als die auch korrekt abzufragen. Ich habe es gestern noch an TIA Plcsim V17 (+Nettoplcsim) getestet, damit funktioniert die Kommunikation wie auch mit einer 1200er mit Firmware 4.5. Also zumindest das browsen des Variablenhaushalts und das Auslesen und Berechnen der Zugriffs-ID (z.B. bei Bool-Arrays scheint es noch ein Padding zu geben), und das Lesen der Variablenwerte.

Ich kann das Projekt zum jetzigen Stand aber mal zur Verfügung stellen.

 

[Thomas_v2.1]

Ich habe bei Github ein entsprechendes Projekt angelegt:

GitHub - thomas-v2/S7CommPlusDriver

Contribute to thomas-v2/S7CommPlusDriver development by creating an account on GitHub.

github.com

Das vorhandene Testprogramm liest den Variablenhaushalt aus, und versucht dann alle Werte zu lesen. Ich habe es bisher noch nicht an einem großen Projekt getestet. Aber Werte von allen Basistypen sollten gelesen werden können. Strings werden z.Zt. als Array aus Einzelwerten angezeigt.

Wichtig ist, entweder OpenSSL zu installieren, oder zumindest die beiden Dlls in ein erreichbares Verzeichnis zu legen.

 

[Thomas_v2.1]

Bei der aktuellen Schnittstelle um Variablen zu lesen/schreiben habe ich mich habe ich mich ganz grob an die von OPC-UA orientiert. Ich finde diese aber viel zu kompliziert mit den zwei Parametern für die beiden Listen mit Zugriffsnamen und den Werten. Wenn man Zugriff rein über den Namen zulässt und beispielsweise bei jedem Start automatisch alles in der SPS browst und die Zugriffs-IDs überhaupt nicht nach außen führt, ist das Problem, dass TIA alles mögliche als Bezeichner zulässt. Z.B. kann ich entweder ein Array of Int 1..2 anlegen das "DatenArray" heßt, oder 2 Integervariablen die DatenArray[0] und DatenArray[1] heißen. Der Vorteil, das alles intern zu führen ist noch, dass die Zugriffsbeschränkungen nicht so einfach von außen aufgehoben werden können. Denn die Haken die jemand im TIA-Portal setzt wenn eine Variable nicht sichtbar oder nicht schreibbar sein soll, sind nur eine Empfehlung an die Client-Anwendung das so zu verarbeiten. Und da wäre ich schon dafür das auch korrekt zu berücksichtigen, da sich auch ganz normal Werte schreiben lassen wenn jemand den Haken bei "Schreibbar" herausgenommen hat.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auf jeden Fall müssen noch diverse Dinge getestet werden, und wenn man mit Plcsim testen weiß man ja auch nicht, ob das Verhalten jetzt spezifisch an Plcsim liegt oder nicht.

Beispielsweise gibt die CPU zurück, wie viele Variablen in einem Request gelesen werden können. Das funktioniert auch so, bei einer 1200er die ich mal da hatte zum Testen konnte diese nur 50 Variablen, bei 51 gab es einen Fehler, ist Ok weil die Anzahl auch so zurückgegeben wurden. Plcsim V18 gibt 100 zurück, versucht man aber 100 zu lesen funktioniert das nur, wenn diese 100 auch in eine PDU passen. Das ist aber variabel je nach dem wie viele IDs diese Variable zum Zugriff benötigt. Ergibt sich aus 100 Variablen eine fragmentierte PDU (was ja theoretisch erlaubt ist) und man schickt diese an Plcsim, ploppt da eine Unhandled Exception auf.
Und wenn man mal so Spezialitäten wie Multidimensionale Arrays im Maximalausbau testen möchte, stellt man fest, dass das in WinCC 7.x auch nicht mal funktioniert. Da wird auf völlig falsche Indizes geschrieben.

 

[JeremyTheocharis]

Hallo Thomas,

wenn du Unterstützung braucht, melde dich gerne bei uns (United Manufacturing Hub). Das GitHub Projekt habe ich auch direkt gestarred. Wir haben einen ganzen IIoT Stack auf Open-Source aufgebaut (https://github.com/united-manufacturing-hub/united-manufacturing-hub) und könnten hier ggf. unterstützen.

Viele Grüße
Jeremy

 

[didicool]

Hallo Thomas,
bin hier im Forum bisher eher passiv unterwegs - meine Arbeit (und mein Wissen) gehört letztendlich meinem Arbeitgeber...
Aber vor dieser Leistung ziehe ich den Hut - Wahnsinn. Wir fahren derzeit noch mit 319 CPU en; gegen Tia und 1500er konnte ich bisher erfolgreich wehren - jetzt habe ich eine 1517 Fw 2.9.4 und TIA 17 vor mir. Da mein Aufgabengebiet vorrangig Monitoring und Diagnose ist, habe ich mir Dein Projekt angeschaut und ausprobiert - echt toll!
Meine Frage ist, wie ich an eine Key.log komme, mit der ich die Kommunikation in Wireshark zwischen TIA und SPS anschauen kann.
Gibt es da irgendeine Möglichkeit? Mit JetBrains Rider könnte ich direkt Variablen aus TIA abgreifen...
Gewonnene Erkenntnisse würde ich gern teilen
Danke und Viele Grüße
Dieter