Profinet via libnodave

Medium · 22 Mai 2015

Hallo zusammen,

ein Kunde von uns stellt demnächst seine Steuerungen um, so dass eine Software von uns nicht mehr via OPC mit der SPS kommunizieren kann wie bisher. Wir wurden gefragt, ob eine Profinet Verbindung ebenfalls möglich wäre. Da ich aber eher in der Softwareentwicklung als denn bei Steuerungen zu Hause bin, habe ich ein paar Unklarheiten.

1) Brauche ich für Profinet eine spezielle Schnittstelle am PC, oder geht das prinzipiell über jede "normale" Ethernet-Karte (bzw. Onboard)?

2) Neben OPC habe ich mit zwei weiteren Kommunikationsmodellen gearbeitet: Projektierte Verbindungen und dann "nackt" über Sockets via Ethernet, und ISO-over-TCP mittels der libnodave. Kann ich mit einer der beiden Varianten auch bei Profinet dran gehen? Worauf wäre da zu achten, bzw. gibt es da Beispiele?

3) Es kann sein, dass unser Programm auf ein Siemens Panel PC kommt, dass einen Onboard CP1616 hat, der in den Bus aufgenommen wird. Komme ich da ggf. dran? (Entwickelt ist unsere Software mit Delphi. Ich bräuchte dafür dann wahrscheinlich eine API. Gibt es sowas?)

Letztlich ist es uns und dem Kunden relativ egal welche Verbindungsart im Detail genutzt wird, so lange es nur nachher über Profinet zur SPS geht. Ich würde mich riesig über ein paar Infos freuen. Danke euch im Voraus!

JesperMP · 22 Mai 2015

Meinst du wirklich "Profinet", also dein PC soll Profinet IO Controller oder Profinet IO Device sein ?
Oder meinst du über Ethernet mit Siemens SPSen verbinden ohne OPC ?

Medium · 22 Mai 2015

Wirklich Profinet. Wäre es einfach Ethernet, würde ich mit ISO-over-TCP via libnodave vorgehen. Das mache ich schon seit Jahren erfolgreich, aber bei Profinet bin ich (noch) überfragt.
Edit: Der PC würde ein Device sein, kein Controller.

JesperMP · 22 Mai 2015

Es gibt von Softing ein Profinet Device stack:
http://industrial.softing.com/en/pr...-io-device-slave-portable-protocol-stack.html
Wurde mich auch interessieren was es kostet. Umsonst bekommt man es nicht.
Ich vermute (aber bin nicht sicher) das es mit eine herkömlichen Netzkarte funktioniert.

Es gibt vielleicht auch andere Hersteller von Profinet stacks.

Es gibt auch Hersteller von Profinet Karten wobei man ein Hersteller-Spezifike Treiber (edit: oder API) in seine Programme einbinden kann.

JesperMP · 22 Mai 2015

Wenn man darüber denkt ....

Warum ist es nicht akseptabel mit OPC oder eine andere 'normalen' Weise mit der SPS zu kommunizieren ?
'Echten' Profinet ist übertrieben wenn es nur um normalen HMI oder Datenbank Anbindung handelt. Und dazu auch unflexibel.
Will man ein mehr zukunftsicherer Lösung als OPC DA ? Dann überleg OPC UA.

LowLevelMahn · 22 Mai 2015

Wirklich Profinet. Wäre es einfach Ethernet

Profinet ist doch auch nur auf Ethernet basierend - d.h. du solltest doch libnodave nutzen können - ansonsten kannst du das einfache ISO/libnodave/Protokoll vergessen und musst den Datenaustausch direkt aus der SPS mit dem PC machen - dauert bestimmt eine weile das zu realisieren und wird bestimmt auch nicht billig

JesperMP · 22 Mai 2015

Meines wissens ist der Profinet stack ziemlich kompliziert.

Medium · 22 Mai 2015

OPC kommt nicht mehr in Frage. So ziemlich alle Kunden von uns versuchen das aktiv mittelfristig komplett zu verbannen wo es nur geht, auch der hier betroffene, und ich begrüße das. Das Profinet wird natürlich nicht nur für ein bisschen HMI gemacht - das gesamte Werk wird darauf konsolidiert (einer der größten Deutschen Farbenhersteller, da steht schon einiges mehr hinter). Die Frage die man dort nun hat ist: Kann unser System nach der Umstellung ohne zu großen Aufwand in diese Struktur eingebunden werden, während die selbe Funktion gegeben bleibt?

