Externe Bibliothek (DLL, SO, C...) für plattformübergreifende Verwendung

[P51D]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen

Ich wusste nicht so recht, in welches Forum ich mit dieser Frage sollte, also entschuldigt wenn ich hier falsch bin.

Momentan beschäftige ich mich (wieder einmal) mit dem selben Thema: Integration eines selber entwickelten Sensors (Modbus-Protokol) in eine SPS an einem anderen Firmenstandort.
Theoretisch ist gibt es ja RS232/RS485 Module, die man in eine Steuerung einbinden und auch mit diesen kommunizieren kann.

Wie sieht es nun aus, wenn etwas mehr "Intelligenz" nötig ist? Beispielsweise die Abstraktion des Sensors so gelöst ist, damit man eine Funktion aufrufen kann um Aktion XY zu bekommen (da sind Register, Modbus-Protokoll etc. für die Steuerung selber unwichtig). So könnte man ebenfalls ein FW-Update des Sensors über die RS232 Schnittstelle machen.

Unter Windows und Linux gibt es ja die Möglichkeit für DLLs/SO. Gibt es das auch für B&R, Siemens und Beckhoff Steuerungen? Weil so könnten wir die Intelligenz in eine solche Bibliothek Verpackung und sie unseren Kollegen mit dem Sensor mitgeben und sie müssten nicht jeweils wieder von Vorne beginnen (reduziert die Zeit zur Umsetzung und Fehlerquellen).
Oder kann man C Files und C++ Klassen in jeder SPS Sprache "Importieren"?
Ich meine, wenn wir eine Bibliothek für Mikrocontroller und eigene PC-Tools (C++ Kompiler, DLL, SO reichen da schon) plattformunabhängig machen können und überall nutzbar ist, müsste das ja auch für SPS gelten.

Irgendwie kann/will ich mir nicht vorstellen, dass die SPS-Welt so unfähig ist, solche seit Jahrzehnten standardisierte Elemente zu nutzen.
Gibt es bei euch jemanden, der da mehr weiss?

Besten Dank
P51D

 

[Bitmanipulator]

Hallo P51D,

Glückwunsch, Du hast es geschafft mit Deinem Unwissen eine komplette Branche zu verunglimpfen. Das Dein Posting aufgrund schlechter Satzbildung nur nach mehrmaligem lesen verständlich ist, ist eine andere Sache.
Zum Thema: In der Automatisierung gibt es Deine Anforderungen schlicht und einfach nicht. Wenn jemand etwas an eine SPS anschließen möchte, dann kümmert man sich selbst darum. Das gilt sowohl für Bastler als auch für Sensorhersteller. In der Regel wird ein Treiber geschrieben, der auf einer SPS/SPS-Serie funktionsfähig ist und dann wird der Treiber mit dem Sensor ausgeliefert oder auf der Homepage bereitgestellt oder was auch immer.

Grüße

 

[P51D]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi

Mhm, ok sorry. Da ist EIN einziges Wort in EINEM Satz falsch... wenn dadurch schon der ganze Post für dich nicht mehr lesbar ist kann ich dir nicht helfen. Und wenn du mit solchen Sätzen schon Probleme hast, dann will ich ja nicht wissen wie es mit etwas komplexeren Dokumenten (Patenten, Papers, unvollständige Datenblätter, Normen, Prüfberichten...) aussieht. Aber ja, das ist definitiv ein anderes Thema.

Ich möchte dir ja nicht auf den Schlips treten, aber dein Post sagt noch viel weniger aus und ist unverständlicher, als meiner.
Meine Anforderung ist sicherlich Daly-Business in der SPS Welt. Wenn dem nicht so wäre, würde es keine neuen Sensoren/Aktoren geben, oder diese genau für einen einzigen SPS-Typ kombiniert mit einer einzigen Software-Version (Release) funktionieren. Und wenn man ein Update bekommt oder die SPS wechseln will/muss schmeisst man alles in die Tonne und fängt von vorne an...

