# Profinet-Kommunikation zu Teilnehmer



## SUZI (21 Juli 2017)

Hallo, 
ich steh grad irgendwie auf dem Schlauch. 
Will mit S7-CPU mit integrierter Profinet-Schnittstelle zu Teilnehmer Kommunikation aufnehmen -> sehe ich an sich noch nicht als Problem an HW-Konfig und Eingänge bzw. Ausgänge  festlegen. Dto. GSXML-Datei.  Es sollen Datensätze übertragen und Rückmeldungen gelesen werden. Per SFC20 alternativ SFC 14/SFC15 so sicherlich auch kein Problem. 
Da ich diese bisher diese kommunikation seriell gemacht habe  waren in den betreffenden FB send/Receive aber auch Rückmeldungen wie "DONE" - "Übertragung Erfolgreich durchgeführt", "NDR"-"Neuer Datensatz vorhanden", "Error"- "Fehler steht an, "Status"- "Übertragung aktiv". Diese Fehlen mir nun. 
Die Rückmeldungen über RET_VAL geben meines Wissens nur Fehler aus. Damit könnte anhand der Auswertung "8XXX" vorhanden zumindest das Vorhandensein eines Fehlers "Error" erzeugt werden. 
-"DONE"-"Übertragung erfolgt" wären vermutlich nur über die anliegende Freigabe zur Übertragung und das abschließende das "BIE"-Bit bzw. ENO und "kein Fehler" zu kreieren.
- "NDR"-"Neuer Datensatz vorhanden" müsste über den Vergleich "altDaten"- "NeuDaten" erfolgen (Vergleich von 132 Byte ->? ).  

Da auf ein Kommando von der SPS eine Rückmeldung vom Teilnehmer kommen soll scheint das ganze doch ein wenig aufwendig zu sein. 

Oder hat jemand eine bessere Idee?
Gerne freue ich mich über einen TIP dazu.

Gruß SUZI


----------



## PN/DP (21 Juli 2017)

Irgendwie wird mir nicht klar, was nun Deine Frage ist...
Doch Du könntest mal in diese FAQ: Linkliste SIMATIC-Kommunikation über Ethernet schauen, da findest Du jede Menge Anleitungen und Beispielprogramme.

Harald


----------



## Larry Laffer (21 Juli 2017)

Das geht mir genauso ... mit was für einem Teilnehmer möchtest du über PN kommunizieren ? Eine andere CPU ? Eines deiner dezentralen Perepheriegeräte ? ...?

Gruß
Larry


----------



## SUZI (21 Juli 2017)

S7-300 CPU soll mit mehreren Lasereinheiten (Profinet-IO-Device) kommunikzieren. 

Die Frage war, ob ich hier mit den SFC14/15 den richtigen Weg einschlage oder ob es da ein besseres,mir unbekanntes Kommunikationshandling gibt. Die "alte Dame" Serielle Schnittstelle bot da schon recht gute fertige Bausteine an.


----------



## ChristophD (21 Juli 2017)

Hi,

die entscheidende Frage ist was genau du schreiben/lesen willst.
Du sprichst von Datensätzen, diese werden in der Regel mittels WRREC uind RDREC bedient.
SFC14/15 sind zu Kommunikation auf I/O Ebene gedacht.

Gruß
Christoph


----------



## Larry Laffer (21 Juli 2017)

SUZI schrieb:


> S7-300 CPU kommuniziert mit mehreren Lasereinheiten.



OK ... das heißt du hast in der HW-Konfig einen Kommunikationsbereich mit dem jeweiligen Laser festgelegt ?
... oder kennt deine CPU die Laser als Geräte gar nicht ?  (lass dir bitte nicht alles einzeln aus der Nase ziehen).

Gruß
Larry


----------



## SUZI (21 Juli 2017)

@ Larry: Ich gehe davon aus, dass die CPU die Laser kennt, da ich die "GSDML-Dateien" dazu eingefügt und den Adressbereich der CPU erweitert und EIn-Ausgangsbereiche (lt. Herstellerbeschreibung jew. 4 Byte Eing. und Ausg. für ansprechen digitaler Fkt. und  jew. 64Byte Eing. und Ausg. für Komandos + Dateinamen u. ä.) eingefügt habe.

@ChristophD: Die Bausteine WRREC uind RDREC werde ich mir mal ansehen, danke


----------



## ChristophD (21 Juli 2017)

was für nen Laser ist das?
Da gibt es bestimmt auch eine Doku dazu wo beschrieben steht wie er anzusteuern ist.


