# Profinet IRT Daten am IPC empfangen (mit S7NetPlus)



## Bergungsdackel (29 Juli 2020)

Guten Tag.

Ist es an einem IPC (Microbox PC von Siemens) möglich mit S7NetPlus auch IRT Daten empfangen? Es werden also über Profinet Daten an den Slave (IPC) geschickt und an diesem IPC soll eine Software diese Daten empfangen. Dass S7NetPlus prinzipiell Daten der PLC empfangen kann, weiss ich. Kann S7NetPlus aber auch Profinet IRT Daten empfangen? Wird das anders programmiert oder ist das bloss eine Hardwarekonfiguration die gesetzt werden muss?

Vielen Dank im Voraus.

Gruß,
bergungsdackel


----------



## ChristophD (29 Juli 2020)

Hi,

also zuerst brauchst du einen Profinet IRT fähigen IPC (dazu benötigt es spezielle HW) und natürlich ein entsprechenden SoftController oder profinet Applikation auf dem IPC damit die Daten überhaupt abgenommen werden.

Gruß
Christoph


----------



## Bergungsdackel (29 Juli 2020)

Hallo.
Danke für deine Antwort. Das mit dem IRT-fähigen IPC dachte ich mir schon. Weisst du zufällig ob der "SIMATIC IPC427E" IRT-fähig ist? Ich finde dazu nichts und im Datenblatt steht nur "Onboard PROFINET-Schnittstelle".

Was meinst du mit "profinet Applikation auf dem IPC damit die Daten überhaupt abgenommen werden"? Wenn der IPC IRT-fähig ist, "reicht" theoretisch eine .NET-Bibliothek so wie S7NetPlus oder habe ich einen Denkfehler?

Gruß,
bergungsdackel


----------



## DeltaMikeAir (29 Juli 2020)

> Weisst du zufällig ob der "SIMATIC IPC427E" IRT-fähig ist?


Die Info findet man doch in den technischen Daten:
https://support.industry.siemens.co...rie-simatic-ipc427e-(microbox)?dti=0&lc=de-AT


----------



## ChristophD (29 Juli 2020)

Hi,

alleine schond das es Gbit Schnittstellen sind sagt das es kein IRT kann.
Und .net Bibliothek spricht mit eine PLC! der IPC ist keine PLC, das ist ein Windows PC und weiter nix.
Da muss dann eine iftware PLC drauf die eben die Daten vom netz abholt und in ihre Datenbereiche schiebt auf die dann die .Net zugreift.


----------



## Bergungsdackel (29 Juli 2020)

DeltaMikeAir schrieb:


> Die Info findet man doch in den technischen Daten:
> https://support.industry.siemens.co...rie-simatic-ipc427e-(microbox)?dti=0&lc=de-AT



Vielen Dank. Funktioniert bei mir also nur über eine PCIe-Karte.


----------



## Bergungsdackel (29 Juli 2020)

ChristophD schrieb:


> Hi,
> 
> alleine schond das es Gbit Schnittstellen sind sagt das es kein IRT kann.
> Und .net Bibliothek spricht mit eine PLC! der IPC ist keine PLC, das ist ein Windows PC und weiter nix.
> Da muss dann eine iftware PLC drauf die eben die Daten vom netz abholt und in ihre Datenbereiche schiebt auf die dann die .Net zugreift.



Danke für die Antwort, ich stehe aber glaube ich aufm Schlauch. Die Bibliothek S7NetPlus kann doch auch auf Daten zugreifen die von der PLC ausgehen? Und die entsprechende Software (programmiert mit S7NetPlus beispielsweise) würde ja auf dem IPC laufen, was doch theoretisch über Profinet/Ethernet verbunden ist. Also es gibt ja in S7NetPlus Befehle wie "ReadBytes" - die sind doch dafür da oder?
Also mir gehts eben darum, was möglich ist. Ich besorge eine PCIe-Karte, womit mein IPC IRT-fähig wird (laut Siemens Seite) und dann bräuchte ich nur noch eine Bibliothek, die diese IRT-Telegramme "verstehen" kann und auslesen kann.


----------



## ChristophD (29 Juli 2020)

die PCIe Karte alleine nützt dir aber nix weil die kann von sich aus ja gar nix.
Du brauchst eine SW die die PROFINET Daten empfängt.
Das ist enweder eine selber geschriebene C# auf Basis des Dev Kits oder eben eine Software Controller auf Basis S7-300 oder S7-1500 , und mit dem redet dann die .net Anwendung , und nicht direkt mit dem PROFINET, schau einfach nochmal in die S7NetPlus Wiki rein dort steht es gut erklärt.
S7net kann nur Daten aus einer PLC lesen und sonst nix.