Mir ist natürlich klar, dass der SPS Programmierer oder der Sensor-Hersteller für die Integration eines Sensors verantwortlich ist. Der Hersteller kann dem SPS Programmieren nur Arbeit abnehmen und die Hardware-Abstraktion machen. Das ist ja der Grund, wieso ich frage.
Ein Treiber unter Windows ist kann eine DLL sein und unter Linux sind das SO-Files, auf einem Mikrocontroller kann C und C++ Source-Code als Treiber angesehen werden. Und aus C,C++ Files eine DLL/SO zu erzeugen ist kein Problem. Und mit etwas Können und entsprechender Abstraktion sind die Source-Files die gleichen (Mikrocontroller, Linux und Windows nutzen alle die gleichen "Quellen"). Entsprechend deinem Alias müsstest du das ja wissen.
Was ist nun auf der SPS ein Treiber und gibt es einen Treiber-Standard der von allen unterstützt wird (DAS war meine Frage!)? Können die gleichen C/C++ Files wie für einen Mikrocontroller/Windows/Linux verwendet werden, indem sie einfach für die SPS kompiliert werden? Somit hätte man ja die gleiche Ausgangslage für alle Plattformen, was genau das ist was ich will.

Dass am Schluss die Logik und das UI für jede SPS gemacht werden muss ist mir auch klar. Nur möchte ich die nötige "Intelligenz" in einen plattformübergreifend nutzbaren Treiber packen (oder zumindest den Source-Code so schreiben).

Ich hoffe ich habe mich nun klarer und verständlicher ausgedrückt.
Besten Dank,
Gruss

 

[StructuredTrash]

SPS-Hersteller werden Dir in der Regel nicht die Möglichkeit bieten, ihre Firmware zu ändern oder zu erweitern. Die übliche Vorgehensweise ist deshalb, die Intelligenz in den Sensor zu packen und seine Funktionalität der SPS über ein standardisiertes Feldbusprotokoll zur Verfügung zu stellen.

 

[bitsearcher]

Schau halt einfach mal was Du zum Thema gsd Dateien findest. Das sollte in die Richtung gehen die Du suchst.

 

[Beckx-net]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus,

es gibt einige "neuere" SPS-Hersteller die es erlauben C/C++ Code im SPS-Kontext aufzurufen (z.B. Beckhoff TwinCAT 3 oder Phoenix PLCNext, Siemens ET2ßßSP OpenController). Ich meine sogar das B&R so etwas auch anbietet. Aber von einem "Standard" kann man hier noch nicht sprechen.

 

[JanB1]

Hallo P51D,

Glückwunsch, Du hast es geschafft mit Deinem Unwissen eine komplette Branche zu verunglimpfen. Das Dein Posting aufgrund schlechter Satzbildung nur nach mehrmaligem lesen verständlich ist, ist eine andere Sache.
Zum Thema: In der Automatisierung gibt es Deine Anforderungen schlicht und einfach nicht. Wenn jemand etwas an eine SPS anschließen möchte, dann kümmert man sich selbst darum. Das gilt sowohl für Bastler als auch für Sensorhersteller. In der Regel wird ein Treiber geschrieben, der auf einer SPS/SPS-Serie funktionsfähig ist und dann wird der Treiber mit dem Sensor ausgeliefert oder auf der Homepage bereitgestellt oder was auch immer.

Grüße

Das war dann doch eine etwas heftige Reaktion, findest du nicht?

 

[Draco Malfoy]

Das war dann doch eine etwas heftige Reaktion, findest du nicht?

Die Reaktion war völlig angemessen. Da kommt mal einer her und verzapft einen unwahrscheinlichen Stuß, da er offensichtlich null Ahnung von der Materie hat. Im Übringen, irgendwie eine Standard-Situation bei allen Hochsprachenprogrammierern, die ich kenne.

Ähnlich lustig wie der Stuxnet-Report von R. Langner, für den er, glaube ich, eine immense Mediale Aufmerksamkeit geerntet hat. In dem Report wird auf zig Seiten breit und lang erklärt, wie ein Hochsprachenprogrammierer-Team es denn endlich geschafft hat irgendwelche Ansätze der SPS-Welt zu verstehen. Janz tolle Leistung.

 