----------



## Larry Laffer (21 Juli 2017)

SUZI schrieb:


> @ Larry: Ich gehe davon aus, dass die CPU die Laser kennt, da ich die "GSDML-Dateien" dazu eingefügt und den Adressbereich der CPU erweitert und EIn-Ausgangsbereiche eingefügt habe.



... dann sollte es über die SFC14 / 15 gehen ... weil du die Laser ja so im Perepheriebereich deiner Steuerung hast ...

Gruß
Larry


----------



## SUZI (21 Juli 2017)

Danke Larry, ist tatsächlich die zunächst überlegte Variante. Doch hoffte ich auf eine komfortablere Variante mit den Rückmeldungen siehe erster Text.


----------



## ChristophD (21 Juli 2017)

Das wird aber nicht funktiionieren.
Wenn man den Text den Du eingangs verfasst hast erstmal ohne Sonderzeichen ließt dann erwartest du das der Aufruf der SFC14/15 dir z.B. den Fehler zustand deines Lasers liefert und das erwartest du im Error Parameter des SFC.
Das ist aber falsch, dort werden Error der SFC Ausführung eingetragen, wenn dort als 8xxx steht dann stimmt was nicht mit dem SFC , dein laser ist davon nicht betroffen, der kann fehlerfrei sein.
Du must also die gelesenen Daten die du ja in einem DB speicherst auswerten!
Und genau deswegen solltest du die Doku des Lasers nehmen und schauen wie die Daten aufgebaut sind und wie Du sie auszuwerten hast.
Der SFC nimmt dir das nicht ab, der schiebt nur Daten hin und her !


----------



## SUZI (21 Juli 2017)

Ja, Integrationsbeispiel für Profibus, 
Es werden grundsätzlich eine Kommandos ausgegeben die aus einer Kommando-Nr. , Kommandolänge, und eventuell weiteren Texten/Befehlen besteht. Ausgabe über 64 Byte Ausgangswort und ähnliches als Rückmeldung zurück vom Laser


----------



## ChristophD (21 Juli 2017)

??????
geht das auch verständlich?


----------



## PN/DP (21 Juli 2017)

Larry Laffer schrieb:


> ... dann sollte es über die SFC14 / 15 gehen ...


... wenn die E/A-Adressen der 64 Byte Ein-/Ausgänge außerhalb des Prozessabbildes PAE/PAA liegen. Wenn die innerhalb des Prozessabbildes liegen, dann soll man nicht noch zusätzlich SFC14/15 aufrufen, sondern einfach mit Lade/Transferiere-Anweisungen (L, T) oder SFC20 (BLKMOV) aufs Prozessabbild zugreifen.
Auf die 4 Byte Ein-/Ausgänge kann man nicht mit SFC14/15 zugreifen sondern muß mit L/T oder SFC20 zugreifen.

Harald


----------



## SUZI (21 Juli 2017)

Den Fehlerzustand des Lasers erhalte ich sicherlich über die Kommunikation, nicht über den Error-Parameter RET-VAL. 
Das Hin und Herschieben der Daten wollte ich kontrollieren wie siehe erste Text "NDR" bzw "DONE" ähnlich den seriellen Bausteinen FB Send und FB Receive.  Und das ist hier die Frage. Die erhaltene Info des Herstellers bezieht sich auf Profibus oder ich habe diese noch nicht gefunden. Aber auf konkrete Frage, bezüglich der aus seiner Sicht zu verwendenden Bausteine oder Beispiel für die S7 mit Profinet, habe ich vom Service des Herstellers leider nur die Antwort dass er es nicht weiss erhalten. Doch, die Konfiguration seiner Hardware habe ich erhalten und dementsprechend auch meine HW-Konfig ausgeführt.


----------



## ChristophD (21 Juli 2017)

Da frage ich jetzt nochmal konkret: Was für eine Lasereinheit ist das?


----------



## SUZI (21 Juli 2017)

Hallo Harald, 
Ist es nicht so, dass der SFC 20 sich unter umständen mehrere Zyklen Zeit läßt?   Daher habe ich die SFC 14/15 für die 64 Byte E/A gedacht wegen der Datenkonsistenz.
Die Datenkonsistenz wäre m. E. bei einem Handling mit L- u T-Befehlen nicht gegeben. 
Für die 4 Byte sicherlich kein Problem. 
SUZI


----------



## SUZI (21 Juli 2017)

> Da frage ich jetzt nochmal konkret: Was für eine Lasereinheit ist das?


Hallo Christoph, Trumpf


----------