----------



## Bergungsdackel (30 Juli 2020)

Ich weiss was du meinst. Mir ist klar, dass es "nur" mit der PCIe-Karte nicht getan ist, aber das ist hier die Frage. S7NetPlus kommuniziert mit der PLC. Jetzt ist halt die Frage, welche Bibliothek ich gebrauchen könnte, um Profinet Daten zu empfangen (jetzt erstmal unabhängig ob IRT oder RT). Du hast hierzu das Dev-Kit erwähnt, wo gibt es dieses bzw. wo finde ich Informationen dazu?
Also wir verstehen uns in dem Fall schon, nur hab ich teils ganz kleine Wissenslücken, da ich zum ersten Mal mit so etwas zu tun habe.
Danke für deine Antworten.


----------



## ChristophD (30 Juli 2020)

Hi,

informationen zum Dev Kit findest du hier: https://support.industry.siemens.com/cs/ww/de/ps
Aber ich glaube das wird auch nicht der richtige Weg sein. Du wirst einfach nicht um eine PLC Herumkommen.


----------



## Bergungsdackel (30 Juli 2020)

Ist damit die PNConfigLib gemeint? Finde auf der Siemens-Support-Seite sehr viele unterschiedliche Treiber oder IO-Lösungen. 
Ich werde die Idee mit der PLC dazwischen ins Gespräch bringen, jedoch muss ich mich auch nur an die Vorgaben halten und zurzeit hats zu mir geheißen die Daten direkt vom Profinet "abzufangen" über eine Bibliothek.


----------



## DeltaMikeAir (30 Juli 2020)

> jedoch muss ich mich auch nur an die Vorgaben halten


Dann soll der, der die Vorgaben gemacht hat mal einen Vorschlag machen


----------



## ChristophD (30 Juli 2020)

Hi,

Alleine schon "Daten direkt von Profinet abzufangen" lässt mich zweifeln da auch nur einer der Beteiligten ein auch nur rudimentäres Verständnis von Ethernet Kommunikation und im Speziellen PROFINET hat.
Was nützt es den wenn man die PN Daten direkt an der Netzwerkkarte abfängt , die Daten sind da nicht gültig und werden nie vernünftig verwendet werden können.
Wenn dann können die Daten aus dem PROFINET Stack abgeholt werden den nur dieser kann sagen ob die Daten richtig und gültig sind (ich haue jetzt mal IOPS IOCS raus ).

Also brauchst du neben der HW PN Schnittstelle ein Stück Software welches die eingehenden Telegramme entgegen nimmt und auswerteed, das ist der PN Stack.
In einer PLC ist dieser PN Stack in der FW implementiert oder man schreibt ihn sich selber mit z.B. dem PN Dev Kit.

Jetzt kommt das S7NetPlus ins Spiel. Dieses Tool kommuniziert mit einer PLC und kann Daten von der PLC lesen.
Es kann aber nicht mit z.B. einem PNStack reden weil das ist keine PLC, da wird schon der Open Aufruf nicht funktionieren.

Für das hier geschilderte Szeanario sehe ich nur eine Möglichkeit:
IPC + CP für PN IO IRT
SoftwareController auf Basis der S7-1500 (1507s)

Damit kann dann dieses S7Net kommunizieren und die Daten abholen die benötigt werden.

Gruß
Christoph


----------



## Bergungsdackel (30 Juli 2020)

Hallo.
Erstmal danke für deine Informationen. Ich verstehe nun ein wenig mehr.

