Profinet-Kommunikation zu Teilnehmer

SUZI

Level-1
Beiträge
98
Reaktionspunkte
6
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zuletzt bearbeitet:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
@ 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
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
@ 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
 
Danke Larry, ist tatsächlich die zunächst überlegte Variante. Doch hoffte ich auf eine komfortablere Variante mit den Rückmeldungen siehe erster Text.
 
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 !
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Zuletzt bearbeitet:
... 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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
 
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
 
Zurück
Oben