Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 7 von 7

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

  1. #1
    Registriert seit
    12.10.2017
    Beiträge
    2
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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
    Zitieren Zitieren Externe Bibliothek (DLL, SO, C...) für plattformübergreifende Verwendung  

  2. #2
    Registriert seit
    13.09.2010
    Beiträge
    111
    Danke
    0
    Erhielt 17 Danke für 17 Beiträge

    Standard

    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

  3. #3
    P51D ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    12.10.2017
    Beiträge
    2
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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

  4. #4
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    734
    Danke
    27
    Erhielt 161 Danke für 139 Beiträge

    Standard

    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.

  5. #5
    Registriert seit
    27.08.2010
    Ort
    OWL
    Beiträge
    19
    Danke
    2
    Erhielt 2 Danke für 1 Beitrag

    Standard

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

  6. #6
    Registriert seit
    03.09.2009
    Beiträge
    128
    Danke
    15
    Erhielt 18 Danke für 18 Beiträge

    Standard

    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.

  7. #7
    Registriert seit
    12.08.2014
    Ort
    Basel
    Beiträge
    142
    Danke
    14
    Erhielt 12 Danke für 11 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Bitmanipulator Beitrag anzeigen
    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?

Ähnliche Themen

  1. Antworten: 5
    Letzter Beitrag: 18.07.2017, 16:34
  2. [C++ - LibNoDave] Compilerprobleme bei der Verwendung der DLL
    Von Rusticus im Forum Hochsprachen - OPC
    Antworten: 8
    Letzter Beitrag: 28.04.2015, 16:38
  3. Externe Bibliothek einbinden B&R
    Von knuppel im Forum Sonstige Steuerungen
    Antworten: 0
    Letzter Beitrag: 14.11.2014, 07:45
  4. Antworten: 0
    Letzter Beitrag: 23.04.2013, 21:41
  5. Verwendung der OSCAT Bibliothek
    Von Vaninger im Forum Sonstige Steuerungen
    Antworten: 1
    Letzter Beitrag: 26.02.2009, 14:38

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •