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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 14

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
    113
    Danke
    0
    Erhielt 18 Danke für 18 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. Folgender Benutzer sagt Danke zu Bitmanipulator für den nützlichen Beitrag:

    Draco Malfoy (29.10.2017)

  4. #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

  5. #4
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 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.

  6. #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.

  7. #6
    Registriert seit
    03.09.2009
    Beiträge
    129
    Danke
    15
    Erhielt 19 Danke für 19 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.

  8. #7
    Registriert seit
    12.08.2014
    Ort
    Basel
    Beiträge
    208
    Danke
    23
    Erhielt 20 Danke für 19 Beiträge

    Standard

    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?

  9. #8
    Registriert seit
    16.10.2012
    Beiträge
    737
    Danke
    51
    Erhielt 32 Danke für 26 Beiträge

    Standard

    Zitat Zitat von JanB1 Beitrag anzeigen
    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.

  10. #9
    Registriert seit
    12.08.2014
    Ort
    Basel
    Beiträge
    208
    Danke
    23
    Erhielt 20 Danke für 19 Beiträge

    Standard

    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    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.
    Geändert von JanB1 (30.10.2017 um 09:50 Uhr)

  11. #10
    Registriert seit
    16.10.2012
    Beiträge
    737
    Danke
    51
    Erhielt 32 Danke für 26 Beiträge

    Standard


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

  12. Folgender Benutzer sagt Danke zu Draco Malfoy für den nützlichen Beitrag:

    Automatonator (08.12.2017)

Ä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
  •