Ich möchte mich in diesem Fall auch nicht auf S7NetPlus festlegen, jede andere Bibliothek ist möglich. Wir haben einen Compile-Zyklus der Daten an einen Profinet-Device schickt (z.B. hier der IPC). Dieser sollte diese empfangen (je nachdem ob IRT oder nicht IRT müsste man erst schauen ob wir einen CP dazu kaufen). Wie du gesagt hast, sollte nun eine Software diese Telegramme verstehen und bestätigen - klar. Hast du eventuell mehr Informationen zum "PN Stack" da man bei Google nur herstellespezifische Dinge findet. Für mein Hintergrundwissen würde es mich natürlich interessieren, wie so ein PN Stack funktioniert und für mehr Infos über das PN Dev Kit wäre ich auch dankbar, da ich mich mit solchen Dingen beschäftige, um noch mehr zu lernen. Es ist schwierig direkt beim ersten Mal den Überblick zu behalten. 
Wenn wir jetzt davon ausgehen, dass ich "nur" Profinet RT benutze, bräuchte ich auch einen Software Controller am IPC? In den technischen Daten steht ja es ist RT-fähig auf Basis der Ethernet-Schnittstelle. Wenn ich das richtig verstanden habe, müsste ich mit diesem "PN Dev Kit" meinen eigenen Controller programmieren, der sozusagen die Telegramme versteht ODER ich habe bereits einen Software Controller (1507S),der das übernimmt oder?
Ansonsten würde ich versuchen die Idee mit IPC + CÜ + Software Controller durchzubringen - kriege ich dafür weitere Informationen bei Siemens oder gibt es bereits Handbücher online?

Gruß


----------



## ChristophD (30 Juli 2020)

Hi,

ein Einstieg wäre hier: https://support.industry.siemens.com/cs/ww/de/view/109760216

Alternativ könnte man auch ein IoT einsetzten, gibt es einen zwingenden Grund für den IPC?


----------



## JesperMP (30 Juli 2020)

