Step 7 Pointer IN_OUT Schnittstelle

MM_TTE3

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe an einer IN_OUT Schnittstelle eins FB (multiinstanz) ein UDT den ich im Baustein natürlich direkt beschreiben/lesen kann. Wenn ich in dem UDT allerdings ein Datentyp benutze der länger als 4 Byte ist oder einen STRING, funktioniert das ja nicht mehr weil die IN_OUT Schnittstelle nur als Pointer in den FB übergeben wird. Soweit so gut...

Jetzt zu meiner Frage.
In einem DB ist für jeden Aufruf des FB einmal der besagte UDT. Hier ein Beispiel:

UDT500 = 16 Byte
Zeit_1 / DATE_AND_TIME
Zeit_2 / DATE_AND_TIME

DB500 = 48 Byte
Aufruf_1 / UDT500
Aufruf_2 / UDT500
Aufruf_3 / UDT500

Die drei Aufrufe stehen jetzt an meiner IN_OUT Schnittstelle der drei FB´s:
FB500 Aufruf_1: IN_OUT = P#DB500.DBX0.0 Byte 16
FB500 Aufruf_2: IN_OUT = P#DB500.DBX16.0 Byte 16
FB500 Aufruf_3: IN_OUT = P#DB500.DBX32.0 Byte 16

Jetzt möchte ich im FB500 natürlich den jeweiligen Datenbereich des richtigen Aufrufs beschreiben. Hierfür wollte ich den Pointer der IN_OUT Schnittstelle auslesen und mir daraus einen individuellen Any-Pointer bilden. Die beiden DATE_AND_TIME die ich ausgeben möchte liegen im TEMP (Byte 0-15). Hier mein FB500:

FB500
IN_OUT 0.0 / Schnittstelle / UDT500 (6 Byte)
TEMP 0.0 / Zeit_1 / DATE_AND_TIME
TEMP 8.0 / Zeit_2 / DATE_AND_TIME
TEMP 16.0 / IN_OUT_Datenbaustein / INT
TEMP 18.0 / IN_OUT_Anfangsadresse / DWORD
TEMP 22.0 / Zielzeiger / Any


LAR1 P#Schnittstelle

