Step 7 Profibus DP Slave -> Read/Write mit SFC14/15 -> error

schneijo

Level-2
Beiträge
69
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

im Rahmen eines unserer Erweiterungsprojekte haben wir eine Problem mit der Anwendung der SFC14/15 DP-Kommunikationsbausteine.

CPU-Typ: S7-315 2-PN/DP
CAE-Tool: Step7-Classic (Simatic Manager 5.6)

Dort soll ein DP-Slave erweitert werden (Insys-MRX Router).
Die HW-Config war schon etwas strange.
Das in der GSD-Datei des Maschinenlieferanten vorgefertigte Modul ließ sich nicht an Steckplatz 1 platzieren.
Das Modul konnte ab Steckplatz 4 integriert werden, davor musste mit leere Slots aufgefüllt werden.
Die Profibus-Kommunikation als solche läuft. Es gibt keine Fehler in der HW-Config.

Nur leider haben wir es bis jetzt nicht geschafft die Datenblöcke ohne Fehler mit den SFC14/SFC15 Bausteinen zu Schreiben bzw. zu Lesen.
Im Screenshot des FC´s werden entsprechend Error-Codes angezeigt: 32945 bzw. 0x80B1
(sowohl bei "DPRD_DAT" und bei "DPWR_DAT" die gleichen Error-Codes)

Wir nutzen diese System-Bausteine öfter.
Irgendwie bekommen wir Sie bei dieser Anwendung nicht zum Laufen.
Wir haben die Block-Größen der HW-Config eigentlich berücksichtigt.
Hat jemand eine Idee?

BR JS
 

Anhänge

  • FC.jpg
    FC.jpg
    190,5 KB · Aufrufe: 29
  • HW-config.jpg
    HW-config.jpg
    101,3 KB · Aufrufe: 31
Wenn die Daten vom Gerät nicht konsistent übertragen werden, kannst du immer nur 4 Bytes auf einen Rutsch lesen.
 
OK, nach einem kurzen Test, 4 Byte können problemlos, das heißt ohne Error geschrieben bzw. gelesen werden.
Es sind insgesamt 240 Byte in jede Richtung zu übertragen.
Da kommt ein Haufen Schreibarbeit auf einen zu, wenn die Blöcke nicht größer wie 4 Byte sein dürfen ... inkl. Potential für Fehler bei der Hex-Codierung der Adressen !?!
Wo ist dann noch der Unterschied zu "L wert" -> "T xyz" ...

Ok noch ne Frage zum Slave:
Das heißt dass das Gerät unterstützt nicht wirklich konsistente Datenübertragung, richtig?
 
Ok, und wie finde ich das raus, ob das Gerät konsistent überträgt?

Probieren? Kommunikationsparter befragen? Es hängt davon ab, wie es bei deinem Partner konfiguriert ist. Ob es darüber hinaus funktioniert, hängt auch davon ab, welche Blockgröße konsistenter Daten dein DP-Master maximal verarbeiten kann. Notfalls kannst du die PEWs oder PEDs auch ohne SFCs in einer Schleife indirekt parametriert einlesen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ok, und wie finde ich das raus, ob das Gerät konsistent überträgt?
Doppelklick auf das Submodul/Steckplatz/die Zeile mit der E/A Adresse
Mit SFC14/15 kann auch immer nur eine Zeile gelesen/geschrieben werden. Man darf sich auch gerne die Beschreibung der Bausteine in der Hilfe durchlesen.

Da kommt ein Haufen Schreibarbeit auf einen zu, wenn die Blöcke nicht größer wie 4 Byte sein dürfen ...
Wie erklärst du deinen Kunden, dass du ihm viel Geld in Rechnung stellen willst, aber höchstens 3 Mausklicks dafür arbeiten willst? ;)
Wenn die Konsistenz wirklich immer nur ein Doppelword ist, dann schreibe halt 60x "L PED... / T DB1. DBD...", das ist schneller getippt als drüber nachgedacht, ob und wie man das vielleicht abkürzen kann.

