Step 7 Problem mit Pointer

Holle-52499

Level-2
Beiträge
52
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

habe wieder mal ein Problem mit einem Pointer.
Und zwar lese ich über einen FB die Statuswörter von einem FU in einen DB ein.
Diesen Baustein habe ich erweitert, weil dieser mir bisher nur 2 Statuswörter vom Umrichter übergeben hat.
Er soll in Zukunft 6 Statutswörter einlesen und in den DB schreiben.
Für das Statuswort wurde unter Stat Variablen ein eigenes Struct (STW) angelegt.
Dieses besteht zu Beginn aus 16 Bits (einzelne Stautsmeldeungen) und 5 Integer Variablen.
Der Code sieht wie folgt aus:

Code:
      NOP   0
//--- Umrichter-Status (STW) einlesen auf lokalen Merkerbereich
      L     #PeripherAddr               // Übergebene Peripherieadresse
      SLW   3                           // Auf Bereichszeiger-Format bringen
      LAR1                              // Lade Peripherie-Eingangsadresse in AR1
      L     PED [AR1,P#8.0]             // Lade Umrichter-STW aus Peripherie-Eingang in AKKU1
                                                  [COLOR=#ff0000] // 8 Byte Offset, da die Statuswörter 8 Bytes hinter dem Peripherieeingangswort liegen.[/COLOR]
      LAR1  P##STW                      // Lade lokale Adresse des Umrichter-Statusworts in AR1
      T     D [AR1,P#0.0]               // Transferiere AKKU1 nach #STW
     
 
//*****************Erweiterung *****************\\
      L     #PeripherAddr               //Erweiterung
      SLW   3
      LAR1  
      L     PED [AR1,P#12.0]       [COLOR=#ff0000] // 4 weitere Bytes Offset, da die Bytes 8-11 schon eingelesen wurden[/COLOR]
      LAR1  P##STW
      T     D [AR1,P#4.0]               //Statuswort 3+4 übergeben
                                                 [COLOR=#ff0000]// die geladenen Wörter 4 Byte hinter dem Beginn von STW ablegen.[/COLOR]

      L     #PeripherAddr               //Erweiterung
      SLW   3
      LAR1  
      L     PED [AR1,P#16.0]        [COLOR=#ff0000]// 4 weitere Bytes Offset, da die Bytes 12-15 schon eingelesen wurden[/COLOR]
      LAR1  P##STW
      T     D [AR1,P#8.0]               // Statuswort 5+6 übergeben
                                                 [COLOR=#FF0000]// die geladenen Wörter 8 Byte hinter dem Beginn von STW ablegen.[/COLOR]
//*****************Erweiterung Ende*****************\\
 
      LAR1  P##STW 
      L     DW#16#0
      <>D                               // Vergleich #STW 1. Datenwort auf <> "0"
      =     #BusOk                      // Kommunikation zum Umrichter ist möglich

Wenn ich das Programm als ganzes Laufen lassen, zeigen die Adressregister die richtigen Anfangsadressen an.
Von daher vermute ich, dass es an den Adressregistern nicht liegen kann.

Wenn ich die Erweiterung überspringe funktioniert das Ganze, mit der Erweiterung allerdings nicht.
Habe die Stellen, wo ich vermute das es hakt, rot kommentiert.

Wo liegt da genau mein Denkfehler?


Gruß
Holger
 
Was heißt "funktioniert nicht"?

Hast Du den/die IDB neu generiert und in die CPU geladen?
Rufst Du jede FB-Instanz mit eigenem IDB auf? (Dein Code ist mit und auch ohne die Erweiterung nicht multiinstanzfähig).

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Funktioniert nicht heißt das alle Statutswörter "0" sind, inklusive den 16 Statusbits. Sieht so aus als werden die dort irgendwo überschrieben.
Der IDB wurden neu generiert und in die CPU geladen. Jede FB-Instanz bekommt einen eigenen IDB.
 
Funktioniert nicht heißt das alle Statutswörter "0" sind, inklusive den 16 Statusbits.
Kann es sein, daß in HW Konfig der E-Bereich des FU konsistent über "Gesamte Länge" projektiert ist? Dann muß der E-Bereich mit SFC14 eingelesen werden. Oder man legt die E/A-Adressen ins Prozessabbild PAE/PAA, dann liest die CPU die Adressen automatisch richtig ein.

Harald
 
Wie kann ich das mit "über die gesamte Länge konsistent" genau verstehen?

Der Umrichter (Danfoss FC302) ist in der HW Konfig Modul Consistent mit PPO Typ 2 projektiert.
Ich kann die Statuswörter problemlos über PEW einlesen. Nur bei dem Umkopieren in den DB funktioniert das leider nicht nach der Erweiterung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie kann ich das mit "über die gesamte Länge konsistent" genau verstehen?

Der Umrichter (Danfoss FC302) ist in der HW Konfig Modul Consistent mit PPO Typ 2 projektiert.
Mache in HW Konfig einen Doppelklick auf einen Steckplatz des DP-Slaves des FU, da wirst Du sehen, daß Du da die Adressen für Ausgang und Eingang festlegen kannst und dahinter steht z.B. "Länge: 4" (oder 6), "Einheit: Worte" und "Konsistent über: gesamte Länge" --> das heißt, der Eingangsbereich kann/darf nur im Ganzen von 4 Worten (8 Byte) gelesen werden (damit die Daten konsistent zusammen bleiben). Das ist mit "L PE..." nicht möglich --> es muß SFC14 verwendet werden.

Mehr zum Thema "Datenkonsistenz" lies mal die Hilfe zum SFC14 "DPRD_DAT"

Für den FU FC302 kenne ich die GSD-Datei DA02040A.GSD Revision 2.13 (für die Danfoss FU-Familien FC100/200/300), da gibt es für verschiedene PPO-Typen jeweils 2 Module: "PPO Type x Module consistent PCD" und "PPO Type x Word consistent PCD"
- bei "Module consistent" ist Konsistenz über "gesamte Länge" eingestellt, es muß das gesamte Modul (Steckplatz) "am Stück" gelesen und geschrieben werden; wenn das mehr als 4 Byte sind, dann muß SFC14 und SFC15 verwendet werden.
- bei "Word consistent" ist Konsistenz über "Einheit" (Einheit: Worte) eingestellt, es müssen die E/A-Adressen als Word oder DWord mit "L PE..." oder "T PA..." gelesen/geschrieben werden

(Die "Word consistent"-Module habe ich noch nie verwendet.)

Ich kann die Statuswörter problemlos über PEW einlesen. Nur bei dem Umkopieren in den DB funktioniert das leider nicht nach der Erweiterung.
Warum das mit "L PEW..." bzw. "L PED..." für einzelne Daten funktioniert hat, kann ich jetzt nicht sagen, Deine Angaben sind nicht ausreichend. Vermutlich hattest Du da auch eine andere HW Konfig? (in Deinem Programmcode in Beitrag #1 sehe ich keinen Fehler)
Was hast Du für eine CPU? (6ES7 ...., Vx.y.z)
Welche E/A-Adressen hast Du für den FU projektiert?

Harald
 
Habe mal ein Bild von den Eigenschaften des DP Slaves gemacht.
Die CPU ist eine IM-151-8 PN/DP CPU (6ES7 151-8AB00-0AB0 V2.7).

Pointer.jpg


Bisher haben wir immer "Module consistent" eingesetzt.
In der HW Konfig ist alles identisch zu den anderen Anlagen, wo wir den FB auch einsetzen.

Was passiert denn wenn ich das ganze jetzt auf "Word consistent" umstelle? Außer das ich alles über "L PE...." oder "T PA..." lesen/schreiben kann?

Was allerdings auch komisch ist... Wenn ich meine Erweiterung überspringe läuft alles so wie es soll und ich kann im Programm mit einem PEW xxx die einzelnen Statuswörter nochmal abrufen und bekomme dabei auch die richtigen Werte raus.
 
Eigentlich dürfte der Zugriff auf das "4 Worte Module consistent" mit "L PED" gar nicht funktionieren (d.h. müßte bei allen Adressen 0 liefern).

Vielleicht ist es ein Firmware-Fehler der CPU 151-8AB0? Die Firmwareversion 2.7.1 gibt es anscheinend nicht öffentlich zum Download. Vielleicht war diese erste IM151-8 CPU so fehlerhaft (in der Hardware?), daß kein Firmware-Update geholfen hätte und deshalb ein Nachfolger 151-8AB01 herausgebracht werden mußte.
Wo finden Sie die aktuellen Updates der Betriebssysteme für die CPUs S7-31x, IM15x und BM147?

Wenn Du nicht auf SFC14/SFC15 umstellen willst: Du könntest in den CPU-Eigenschaften die Prozessabbilder der Eingänge und Ausgänge vergrößern (z.B. auf 1024 Bytes), so daß die E/A-Adressen des/der FU im Prozessabbild liegen und dann statt "L PED... / T PAD..." mit "L ED... / T AD..." zugreifen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein paar Unkorrektheiten im geposteten Code, die aber mit dem Problem nichts zu tun haben:
Code:
      L     #PeripherAddr               // Übergebene Peripherieadresse
      [COLOR="#FF0000"]SLW[/COLOR]   3                           // Auf Bereichszeiger-Format bringen
[...]
      LAR1  P##STW
      [COLOR="#FF0000"]L     W [AR1,P#0.0]         <-- das fehlt hier noch[/COLOR]
      L     DW#16#0
      <>D                               // Vergleich #STW 1. Datenwort auf <> "0"
      =     #BusOk                      // Kommunikation zum Umrichter ist möglich
Statt SLW muß eigentlich SLD verwendet werden, das spielt aber keine Rolle solange #PeripherAddr im Bereich 0 ... 8191 ist.

Harald
 
Zurück
Oben