L W [AR1,P#0.0] (AKKU1 = 500)
T #IN_OUT_Datenbaustein

L D [AR1,P#2.0] (AKKU1 = 16#84000000)
L 16#00FFFFFF
UD
T #IN_OUT_Anfangsadresse

Wenn ich den Baustein beobachte liegt hier offensichtlich schon der Fehler. In meiner Variable #IN_OUT_Datenbaustein steht wie gewünscht "500" (Datenbaustein der UDT an der IN_OUT_Schnittstelle). Leider steht im Byte 3-5 nicht wie erwartet der Anfangsbereich meiner UDT (Aufruf_1 = P#0.0; Aufruf_2 = P#16.0; Aufruf_3 = P#32.0) sondern immer nur P#0.0. Im Byte 3, welches ja ausgeblendet wird, steht sogar 16#84 (Speicherbereich Datenbaustein). Aber den Versatz von der UDT im jeweiligen Aufruf bekomme ich nicht raus :(.



Zur Vervollständigung noch der weitere Baustein:
LAR1 P##Zielzeiger
L B#16#10 (S7-Kennung)
T B [AR1,P#0.0]
L B#16#2 (Datentyp Byte)
T B [AR1,P#1.0]
L 16 (Länge der beiden DATE_AND_TIME)
T W [AR1,P#2.0]
L #IN_OUT_Datenbaustein (Datenbaustein der angegebenen UDT)
T W [AR1,P#4.0]
L #IN_OUT_Anfangsadresse (Anfangsadresse der angegeben UDT, welche bei mir leider immer P#0.0 ist)
T D [AR1,P#6.0]
L B#16#84 (Speicherbereich für Datenbaustein)
T B [AR1,P#6.0]
SFC20 soll dann nur
P#L0.0 Byte 16 -> #Zielzeiger
kopieren.



Vielen Dank vorab für die Unterstützung :).
Gruss
 
Zuletzt bearbeitet:
Ich habe noch eine Frage die sicher aber schnell klären dürfte :).

Wenn ich an meinen SFC20 den Zeiger
P#L0.0 BYTE 26
schreibe funktioniert alles wunderbar.

Was mache ich falsch wenn ich mir den Zeiger so zusammenbaue
LAR1 P##Zeiger

L B#16#10
T B [AR1,P#0.0]

L B#16#2
T B [AR1,P#1.0]

L 26
T W [AR1,P#2.0]

L 0
T W [AR1,P#4.0]

L P#0.0
T D [AR1,P#6.0]

L B#16#86
T B [AR1,P#6.0]

Ich dachte B#16#86 steht für den Speicherbereich Lokaldaten. Irgendwie funktioniert es aber nicht :D.

Danke!
Gruss
 
Hallo MM_TTE3
Für deinen Baustein, der den SFC20 aufruft, liegt der Source oder Destination Bereich im eigenen LStack.
Für den SFC20 jedoch nicht! Für ihn liegt der Bereich im LStack des Aufrufers, also des Vaterbausteins.
Du darfst nicht die 0x86 nehmen, sondern musst die 0x87 verwenden!
mfg
Linus
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Linus,

ich war grade am schreiben dass es mit B#16#87 funktioniert aber ich nicht weiß warum :).
Vielen Dank für die Erklärung! Es ist Alles logisch wenn man´s kapiert hat.

Gruss!
 
Irgendwie funktioniert es aber nicht
Kannst Du das "irgendwie" genauer erklären?
Was willst Du eigentlich tun? Was funktioniert nicht?


Ich dachte B#16#86 steht für den Speicherbereich Lokaldaten.
Wenn Du es so schreibst, dann mußt Du nicht wissen, welche Kennung für "Lokaldaten" steht:
Code:
      LAR1  P##Zeiger

      L     B#16#10
      T     B [AR1,P#0.0]

      L     B#16#2
      T     B [AR1,P#1.0]

      L     26
      T     W [AR1,P#2.0]

      L     0
      T     W [AR1,P#4.0]

      L     P#L 0.0
      T     D [AR1,P#6.0]

     CALL "BLKMOV"
      SRCBLK :=#Zeiger   //das muß eine ANY-Variable in TEMP sein
      ...

Harald
 
Es wurde überhaupt nicht´s kopiert mit meinem Pointer aus dem Beitrag oben. Das lag aber daran dass ich LinusAM4V schon erklärt hat den L-Stack vom SFC20 kopiert hätte bei dem Speicherbereich B#16#86. Mit B#16#87 geht es dann wunderbar. Auf die Idee den Speicherbereich direkt als P#L 0.0 mit anzugeben bin ich nicht gekommen :D.

Danke!
Gruss
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe es grade mal ausprobiert mit deiner Anweisung. Leider funktioniert es nicht wenn ich in meinem Zeiger die Bytes 6-9 direkt mit dem Pointer P#L 0.0 beschreibe.
Wenn ich mir das online ansehe schreibt er mir dabei auch 86000000 in meinen Any-Zeiger wobei die 86 wieder für den aktuellen L-Stack steht.

Schreibe ich das dann wie von dir oben angegeben an meinen SFC20 dann wird nichts kopiert weil die 86 wohl für den SFC20 bedeutet er soll seinen eigenen internen L-Stack kopieren. So kann ich es mir nur vorstellen und so verstehe ich LinusAM4V auch in seiner Erklärung.

Nur wenn ich es so mache klappt es:

LAR1 P##Zeiger

L B#16#10
T B [AR1,P#0.0]

L B#16#2
T B [AR1,P#1.0]

L 26
T W [AR1,P#2.0]

L 0
T W [AR1,P#4.0]

L P#0.0
T D [AR1,P#6.0]

L B#16#87
T B [AR1,P#6.0]

Gruss!
 
Liebe Gemeinde,

ich bin durch die SuFu auf diesen Beitrag gestoßen und denke, dass mein Problem im gleichen Stadion spielt - daher meine Frage an dieser Stelle:

Folgende Situation:
OB1 ruft nur FC1 auf
FC hat nur Lokaldaten.
Ich möchte das AR1 auf den Any-Zeiger an L0.0 ausrichten.

folgendes ist zu sehen:

2 Byte Offset.jpg

Frage: woher kommen die zwei Byte Offset???
Das ganze läuft im Moment im PLC-SIM.

Vielen Dank für Eure Meinungen!!!


Grüße aus Nordhessen
Meista
 
Hallo Meister,
das ist eine interessante Frage. Ich habe dein Beispiel nachprogrammiert (was ja wirklich nicht viel Zeit braucht...) und bekomme die richtige
Anzeige mit L0.0 im AR1 für den Parameter #Ein.
Daher meine Frage: Hast du irgendwann einmal die Anzeigesprache von AWL nach KOP/FUP umgeschaltet und zurück?
Oder mal ein Upload eines Online Bausteins durchgeführt?
Wenn du im Baustein eine nichtige Änderung durchführst (Leerzeile) und danach den Baustein abspeicherst und downlädst, bleibt die Anzeige bei L2.0?
mfg
Linus
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Linus!

Vielen Dank für Deine schnelle Antwort!!!
Die üblichen Spielereien haben wir während der Fehlersuche allesamt schon durchprobiert - ohne Änderung.

Ursprünglich sollte ein Any-Pointer parametriert werden und dann mit einem Blockmove etwas kopiert werden - kein Hexenwerk also.
Als der Blockmove mit der RetVal antwortete, dass ein Fehler beim Lesen eines Parameters auftrat ging die Suche los.
In der Folge konnte das Problem soweit isoliert werden, dass es reichte die FC mit nur einer Anweisung un bekanntem Ausgang zu versorgen.

Der Knaller kommt aber jetzt erst:
Das Problem habe eigentlich nicht ich sondern mein [jüngerer] Kollege, welcher sich vertrauensvoll an mich wandte.

Inspiriert von Deiner Antwort habe ich an meinem Arbeitsplatz das gleiche getan wie Du nämlich die Situation nachgestellt und komme [wer hätte das gedacht] zum gleichen Ergebnis wie Du nämlich 0.0......

Es bleibt also weiter spannend....

Ich melde mich wenn ich was Neues weiß.....
 
Was mir dazu einfällt:
Hmm, liegt es am PLCSIM, an der CPU, am Step7, am Projekt oder am Baustein?

Am schnellsten und sichersten sollte das Problem verschwinden über Erzeugen eines neuen Bausteins und Löschen des problematischen Bausteins, evtl. die Programm-Netzwerke kopieren oder über eine AWL-Quelle gehen. Allerdings weiß man dann nicht die Ursache des Phänomens...

Der Kollege testet es auf seinem PLCSIM --> falsche Adresse L2.0
Du testest es auf Deinem PLCSIM --> OK, richtige Adresse L0.0
Richtig so? Oder...?

Und wenn Ihr Eure Projekte tauscht? Wandert der Fehler mit oder bleibt er auf dem Computer?
Versionsnummern der SIMATIC-Software vergleichen.

Das Problem habt Ihr zuerst auf einer echten CPU bemerkt?
Wenn der Baustein in einer echten CPU 315-2DP von zwei verschiedenen PG beobachtet wird, zeigen beide PG das gleiche an?
Wie ist es, wenn der Baustein vor der Brille zuerst online geöffnet wird? Auch mal über "Erreichbare Teilnehmer" gehen und online öffnen.
Was sagt die Baustein-Konsistenzprüfung?
Wenn der Kollege einen Mini-Test-FC erstellt, der ist dann auch sofort falsch?

Harald
 
Gelöst!

Wir haben am betroffenen Arbeitsplatz ein neues Projekt erstellt und den FC hinein kopiert - im OB1 aufgerufen und.... le voilá... es steht eine 0.0 im AR1.

Aber warum?

Beim Blick in die Deklaration der Lokaldaten des FC ist uns ein Eintrag aufgefallen, welcher vorher noch nicht da war. Vor dem Any steht nun plötzlich eine andere Integer-Variable, welche mein Kollege im ursprünglichen Baustein mal angelegt und dann aber wieder gelöscht hatte. Der Editor hatte diese wohl noch im "Gedächtnis", hat sie uns aber im Deklarationsteil nicht anzeigen wollen.

Erschreckend ist die Tatsache, dass der Baustein sich ja online betrachten ließ und keinerlei Meldungen erschienen - das steigert nicht unbedingt das Vertrauen in die Bildschirmanzeige.
Hätten wir keinen Screen-Shot [aus dem ersten Beitrag ersichtlich] angefertigt, würde ich es vermutlich selbst nicht glauben wollen, wenn mir jemand die Geschichte erzählen würde.

Man lernt halt nie aus.....;)


Danke an Linus für Deine Bemühungen.


Grüße aus Nordhessen
DaMeista
 
Zurück
Oben