kleine Zeigerfrage

Ralle

Super-Moderator , User des Jahres 2006-2007
Teammitglied
Beiträge
15.400
Reaktionspunkte
4.034
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab gerade einen Fehler zu suchen. Irgendein Baustein schreibt Daten wild in die SPS, denke ein Pointerproblem. Dazu seh ich mir gerade einen Fremdbaustein an und stolpere über 2 Sachen:

1.

Code:
//Adresse der DP in Adressregister
      L     DID  134
      L     DIW  138
      LAR2
AR2 lädt das Adreßregister AR2 mit dem Inhalt von AKKU 1 (32 Bit-Pointer).
Ok, merke gerade, das kann ich mir noch erklären, Grundadresse und dann nochmal überschmieren, dafür würd ich dem Progger die Finger spitzen.

2.

Code:
      TAR1  #RettAR2                    //Adresse der DP in Adressregister
      L     DID  128
      L     DIW  132
      LAR2  
      L     DIB    0                    //TAG übermitteln
      T     PAB [AR2,P#5.0]
      L     DIB    1
      T     PAB [AR2,P#4.0]
      L     DIB    2
      T     PAB [AR2,P#3.0]
      L     DIB    3
      T     PAB [AR2,P#2.0]
      NOP   0

...

      L     PEB [AR2,P#1.0]
      T     DIB  272
      L     PEB [AR2,P#0.0]
      T     DIB  273
      LAR1  #RettAR2
      NOP   0
Er arbeitet die ganze Zeit nur mit AR2, rettet aber AR1.
Macht das Sinn, sollte man nicht AR2 retten (ist ein FB, der wiederumg in einem FB aufgerufen wird, aber keine Multiinstanz!)
 
Ich sehe den Sinn noch nicht warum der Vogel das Adressregister 2 überhaupt benutzt. Schreib das Ganze mal so um das das Adressregister 1 benutzt wird. Dann braucht man das 2er auch nicht retten, mit dem kann man nämlich ne Menge kaputt machen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich sehe den Sinn noch nicht warum der Vogel das Adressregister 2 überhaupt benutzt. Schreib das Ganze mal so um das das Adressregister 1 benutzt wird. Dann braucht man das 2er auch nicht retten, mit dem kann man nämlich ne Menge kaputt machen.

Genau das befürchte ich auch!
 
gibt das nicht Probleme wenn ich mit dem AR2 arbeite und auf den DI zugreife.

Dachte immer wenn mit dem AR2 gearbeitet wird, dürfen keine Lokaldatenzugriffe erfolgen, da der FB seine IDb verwaltung im AR2 vornimmt.
 
Ist der FB denn multiinstanzfähig? Oder wurde beim Anlegen des FB als neuer Baustein der Haken bei Multiinstanzfähigkeit entfernt? Wenn der FB nicht multiinstanzfähig ist, kann man ganz normal mit dem AR2 arbeiten.

Gruß Kai
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Kai
Der betreffende FB, als auch der Aufrufende FB sind Multiinstanzfähig, aber nicht als solche verwendet, sondern ganz normal mit Call FBxy, DBxy aufgerufen.
 
Code:
//Adresse der DP in Adressregister
      L     DID  134                    // DID134 => AKKU 1
      L     DIW  138                    // AKKU 1 => AKKU 2 / DIW138 => AKKU 1
      LAR2                              // AKKU 1 => AR2

So richtig verstehen kann ich den Programmcode nicht. :confused:

Gruß Kai
 
Code:
//Adresse der DP in Adressregister
      L     DID  134                    // DID134 => AKKU 1
      L     DIW  138                    // AKKU 1 => AKKU 2 / DIW138 => AKKU 1
      LAR2                              // AKKU 1 => AR2
So richtig verstehen kann ich den Programmcode nicht. :confused:

Gruß Kai

Ich denke mal, ein Teil des DID 134 bleibt ja stehen im Akku1, da ja in der zweiten Zeile nur noch ein DIW geschrieben wird. Wer sich sowas nur einfallen läßt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke mal, ein Teil des DID 134 bleibt ja stehen im Akku1, da ja in der zweiten Zeile nur noch ein DIW geschrieben wird. Wer sich sowas nur einfallen läßt?

Das stimmt nicht, es bleibt kein Teil des DID 134 im AKKU 1 stehen.

Es wird zuerst der Inhalt von AKKU 1 (DID 134) nach AKKU 2 geschrieben.

Und dann wird der Wert von DIW 138 rechtsbündig als 32-Bit Wert in den AKKU 1 geschrieben.

Gruß Kai
 
Aber aufpassen..

Ich denke mal, ein Teil des DID 134 bleibt ja stehen im Akku1, da ja in der zweiten Zeile nur noch ein DIW geschrieben wird. Wer sich sowas nur einfallen läßt?

Derjenige denkt aber bestimmt, er ist der grösste, 100%.
@Ralle, ich verstehe langsam, was du meinst mit unsaubere Implementierungen; ich habe so was noch nicht gesehen..
Man, man, gibt es Programmierer..

@Kai: vielleicht war es so bei S5, mit den Akkus?

Vladi
 
Code:
//Adresse der DP in Adressregister
      L     DID  134                    // DID134 => AKKU 1
      L     DIW  138                    // AKKU 1 => AKKU 2 / DIW138 => AKKU 1
      LAR2                              // AKKU 1 => AR2

Also ich denke mal, ich weiß jetzt, was er beabsichtigt hat.

Auf Adresse 134 ist ein Pointer als IN (das sind 6 Byte) definiert.
Am IN steht: P#344.0
Dort soll also ein kompletter Pointer geladen werden.
Ich mein es funktioniert, weil letztendlich kein kompletter Pointer (DB-Information) gebraucht wird. Was meint ihr?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Auf Adresse 134 ist ein Pointer als IN (das sind 6 Byte) definiert.
Am IN steht: P#344.0
Dort soll also ein kompletter Pointer geladen werden.
Ich mein es funktioniert, weil letztendlich kein kompletter Pointer (DB-Information) gebraucht wird. Was meint ihr?

Er lädt mit dem DIW 138 also nur die Byte-Adresse und die Bit-Adresse des Pointers. Die DB-Nummer und der Operandenbereich werden nicht gebraucht.

Das sollte tatsächlich funktionieren, solange die Byte-Adresse des Pointers nicht zu groß wird. Die Byte-Adresse und die Bit-Adresse liegen ja in den Bytes DIB 137 - DIB 139 und nicht nur in den Bytes DIB 138 - DIB 139.

Folgender Programmcode sollte aber auch funktionieren:

Code:
//Adresse der DP in Adressregister
      L     DIW  138                    // POINTER Byte-Adresse + Bit-Adresse
      LAR2

Gruß Kai
 
Ich denke mal, ein Teil des DID 134 bleibt ja stehen im Akku1, da ja in der zweiten Zeile nur noch ein DIW geschrieben wird. Wer sich sowas nur einfallen läßt?

Hallo Ralle,

wie Kai schon richtig sagte, dass stimmt nicht.

Auszug aus der S7 Hilfe zum Ladebefehl:

Code:
Beschreibung 

L <Operand> lädt den Inhalt des adressierten Bytes, Wortes oder Doppelwortes in AKKU 1, nachdem zuvor der alte Inhalt von 
AKKU 1 in AKKU 2 gespeichert wurde [B]und AKKU 1 auf "0" zurückgesetzt wurde[/B].

Inhalt von Akkumulator 1 

Inhalt von AKKU 1 	AKKU1-H-H	AKKU1-H-L	AKKU1-L-H	AKKU1-L-L
vor Ausführung der Ladeoperation	XXXXXXXX	XXXXXXXX	XXXXXXXX	XXXXXXXX
nach Ausführung von L MB10 (L <Byte>)	00000000	00000000	00000000	<MB10>
nach Ausführung von L MW10  (L <Wort>)	00000000	00000000	<MB10>	<MB11>
nach Ausführung von L MD10  
(L <Doppelwort>)	<MB10>	<MB11>	<MB12>	<MB13>
 
Er lädt mit dem DIW 138 also nur die Byte-Adresse und die Bit-Adresse des Pointers. Die DB-Nummer und der Operandenbereich werden nicht gebraucht.

Das sollte tatsächlich funktionieren, solange die Byte-Adresse des Pointers nicht zu groß wird. Die Byte-Adresse und die Bit-Adresse liegen ja in den Bytes DIB 137 - DIB 139 und nicht nur in den Bytes DIB 138 - DIB 139.

Folgender Programmcode sollte aber auch funktionieren:

Code:
//Adresse der DP in Adressregister
      L     DIW  138                    // POINTER Byte-Adresse + Bit-Adresse
      LAR2
Gruß Kai

Seh ich auch so.
*ACK*

@IBN

Ja, alles klar, war mal so meiner erste Vermutung, bevor ich drauf kam, daß dort versucht wurde einen 6-Byte-Pointer zu laden. Das mit dem Akku ist ja eingentlich auch klar, sonst müßte man den selbst auf Null setzen, bevor man 1 Byte lädt und transferiert.
 
Zuletzt bearbeitet:
Zurück
Oben