## Larry Laffer (21 Juli 2017)

Hat sie geschrieben :  ein Trumpf-Laser ... (den kenne ich aber nicht).

@Suzi: Kann das Ding denn wirklich PN ... oder geschieht die Kommunikation eigentlich mit einem ANYBus-Modul, dass dann wieder seriell mit dem Laser "spricht" ?
Vielleicht solltest du mal einen Screenshot von der HW-Konfig eines deiner Laser hier einfügen ...

Gruß
Larry


----------



## Larry Laffer (21 Juli 2017)

Nachsatz:
Wenn der Hersteller (also Trumpf) dir aber schreibt, dass er das mit der Kommunikation selber nicht so recht weiß dann ist das schon ein Armuts-Zeugnis ...


----------



## SUZI (21 Juli 2017)

> Hat sie geschrieben :  ein Trumpf-Laser ... (den kenne ich aber nicht).
> 
> @Suzi: Kann das Ding denn wirklich PN ... oder geschieht die Kommunikation eigentlich mit einem ANYBus-Modul, dass dann wieder seriell mit dem Laser "spricht" ?
> Vielleicht solltest du mal einen Screenshot von der HW-Konfig eines deiner Laser hier einfügen ...


 Lt GSDML: Hilscher CIFX 2.2


----------



## SUZI (21 Juli 2017)

> Nachsatz:
> Wenn der Hersteller (also Trumpf) dir aber schreibt, dass er das mit der Kommunikation selber nicht so recht weiß dann ist das schon ein Armuts-Zeugnis ...


Ich denke da ist die serielle Kommunikation und Profibus-Kommunikation noch zu sehr verbreitet. Und sicherlich hängt es mit dem Mitarbeiter zusammen.


----------



## ChristophD (21 Juli 2017)

Hi,

ok dann ist schonmal klar das dieses PN Interface nicht von Trumpf ist sondern ne Hilscherkarte die im Laser verbaut ist.
Wenn es ein Integrationsbeispiel für Profibus gibt dann kann dieses ja für PROFINET verwendet werden, die Bausteine sind da ja gleich.

Leider hat Trumpf nicht wirklich einen Service Bereich im internet


----------



## santacrews (21 Juli 2017)

Hilscher ist nur ein "Übersetzer".
Die dinger benutzen wir immer in unseren PCs zur Kommunikation mit der SPS.
Wenn Du mich fragst, dann musst Du die GSD Datei der Hilscher Karte in die HW-Konfig eintragen und beim Hersteller gucken, welche Parameter er auf welchen Adressen er erwartet.
Eine Kontrollierte Kommunikation ist bei Profinet meiner Meinung nach absolut nicht notwendig.


----------



## santacrews (21 Juli 2017)

Durch die Ansprechüberwachungszeit hast Du doch quasi eine Überwachung der Datenübertragung


----------



## Larry Laffer (21 Juli 2017)

santacrews schrieb:


> Eine Kontrollierte Kommunikation ist bei Profinet meiner Meinung nach absolut nicht notwendig.


Dem würde ich so zustimmen ... 


santacrews schrieb:


> Wenn Du mich fragst, dann musst Du die GSD Datei der Hilscher Karte in die HW-Konfig eintragen und beim Hersteller gucken, welche Parameter er auf welchen Adressen er erwartet.


Das müßte aber auf alle Fälle aus der GSD-Datei (HW-Konfig) hervorgehen.
Man MUSS sich hier aber sehr wahrscheinlich an eine Reihenfolge in der Zuweisung von bestimmten Daten/Werten auf bestimmte Koppelbereiche halte - so gesehen dann doch wieder eine Art Kommunikation. Als Basis sollte hier aber dann auch wieder die schon bekannte serielle Kommunikation helfen können. Über die Hilscher-Karte wird es nicht soviel anders laufen. Also auf alle Fälle mal ein bißchen Richtung "Schrittkette" beim Datenaustausch denken.

Gruß
Larry


----------



## SUZI (21 Juli 2017)

> Man MUSS sich hier aber sehr wahrscheinlich an eine Reihenfolge in der Zuweisung von bestimmten Daten/Werten auf bestimmte Koppelbereiche halte - so gesehen dann doch wieder eine Art Kommunikation. Als Basis sollte hier aber dann auch wieder die schon bekannte serielle Kommunikation helfen können. Über die Hilscher-Karte wird es nicht soviel anders laufen. Also auf alle Fälle mal ein bißchen Richtung "Schrittkette" beim Datenaustausch denken.




Hallo Larry, hallo Christoph,