noch ne Frage zum Slave:
Das heißt dass das Gerät unterstützt nicht wirklich konsistente Datenübertragung, richtig?
Das musst du in der Projektierung der Submodule des Slaves nachschauen.

Tipp: projektiere die E/A-Adressen so, dass sie im Prozessabbild PAE/PAA liegen, dann brauchst du dir um die Konsistenz (fast) keine Gedanken machen, und brauchst keine SFC14/15 verwenden und darfst es auch nicht. Die CPU händelt das dann ganz automatisch im Hintergrund. Zum Umkopieren der E/A in DB kannst du dann auch BLKMOV verwenden, und zwar für den ganzen Slave am Stück.
 
Ach, sehe gerade, E2M. Die Daten sind nichtkonsistent bzw. "konsistent über Einheit". Das heißt, du kannst SFC14/15 nicht verwenden. Warum mußtest du Leerplätze einfügen? Ich habe diese Schnittstelle auch schon oft genutzt, auch mit S7-315, hatte hier nie ein Problem.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

im Rahmen eines unserer Erweiterungsprojekte haben wir eine Problem mit der Anwendung der SFC14/15 DP-Kommunikationsbausteine.

CPU-Typ: S7-315 2-PN/DP
CAE-Tool: Step7-Classic (Simatic Manager 5.6)

Dort soll ein DP-Slave erweitert werden (Insys-MRX Router).
Die HW-Config war schon etwas strange.
Das in der GSD-Datei des Maschinenlieferanten vorgefertigte Modul ließ sich nicht an Steckplatz 1 platzieren.
Das Modul konnte ab Steckplatz 4 integriert werden, davor musste mit leere Slots aufgefüllt werden.
Die Profibus-Kommunikation als solche läuft. Es gibt keine Fehler in der HW-Config.

Nur leider haben wir es bis jetzt nicht geschafft die Datenblöcke ohne Fehler mit den SFC14/SFC15 Bausteinen zu Schreiben bzw. zu Lesen.
Im Screenshot des FC´s werden entsprechend Error-Codes angezeigt: 32945 bzw. 0x80B1
(sowohl bei "DPRD_DAT" und bei "DPWR_DAT" die gleichen Error-Codes)

Wir nutzen diese System-Bausteine öfter.
Irgendwie bekommen wir Sie bei dieser Anwendung nicht zum Laufen.
Wir haben die Block-Größen der HW-Config eigentlich berücksichtigt.
Hat jemand eine Idee?

BR JS
Ist beim SFC14/15 als Any-Pointer nicht nur Byte erlaubt?
Aus der Hilfe zum Baustein:
Konsistente Daten eines DP-Normslaves/PROFINET IO-Devices lesen mit der SFC 14 "DPRD_DAT"
Zielbereich für die gelesenen Nutzdaten. Er muß genauso lang sein, wie Sie für die selektierte Baugruppe mit STEP 7 projektiert haben. Es ist nur der Datentyp BYTE zulässig.
Hinweis: Beachten Sie, dass der Parameter RECORD bei S7-300-CPUs immer die vollständige Angabe der DB-Parameter erfordert (Bsp.: P#DB13.DBX0.0 Byte 100). Das Weglassen einer expliziten DB-Nr. ist für S7-300-CPUs unzulässig und führt zu einer Fehlermeldung im Anwenderprogramm.
 
Gibt es Forum eigentlich schon eine Funktion, wo die von uns herausgesuchten Hilfe-Texte vorgelesen werden?... ;)

Prozessabbild und SFC20?
Ja klar, nur so. Mit SFC20 BLKMOV kann nicht auf Peripherie Adressen zugegriffen werden, auf Adressen im Speicherbereich der Eingänge und Ausgänge (z.B. Prozessabbild) aber sehr wohl.
 
Zurück
Oben