Die SPS ist nicht von uns, und wir dürfen da auch nicht dran. Ebenso ist der IPC nicht dediziert für unser Programm, und jede Installation von Treibern o.ä. bedarf der Prüfung und Zustimmung (der recht strengen) IT-Abteilung des Kunden. Eine Lösung die ohne große Treiberpakete und Brimborium auskommt wäre da natürlich das einfachste, ansonsten müssen wir abklären ob Vorgaben diesbzlg. abgesegnet werden.

LowLevelMahns Antwort klingt hier aber sehr spannend: Wenn die SPS über Ethernet am PC hängt (vermutlich über diverse Switches hinweg), und auf dieser Leitung wird Profinet "gesprochen", kann ich diese dann gleichzeitig auch für ISO-over-TCP nutzen? Versteht insbesondere die SPS was ich von ihr dann will? Weil dann würden ja 2 völlig unterschiedliche Protokolle auf ein und derselben Schnittstelle gesprochen. Wenn das geht, wären wir natürlich sehr elegant aus dem Schneider!

JesperMP · 22 Mai 2015

Du schreibst dein PC soll Profinet Device sein. Das geht meines wissens nicht mit Libnodave. (edit: Sonnst ware Libnodave die Hammer :icon_lol

Du weist doch das Profinet IO ist nicht nur eine andere Weise dasselbe wie OPC DA ist ?
Z.B du hast pro Device maximal 1440 Byte zur Verfügung. Sehr viel ? Nein, das entspricht nur 360 REALs. Wenn in beide Richtungen Daten gesendet werden muss, dann nur 180 REALs.
Wenn eine Änderung eingeführt werden muss, dann müssen Controller und Device neu konfiguriert werden, und neugestartet werden, was in die meistens Anlagen wenn der Produktion läuft eine no-no ist.
Usw..

Es heist ja auch Profinet IO Controller und Profinet IO Device weil es für E/A in der Feld gemeint ist.

OPC kommt nicht mehr in Frage. So ziemlich alle Kunden von uns versuchen das aktiv mittelfristig komplett zu verbannen wo es nur geht, auch der hier betroffene, und ich begrüße das.

Die Gründe wurde ich gerne wissen.

Die SPS ist nicht von uns, und wir dürfen da auch nicht dran. Ebenso ist der IPC nicht dediziert für unser Programm, und jede Installation von Treibern o.ä. bedarf der Prüfung und Zustimmung (der recht strengen) IT-Abteilung des Kunden. Eine Lösung die ohne große Treiberpakete und Brimborium auskommt wäre da natürlich das einfachste, ansonsten müssen wir abklären ob Vorgaben diesbzlg. abgesegnet werden.

OPC UA ist die Lösung.

Jemand hat diese Forderung (Muss Profinet IO Device sein, darf keine weitere Treiber installieren) geschrieben. Frag dise Person wie er sich vorstellt du soll es erledigen.

Medium · 22 Mai 2015

Gründe gegen OPC: Es gibt zu viele Alternativen das gleiche zu erreichen, die erheblich weniger fummelig zu konfigurieren sind - insbesondere wenn mehrere Windows-PCs mitspielen, wohlmöglich noch unter verschiedenen Versionen (DCOM sei Dank). Die meisten haben wohl zu viel Erfahrung mit tagelangen Konfigurationssessions (auch mit externen Experten zusammen) durch, und da keine Lust mehr drauf.
Und aus meiner Sicht als Entwickler "fühlen" sich nahezu alle OPC-Lösungen beim Programmieren sehr "klobig" an. Ein lockeres Protokoll via Sockets empfinde ich zumindest als viel eleganter im Umgang. Da spielt sicherlich auch persönliche Präferenz mit rein, keine Frage. OPC UA hatten wir noch nicht im Einsatz.

Wenn du schreibst OPC UA sei die Lösung, wie kann ich via OPC UA mit Profinet kommunizieren? Wir können schlecht unserem Kunden sagen: Hey, deine bisher aufgewendeten Monate an Planung und Vorbereitung kannst du bitte streichen, weil unsere Hand voll kleiner Tools will das nicht können. Bitte mache doch einfach alles nochmal neu mit OPC UA. Die paar 100k€ an jetzt falscher Hardware schreibt ihr ja locker ab.
Die werden uns hinterherlachen nachdem sie uns vom Dach getreten haben. Und dann anstoßen.

Natürlich ist Profinet I/O. Mehr sollen wir auch nicht. Ein paar Words lesen, ein paar schreiben. Lesen so alle 1-2 Sekunden ein Mal, schreiben bei Bedienung - so etwa 1x pro Stunde grob. Der von dir genannte Rahmen wäre da weit mehr als ausreichend.

Es gibt nicht "diese eine" Person, die die Vorgaben gemacht hat. Es gibt einen Betrieb, der gesagt hat: Wir stellen auf Profinet um. Dieser hat angefragt, ob wir auf Profinet könnten, oder ob ein anderer Weg nötig wird. Ich weiss aus Erfahrung, dass umfangreiche Installationen nicht mal so nebenbei dort gehen, insbesondere weil es bisher ja auch ohne ging. Du stellst dir das ein wenig einfach vor glaube ich.

Alles was ich will, ist wissen: Ich werde eine Profinet-Verbindung an einem PC haben. Kann ich via nacktem Socket oder libnodave mit einer SPS am Bus reden oder nicht? Dabei ist es egal ob tatsächlich über den Profinet-Bus, oder nur über die selbe physikalische Verbindung aber mit anderem Protokoll.

-

Ich habe gerade nochmals mit dem Kunden gesprochen, und es soll dort wohl ohnehin das "SIMATIC Profinet Development Kit DK-16xx PN IO" installiert werden. Die Beschreibungen die ich dazu gefunden habe sind erbärmlich allgemein gehalten, und ich kann nicht ansatzweise abschätzen, ob ich mit dieser API aus meiner Delphi-Applikation heraus kommunizieren kann. Stehen dann entsprechende ActiveX-Elemente zur Verfügung o.ä.? Gibt es eine einzubindende DLL? Schon fertige Header-Konvertierungen für Delphi dazu? Können prinzipiell mehrere Applikationen auf einem PC über die selbe Schnittstelle gehen? Sind das dann eigene "virtuelle" Devices, oder teilt man sich den Anschluss einfach? Ohne das Produkt zu haben kann man fast nichts über seinen Nutzen sagen. Gibt es da ggf. Erfahrungen mit hier?

JesperMP · 22 Mai 2015

Genau das DCOM Problem gehört mit OPC UA zu den Vergangenheit.

Wir können schlecht unserem Kunden sagen: Hey, deine bisher aufgewendeten Monate an Planung und Vorbereitung kannst du bitte streichen, weil unsere Hand voll kleiner Tools will das nicht können. Bitte mache doch einfach alles nochmal neu mit OPC UA. Die paar 100k€ an jetzt falscher Hardware schreibt ihr ja locker ab.
Die werden uns hinterherlachen nachdem sie uns vom Dach getreten haben. Und dann anstoßen.

Also man hat 100k€ verschwendet, und auf etwas entschieden, aber es ist noch unklar wie man es lösen soll ?

Ich werde eine Profinet-Verbindung an einem PC haben. Kann ich via nacktem Socket oder libnodave mit einer SPS am Bus reden oder nicht? Dabei ist es egal ob tatsächlich über den Profinet-Bus, oder nur über die selbe physikalische Verbindung aber mit anderem Protokoll.

Also, realen Profinet Device geht nicht nur mit sockets oder Libnodave. Oder es geht, aber dann braucht man eine Programmier-Guru.
Den letzten Satz (mit Rot markiert) in den obigen Zitat lautet für mich als ob es noch unklar ist was gefordert wird.

Wenn ich es richtig verstanden habe:
Sie haben eine PC Anwenderprogramm für diese Industrie entwickelt.
Es muss auf einen PC installiert werden, der nicht von euch ist.
Es darf keine weitere Treiber oder Zusatzsoftware installiert werden.
OPC DA oder UA will man nicht.
Der PC und der Anwendersoftware muss als Profinet Device für der Kundenseitige SPS als Profinet Controller sein.
Wenn alle diese Forderungen gelöst werden muss, sehe ich keine Lösung.

JesperMP · 22 Mai 2015

Medium schrieb:
Ich habe gerade nochmals mit dem Kunden gesprochen, und es soll dort wohl ohnehin das "SIMATIC Profinet Development Kit DK-16xx PN IO" installiert werden. Die Beschreibungen die ich dazu gefunden habe sind erbärmlich allgemein gehalten, und ich kann nicht ansatzweise abschätzen, ob ich mit dieser API aus meiner Delphi-Applikation heraus kommunizieren kann. Stehen dann entsprechende ActiveX-Elemente zur Verfügung o.ä.? Gibt es eine einzubindende DLL? Schon fertige Header-Konvertierungen für Delphi dazu? Können prinzipiell mehrere Applikationen auf einem PC über die selbe Schnittstelle gehen? Sind das dann eigene "virtuelle" Devices, oder teilt man sich den Anschluss einfach? Ohne das Produkt zu haben kann man fast nichts über seinen Nutzen sagen. Gibt es da ggf. Erfahrungen mit hier?

Aha. Dies ist also der Lösung den man gewählt hat.
Starte eine neuen Thema mit der Titel "Erfahrungen mit "SIMATIC Profinet Development Kit DK-16xx PN IO" oder so.

Thomas_v2.1 · 22 Mai 2015

Das hört sich nach "wir müssen was mit Profinet machen, haben aber keine Ahnung was das ist" an.

Profinet basiert auf Ethernet.
OPC ist eine komplett andere Baustelle wie Profinet. Das wäre das gleiche wie wenn ich sage "wir wollen kein Windows mehr, wir wollen USB". Das hat technisch nichts miteinander zu tun.
So wäre es möglich eine Software via OPC über Profinet mit einer Steuerung kommunizieren zu lassen.

Ich würde den Kunden nochmal genau fragen, was er sich darunter vorstellt.

LowLevelMahn · 22 Mai 2015

Profinet != OPC

http://us.profinet.com/profinet-versus-opc/

JesperMP · 22 Mai 2015

Und wenn man wieder darüber denkt ....

Dies ist noch dummer als hatte man sich einfach für "Profinet" oder "OPC UA" entschieden, oder beide.
Diese software kit funktioniert NUR mit eine Siemens CP1616 Karte, und ist eine proprietäre Software Schnittstelle, wie du es schon gefunden hast.
Denk daran das Siemens hat in den Vergangenheit unterschiedliche Software Schnittstellen, wobei einige lebt, einige stolpert weiter, und andere sind gestorben.
Diese Software kit glaube ich nich ist eine dauerhafte Lösung.

Ich schlage vor als einfache Lösung:
Siemens CP1616 konfiguriert als Profinet IO Device, mit Simatic Net software als OPC UA Server.
Und alle können froh sein.

Medium · 26 Mai 2015

Thomas_v2.1 schrieb:
Das hört sich nach "wir müssen was mit Profinet machen, haben aber keine Ahnung was das ist" an.

Ich hatte gehofft, dass dies in meinem Eingangsposting deutlich genug war. Wenn ich genau wüsste was abgeht, würde ich hier nicht nachfragen müssen

Wenn ich die Beschreibung auf LowLevelMahns Link richtig erfasse, ist mein grundlegender Denkfehler: PROFINET ist nur ein Protokoll, welches im Rahmen des IP-Protokolls via ganz normalem Ethernet übertragen wird. Ich nahm bisher an, dass es für PROFINET ggf. eines speziellen Anschlusses bedarf, oder zumindest eines gesonderten Treibers, der den normalen Netzwerkbetrieb ggf. auf dem Anschluss/Kabel verhindert. Dem ist jedoch nicht so, und ich könnte einen PC mit ein und demselben Ethernet-Anschluss sowohl in eine PROFINET-Infrastruktur, als auch ins ganz normale LAN verbinden. (Vorausgesetzt natürlich die beiden Netze überschneiden sich.) Dies war mir bisher nicht ganz klar, danke für den Link!

Also kann ich annehmen, dass ich - obwohl auch PROFINET über mein Kabel geht - im Grunde auch eine ISO-over-TCP Verbindung zur SPS herstellen könnte.

Alternativ könnte ich lokal einen OPC UA Server auf dem PC haben, der dann die Daten der SPS via PROFINET zur Verfügung stellen kann. (Leider habe ich keine Zugriffskomponenten für OPC UA für Delphi. Gibt es da Empfehlungen? Ich will das sicherlich nicht "zu Fuß" machen müssen.)

Jetzt ist nur noch die Frage, wie der CP1616 darauf reagiert, wenn ich versuche darüber eine ISO-over-TCP Verbindung herzustellen wie über eine normale Netzwerkkarte. Wie ich Siemens kenne, hält man da bestimmt ein paar Überraschungen für mich parat.

JesperMP · 26 Mai 2015

Medium schrieb:
Ich hatte gehofft, dass dies in meinem Eingangsposting deutlich genug war. Wenn ich genau wüsste was abgeht, würde ich hier nicht nachfragen müssen

Ich glaube das Thomas' Bemerkung war nicht an dir gemeint, sondern an die der diese Forderung gemacht hat. (Muss CP1616 sein. Muss mit speziellen Software kit gemacht sein).

Medium schrieb:
Also kann ich annehmen, dass ich - obwohl auch PROFINET über mein Kabel geht - im Grunde auch eine ISO-over-TCP Verbindung zur SPS herstellen könnte.

ISO-over-TCP nur wenn es um ein Siemens SPS handelt.
Und wenn ich der speziellen Forderung versteht will man irgendwie echten Profinet.

Medium schrieb:
(Leider habe ich keine Zugriffskomponenten für OPC UA für Delphi. Gibt es da Empfehlungen? Ich will das sicherlich nicht "zu Fuß" machen müssen.)

Das sieht leider schlecht aus.
Für Delphi macht Kassl (www.kassl.de) eine Bibliotek mit guten Ruf. Aber leider nur für OPC DA. Vielleicht Kassl fragen ob ein OPC UA Bibliotek unterwegs ist.

Medium · 26 Mai 2015

JesperMP schrieb:
Ich glaube das Thomas' Bemerkung war nicht an dir gemeint, sondern an die der diese Forderung gemacht hat. (Muss CP1616 sein. Muss mit speziellen Software kit gemacht sein).

Ja, das kann sein. Da ist der Kunde in der Tat noch etwas unentschlossen. Ich weiss noch nicht genau, ob ich nun auf einen normalen Panel-PC ohne CP lande, einem mit, oder es gibt sogar noch die Option, dass alles auf dem Panel in einer Terminal-Service Sitzung laufen soll, wobei ich nicht weiss, wie der Terminal-Server ausgestattet sein würde. Das ist in der Tat noch sehr unausgegoren.
Man hat uns dennoch jetzt schon gefragt ob wir prinzipiell mit diesen Veränderungen arbeiten können, weil wenn nicht wäre JETZT noch Zeit Dinge ggf. im kleinen Rahmen zu ändern.

ISO-over-TCP nur wenn es um ein Siemens SPS handelt.

Das ist gegeben, im gesamten Werk befinden sich ausschließlich Siemens SPSen.

Und wenn ich der speziellen Forderung versteht will man irgendwie echten Profinet.

Da wird vermutlich mit reinspielen, dass ich beim Stellen meiner Frage selbst noch etwas unklar darüber war, was PROFINET im Detail ist. Ob der Kunde uns auch via ISO dran lässt müsste ich dann in Erfahrung bringen.

Das sieht leider schlecht aus.
Für Delphi macht Kassl (www.kassl.de) eine Bibliotek mit guten Ruf. Aber leider nur für OPC DA. Vielleicht Kassl fragen ob ein OPC UA Bibliotek unterwegs ist.

Genau die Kassl-Komponenten haben wir im Einsatz. Dann muss ich da mal fragen. Weil wenn es da nichts gibt, dann fällt OPC (auch UA) definitiv flach. Unser Programm ist zwar nicht übermäßig komplex, aber vollständig in einer anderen Sprache reimplementieren - nein danke. (Wird auch keiner bezahlen wollen denke ich

)

Danke euch zwischendurch mal!

LowLevelMahn · 28 Mai 2015

OPC UA Komponenten fuer Delphi: http://www.opclabs.com/products/quickopc/languages-and-tools/delphi

Medium · 28 Mai 2015

Wow, danke! Das wäre dann definitiv ein Link der gespeichert wird!

Profinet via libnodave

Level-1

Level-3

Level-1

Level-3

Level-3

Level-1

Level-3

Level-1

Level-3

Level-1

Level-3

Level-3

Level-1

Level-1

Level-3

Level-1

Level-3

Level-1

Level-1

Level-1

Similar threads

Wir schützen deine Privatsphäre