ich denke dass ist einfach der Weg.... 
Danke Suzi


----------



## santacrews (21 Juli 2017)

Larry Laffer schrieb:


> Das müßte aber auf alle Fälle aus der GSD-Datei (HW-Konfig) hervorgehen.



Jein. Die Hilscher Karten sind da ein bisschen wie ne ET200 Kopfbaugruppe. Oder ein DP/DP Koppler. 
Da kann man als Unterbaugruppe noch Eingangs und Ausgangsdaten hinzufügen.


Es muss auf jeden Fall irgendjemanden geben, der im Inneren des Lasers die Kommunikation zur Hilscher Karte kreiert hat. Und daran muss man sich auf der anderen Seite der Karte auch dran halten.
Lange rede kurzer Sinn: Ich würde keine SFC/SFB Veranstaltungen machen sondern einfach die Daten, die Du hast auf entsprechende AW / PAW schreiben und fertig. Musst halt nur wissen welche Daten an welche Adressen kommen.


----------



## Larry Laffer (21 Juli 2017)

santacrews schrieb:


> Hilscher ist nur ein "Übersetzer".



Ich habe noch nicht damit gearbeitet - also doch in etwa so, wie ein ANYBus-Modul ?


----------



## ChristophD (21 Juli 2017)

Larry Laffer schrieb:


> Ich habe noch nicht damit gearbeitet - also doch in etwa so, wie ein ANYBus-Modul ?



Nicht ganz.
Ist im Prinzip ne PC Einschubkarte die für das  Feldbus System verwendet wird.
Über eine API kannst du dann ein eigenes Programm schreiben welches eben die Daten von der Karte weiterverarbeitet.

Ähnlich wie bei KUKA Robotern, dort wurden Siemens CP's dafür eingesetzt (CP5614 / CP1616).

Gruß
Christoph


----------



## Larry Laffer (21 Juli 2017)

@Suzi:
Ich habe jetzt gerade den von dir nachgeschobenen Screenshot gesehen. Das ist natürlich auch wieder dürftig. Ich hatte jetzt schon erwartet, dass den "4 Byte Ausgang" eine brauchbare namentliche Zuordnung gemacht wurde. Im Grunde sind das ja die Koppelbereiche, die ggf. festgelegte Funktionen haben (z.B. Kommando's , Beschriftungstext etc.)

Gruß
Larry


----------



## PN/DP (21 Juli 2017)

SUZI schrieb:


> Ist es nicht so, dass der SFC 20 sich unter umständen mehrere Zyklen Zeit läßt?


Nein, der SFC20 wird immer sofort fertig (es sei denn, er verursacht eine Zykluszeitüberschreitung).
(Allerdings kann der SFC20 durch höherpriore OB unterbrochen werden, was aber nur eine Relevanz hat, wenn man in verschiedenen OB-Ebenen auf die SFC20-Quell/Zielbereiche zugreift.)



SUZI schrieb:


> Daher habe ich die SFC 14/15 für die 64 Byte E/A gedacht wegen der Datenkonsistenz.


Die SFC14/15 kann man nur einsetzen, wenn für das Zugreifen auf die E/A-Adressen eine Konsistenz ungleich 1, 2 oder 4 Byte projektiert ist und wenn die E/A-Adressen außerhalb des E/A-Prozessabbildes liegen. Wenn die E/A-Adressen innerhalb des Prozessabbildes liegen, dann kümmert sich das Betriebssystem der CPU um das konsistente Kopieren zwischen Prozessabbild und Peripherie und die Daten liegen konsistent im Prozessabbild, so daß man einfach mit L/T auf's Prozessabbild zugreifen kann.

Harald


----------



## SUZI (21 Juli 2017)

> Ich hatte jetzt schon erwartet, dass den "4 Byte Ausgang" eine brauchbare namentliche Zuordnung gemacht wurde. Im Grunde sind das ja die Koppelbereiche, die ggf. festgelegte Funktionen haben (z.B. Kommando's , Beschriftungstext etc.)



Die Definition der einzelnen Bits der Ausgangsbytes gibt es im Handbuch zur Installation der Schnittstellenkarte und auch in der Zuordnungsliste. Im Groben: LASER-AblaufSteuerung/Digitale Schnittstelle
für die 64 Bytes Empfangs- / Sendepuffer Kommandos
Für die Kommandos zur Steuerung des Lasers, sowie der Rückmeldungen gibt es ein eigenes Handbuch.
Im Prinzip ist ja auch fast alles vorhanden.


----------