[JanB1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Reaktion war völlig angemessen. Da kommt mal einer her und verzapft einen unwahrscheinlichen Stuß, da er offensichtlich null Ahnung von der Materie hat. Im Übringen, irgendwie eine Standard-Situation bei allen Hochsprachenprogrammierern, die ich kenne.

Dann macht man diese Person freundlich, aber mit Nachdruck darauf Aufmerksam, was für einen Stuss sie da verzapft hat. Sonst leidet die Professionalität. Nur weil sich das Gegenüber nicht professionell verhält oder keine Ahnung hat, wovon er/sie da spricht, muss man ja nicht gleich unfreundlich werden. ES SEI DENN die Person versucht dir deinen Job zu erklären. Da würd ich auch ungehalten werden.

Und das hat nichts mit Hochsprachenprogrammierern zu tun. Das können auch andere. Hochsprachenprogrammierer kennen halt einfach ihre Materie besser und gehen davon aus, dass sich eine SPS in etwa gleich verhält wie ein PC. Was halt nicht so ganz stimmt. Und nicht umsonst haben wir uns Jahrelang gebildet, um uns nun "Automationsfachmann" (oder wie auch immer man es nenne will) nennen zu können. Es ist nunmals eine komplexe Materie.

 

[Draco Malfoy]

Dann macht man diese Person freundlich, aber mit Nachdruck darauf Aufmerksam, was für einen Stuss sie da verzapft hat. Sonst leidet die Professionalität.

Ok, dann also nochmal für Windows, Linux, Unix, Wanix und andere C/C++/C#/java/Delphi und andere hochintelligente Hochsprachenprogrammierer und SPS-Profanen:

Das Wort "Treiber" ist auf die SPS-Welt so nicht übertragbar. Es gibt bei einem extern angebundenen Device, wie zum Beispiel einem PN/DP Slave nur zwei definierte Arten der Kommunikation, das sind:

- 1. Zyklische Kommunikation über ein zyklisches Telegramm (X-Byte in Empfangsrichtung, Y-Byte in Senderichtung). Diese Daten werden im Buszyklus bzw. Prozessabbildzyklus aktualisiert.
- 2. Azyklische Kommunikation. Dabei kann ich über eine bestimmte Systemroutine (SFB52/53) auf ein bestimmtes Datum oder mehrere Daten im Gerät zugreifen. Dieser Zugriff ist deutlich langsamer.

Was ist im Idealfall ein Treiber auf der SPS-Seite ?

EIn Baustein, der:

- zyklische Daten vom Gerät empfängt und diese in benutzerfreundlicher Form an seiner Schnittstelle bereitstellt,
- zyklische Daten von der Applikation zum Gerät sendet,
- Bei Bedarf und für spezielle Aufgaben wie zum Beispiel Nullwertabgleich, bestimmte spezifische Abfragen, azyklische Kommunikation mit dem Gerät abwickelt;
- Diagnose des Geräts durchführt und mir Informationen über seinen Zustand bereitstellt.

Alle diese Zugriffe erfolgen mit Bordmitteln der SPS, solchen wie SFC14/15, SFC51, SFB 52,53,54 und ggf. SFC12/13. Diese Systemfunktionen genügen bestimmten Spezifikationen und funktionieren für alle Geräte gleich. Beispielsweise kann ich mit einem SFC51 einen SZL-Teillisteneintrag auslesen und so Diagnoseinformationen über den Zustand meines Geräts am Bus gewinnen.

 

[Blockmove]

Die Reaktion war völlig angemessen. Da kommt mal einer her und verzapft einen unwahrscheinlichen Stuß, da er offensichtlich null Ahnung von der Materie hat. Im Übringen, irgendwie eine Standard-Situation bei allen Hochsprachenprogrammierern, die ich kenne.

Ähnlich lustig wie der Stuxnet-Report von R. Langner, für den er, glaube ich, eine immense Mediale Aufmerksamkeit geerntet hat. In dem Report wird auf zig Seiten breit und lang erklärt, wie ein Hochsprachenprogrammierer-Team es denn endlich geschafft hat irgendwelche Ansätze der SPS-Welt zu verstehen. Janz tolle Leistung.

Mit Teil 1 hast du - meiner Meinung nach - recht.
Die Reaktion war angemessen.

Zu Teil 2:
Den Langner-Report zu Stuxnet finde ich persönlich gar nicht so schlecht.
Du must hier einfach mal die Zielgruppe berücksichtigen. Das sind nämlich (angebliche) IT-Security Eyperten mit dem SPS-Wissen des TE.
Wenn dir ein Experte auf die Frage "Werden Sie doch bitte mal konkret und erklären uns welche Massnahmen für das Absichern einer einer Siemens S7 300/400 gegen Angriffe aus dem Netz notwendig sind?" erklärt:
"Basis des ganzen ist natürlich ein vernünfiger Viren- und Malwareschutz. Steuerungen sind heute nichts anderes mehr als ihr Büro-PC. Daher ist eine Härtung des Betriebssystems wichtig. Wir arbeiten hier mit den namhaften Herstellern zusammen, Von uns bekommen Sie dann eine auf Ihre Anforderungen angepasste Version, die Sie nach der Grundinstallation einspielen".
Daraufhin habe ich nochmals nachgefragt "Wir reden hier von Standard Siemens Anlagensteuerungen. Welche Erfahrungen hat ihr Haus damit". Anwort "Das ist unser Tagesgeschäft darum sind wir hier" ...
Weitere Nachfragen hab ich mir gespart

Gruß
Blockmove

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn dir ein Experte auf die Frage "Werden Sie doch bitte mal konkret und erklären uns welche Massnahmen für das Absichern einer einer Siemens S7 300/400 gegen Angriffe aus dem Netz notwendig sind?" erklärt: "Basis des ganzen ist natürlich ein vernünfiger Viren- und Malwareschutz. Steuerungen sind heute nichts anderes mehr als ihr Büro-PC. Daher ist eine Härtung des Betriebssystems wichtig. Wir arbeiten hier mit den namhaften Herstellern zusammen, Von uns bekommen Sie dann eine auf Ihre Anforderungen angepasste Version, die Sie nach der Grundinstallation einspielen".

Das ist natürlich harter Tobak. Der Punkt ist, ich finde es unbegreiflich, daß Leute die Ahnung von Informatik haben sollten in der Regel vor einer SPS stehen wie ein Ochs vor dem Kleiderschrank. Ich habe mich mal mit den Langner-Leuten unterhalten. Die Code-Schnipsel die sie herausgegeben haben sehen nämlich danach aus, als wären sie von einem SCL Compiler generiert. Oder, das was dort abgebildet ist, ist die reine MC7 Ebene. Habe die gefragt, ob die denn versucht hatten, ein Projekt von einer infizierten CPU mal zurückzuladen und zur Analyse den Fachkräften bereitzustellen. Daraufhin wurde mir gesagt, daß das sehr kompliziert sein soll und gar nicht gehen würde. Es gab auch Fragen, ob ich ein Stück vom AWL-Code revers kompilieren könnte. Eventuell schon. Wenns denn den gesamten Baustein als AWL-Quelle mal geben würde, und nicht nur den MC7-Rumpf ohne Deklarationsteil. Richtig niedlich ist auch diese C-Syntax in ihrem Bericht, mit geschweiften Klammern. Angewendet auf den MC7 Code.

 

[Blockmove]

@Draco
Langner gehört schon zu den seriösen in der Branche.
Wir haben deren Kommunikationbibliothek selber auch jahrelang in unseren PC-Programmen eingesetzt.
Also von S7-Kommunikation haben die Jungs und Mädels Ahnung.
Stuxnet auseinander zu pfrimmeln, war sicher eine saumässige Arbeit.
Bei den infizierten Zentrifugen handelt es sich ja nicht gerade um öffentlich zu gängliche ANlagen mit frei verfügbaren Schaltplänen.

Gruß
Blockmove

 

[maxder2te]

Was ist im Idealfall ein Treiber auf der SPS-Seite ?

EIn Baustein, der:
- zyklische Daten vom Gerät empfängt und diese in benutzerfreundlicher Form an seiner Schnittstelle bereitstellt,
- zyklische Daten von der Applikation zum Gerät sendet,
- Bei Bedarf und für spezielle Aufgaben wie zum Beispiel Nullwertabgleich, bestimmte spezifische Abfragen, azyklische Kommunikation mit dem Gerät abwickelt;
- Diagnose des Geräts durchführt und mir Informationen über seinen Zustand bereitstellt.

Exakt sowas nennt man Treiber, wobei man sich nicht auf EINen Baustein einschränken sollte.

Der T-Teil der S7-300T und S7-1500 CPUs kann auch als Treiber betrachtet werden, es geht im Wesentlichen um das Schaffen von Abstraktionsschichten und (vereinfachten) Schnittstellen.