Vielleicht liege ich da komplett falsch, aber wäre es nicht genügend mit Simatic Net PN IO (https://mall.industry.siemens.com/mall/en/WW/Catalog/Product/6GK1704-1HW14-0AA0), eventuell als OPC Server ? Und dann eine 'normalen' OPC Client um die Daten zu abfragen ?


----------



## JesperMP (30 Juli 2020)

Noch eine weitere Frage.
Woher kommt den Bedarf von IRT oder RT ? Ist 'RT' tatsächlich notwendig für die Anwendung ? 
D.h. Real-Time und deterministisch ?
In den Fall wäre es ein Problem da 'normale' Windows Programme keine RT Eigenschaften habe.
Eine Lösung wäre den vorgeschlagene Open Controller. Dies ist aber kein normalen Windows Programm.

Wenn kein RT gefordert ist, dann wäre mein Vorschlag mit z.B. Simatic NET PN IO ein Möglichkeit.


----------



## Bergungsdackel (30 Juli 2020)

ChristophD schrieb:


> Hi,
> 
> ein Einstieg wäre hier: https://support.industry.siemens.com/cs/ww/de/view/109760216
> 
> Alternativ könnte man auch ein IoT einsetzten, gibt es einen zwingenden Grund für den IPC?


IPC liegt halt nahe, da die Daten die über Profinet abgefangen wurden, verarbeitet werden sollen und gegebenfalls in eine SQL-Datenbank (oder ähnliches) geschrieben werden sollen. Außerdem soll es "zukunftssicher" sein, sodass man diese Möglichkeit für weitere Projekte nutzen könnte.


----------



## Bergungsdackel (30 Juli 2020)

JesperMP schrieb:


> Noch eine weitere Frage.
> Woher kommt den Bedarf von IRT oder RT ? Ist 'RT' tatsächlich notwendig für die Anwendung ?
> D.h. Real-Time und deterministisch ?
> In den Fall wäre es ein Problem da 'normale' Windows Programme keine RT Eigenschaften habe.
> ...


Die Idee mit IRT/RT kam tatsächlich nicht von mir, ich soll das bloß umsetzen und die Möglichkeiten prüfen. Was genau ist denn der Unterschied zwischen dem NET PN IO, das du geschickt hast und dem PN Driver, den ChristophD geschickt hat???


----------



## JesperMP (30 Juli 2020)

Bergungsdackel schrieb:


> Was genau ist denn der Unterschied zwischen dem NET PN IO, das du geschickt hast und dem PN Driver, den ChristophD geschickt hat???


Simatic Net ist ein 'general purpose' Software die man verwendet über standardisierte Verfahren daten senden und empfangen zwischen Geräte und Windows Anwendersoftware. Simatic Net gibt es dann in viele Varianten, z.B. für Ethernet (S7 Verbindungen), Profibus (S7 verbindungen). Profibus DP (Profibus master/slave), und Profinet IO (Profinet master/slave). Das Schnittstelle für die Windows Software ändert sich nicht. Das Schnittstelle für die Windows Software wäre entweder "S7-API" (ein Siemens Standard), OPC DA oder OPC UA (offene Standards).
Simatic Net kauft man 1 Lizenz pro Installation.

Wenn man Simatic Net oder S7Netplus einsetzt, wird es nicht Real-Time sein über den gesammte Verbindung von Quelle nach Ziel. Es kann sein dass die Daten über Profinet und RT gesendet wird, und bis den Empfangsfach in den Simatic Net Datenspeicher gelangt. Aber der Windowsanwendung kann die Daten nicht ein Realtime abfragen.

Profinet "RT" oder "IRT" ist vermutlich ein Missverständniss von den ursprüngliche Auftragsgeber. Wenn die Anwendung mit SQL zu tun hat kann es nicht Real-Time sein.

Über den von ChristophD vorgeschlagene Treiber kann ich nicht viel sagen. Ich _glaube_ dass es ist gemeint für Embedded-Anwender, und nicht für algemeine Windows-Anwendungen.
Und man kauft kein Einzel-Lizenz, sonder ein Entwicklerlizenz, der dann vermutlcih recht teuer ist.

Wenn du ein Zukunftsichere Software entwickeln will, dann wurde ich OPC UA überlegen.


----------



## Bergungsdackel (30 Juli 2020)

Danke dir.

Ich erkundige mich mal und melde mich dann wieder.


----------



## JesperMP (30 Juli 2020)

Noch ein paar Bemerkungen.

Ich gehe davon aus das mit S7NetPlus ist dieses gemeint: https://github.com/S7NetPlus/s7netplus

Es kann sein dass S7NetPlus die Lösung für dich ist, wenn....
.. da ist kein Bedarf von Datenübertragung in 'Real-Zeit'. 
.. der Partner immer ein S7 Steuerung ist.
.. die Daten in den Partner S7 Steuerung kein optimierter DBs verwendet.
.. der Endkunde akzeptiert dass in den S7 Steurung ist PUT/GET freigeschaltet (ist ein Sicherheitsrisiko).
.. der Endkunde akzeptiert dass der Software auf freiwillige basis entwickelt ist. D.h. da ist kein 24/7 Support zu beanfragen wenn die Produktion steht mitten in Nachtschicht.


----------



## Thomas_v2.1 (30 Juli 2020)

JesperMP schrieb:


> .. der Endkunde akzeptiert dass der Software auf freiwillige basis entwickelt ist. D.h. da ist kein 24/7 Support zu beanfragen wenn die Produktion steht mitten in Nachtschicht.



Die Bibliothek ist keine eigenständige Anwendung sondern Teil seiner Software. D.h. als erstes steht er dafür in der Gewährleistung. Wenn du deine Anwendung mit einer Siemens Bibliothek aufsetzt, dann steht dem Endkunden dafür auch nicht automatisch der Siemens-Support 24/7 zur Verfügung.
Zudem verwendet Siemens selber zu genüge unterlagerte Bibliotheken die auf "freiwilliger Basis" entwickelt wurden (richtige Bezeichnung ist hier Open-Source), das hieße ja nach deiner Logik, dass ich von Siemens dadurch auch keinen 24/7 Support mehr erhalte.


----------



## JesperMP (30 Juli 2020)

Thomas_v2.1 schrieb:


> Wenn du deine Anwendung mit einer Siemens Bibliothek aufsetzt, dann steht dem Endkunden dafür auch nicht automatisch der Siemens-Support 24/7 zur Verfügung.


Doch. Wenn Simatic Net in Verwendung ist, kann meine Kunde und ich beide an Siemens wenden und ein Support Anfrage stellen.
Und es gibt Tools, wie OPC Test Clients, wobei man feststellen kann ob das Problem liegt bei den OPC Server oder den OPC Client. Wenn das Problem liegt bei den OPC Server i.e. Simatic Net, dann muss Siemens eine Lösung finden.



Thomas_v2.1 schrieb:


> Zudem verwendet Siemens selber zu genüge unterlagerte Bibliotheken die auf "freiwilliger Basis" entwickelt wurden (richtige Bezeichnung ist hier Open-Source), das hieße ja nach deiner Logik, dass ich von Siemens dadurch auch keinen 24/7 Support mehr erhalte.


Was ich über die 'freiwillige' gemeint hat, ist das die Organisation dahinten Steckt ist äusserst dünn. Hast du die Github Seite angeschaut ? Die letzte Update war 13 Monate her.

Wenn ich Siemens ein Support Anfrage startet, dann habe ich in normalen Fall ein Support-Mitarbeiter im Rohr innerhalb von eine Stunde. Eine Lösung bekomme ich vielleicht nicht innerhalb von eine Stunde, aber am mindestens kann ich an meine Kunde sagen das wir ernsthaft auf das Problem arbeitet und eine Lösung finden will.
Was passiert wenn morgens Microsoft ein Windows Update sendet der die Software zerschiesst ? Es kann sein das beide Simatic Net und S7netplus scheitern, aber ich weis das Siemens sofort auf eine Lösung arbeitet.

DAS ist die Hauptgrund das wir die 'grossen' Lieferanten verwendet, und keine Bastellösungen. Es ist vielleicht akseptabel für andere, aber für mich nicht.


----------



## Thomas_v2.1 (30 Juli 2020)

JesperMP schrieb:


> Was ich über die 'freiwillige' gemeint hat, ist das die Organisation dahinten Steckt ist äusserst dünn. Hast du die Github Seite angeschaut ? Die letzte Update war 13 Monate her.


Das muss nicht unbedingt was heißen. Irgendwann ist ein Produkt auch mal fertig, die Komplexität ist auch durchaus überschaubar.



JesperMP schrieb:


> DAS ist die Hauptgrund das wir die 'grossen' Lieferanten verwendet, und keine Bastellösungen. Es ist vielleicht akseptabel für andere, aber für mich nicht.


Woran bewertest du denn eine "Bastellösung". Wenn jemand anderes 1000 Zeilen Code schreibt, und es vermutlich von mehreren hunderten anderen Leuten eingesetzt und getestet wurde ist es eine Bastellösung. Wenn du für einen Kunden das SPS-Programm mit mehreren tausend Zeilen Code schreibst, was vermutlich wenn überhaupt nur einmal getestet wurde. Ist das auch eine Bastellösung.

Schaust du dir zu den Produkten die du bei Siemens kaufst auch immer den Beipackzettel an, und prüfst die Open-Source Projektseiten ob die auch gepflegt werden? Bei OpenSSL hat sich bei Heartbleed ja auch herausgestellt, dass das eine Ein-Mann Show ist.


----------



## JesperMP (30 Juli 2020)

Meine Kommentare beziehen sicht nicht auf Open-Source generell, sondern auf S7netplus. Hast du die Github Seite angeschaut ?


----------



## Thomas_v2.1 (30 Juli 2020)

JesperMP schrieb:


> Meine Kommentare beziehen sicht nicht auf Open-Source generell, sondern auf S7netplus. Hast du die Github Seite angeschaut ?



Ja, ich würde es nicht einsetzen, weil es andere ebenfalls OpenSource Lösungen gibt die mir besser gefallen.
Bei libnodave gibt es auch seit 2014 keine Updates mehr, und der Code ist auch alles andere als schön. Aber es funktioniert.


----------



## kulmx (31 August 2022)

S7netplus
50 PLC S7-300 PN =was wird die Lesegeschwindigkeit sein?


----------



## Thomas_v2.1 (31 August 2022)

Welche Datenmenge?
Solange die Daten in eine PDU passen (222 Byte bei einem Bereich), dauert das Lesen bei einer CPU mit PN-Schnittstelle zwischen 5-10 ms, wenn die Verbindung offen gehalten wird. Wenn du entsprechend mehrere Threads startest, musst du ja nicht alle nacheinander abfragen und auf die Antworten warten.


----------



## kulmx (1 September 2022)

OK
222Byte max 1 CPU =10ms, 50 CPU =5000ms ?
ich habe keine körperliche Möglichkeit, dies zu protestieren.Bestätigen Sie meine Bedenken hinsichtlich der Geschwindigkeit
===
deltalogic.de
welche Datenübertragungsraten und -mengen hat dieses Entwicklungsteam?


----------



## Thomas_v2.1 (1 September 2022)

Da du das Programm selber schreibst, musst du die einzelnen SPSen doch nicht zwingend nacheinander abfragen, sondern kannst es doch so programmieren, dass das parallel geschieht. Also 50 Threads starten die jeweils eine Verbindung zu einer SPS aufbauen und halten, und dann die Daten abfragen.


----------



## kulmx (1 September 2022)

Thomas_v2.1 schrieb:


> Welche Datenmenge?
> Solange die Daten in eine PDU passen (222 Byte bei einem Bereich), dauert das Lesen bei einer CPU mit PN-Schnittstelle zwischen 5-10 ms, wenn die Verbindung offen gehalten wird. Wenn du entsprechend mehrere Threads startest, musst du ja nicht alle nacheinander abfragen und auf die Antworten warten.


(222 Byte bei einem Bereich)
wo finde ich diese Beschreibung in der Anleitung ? pdf


----------

