Ergebnis von DI_String in Temp-Var

volker

Supermoderator
Teammitglied
Beiträge
5.805
Reaktionspunkte
1.027
Zuviel Werbung?
-> Hier kostenlos registrieren
Hay

Wieso funktioniert das nicht?
Wenn ich das ergebnis der fc5 in einen temporären string lege steht da nur müll drin.
 

Anhänge

  • Zwischenablage02.jpg
    Zwischenablage02.jpg
    113,8 KB · Aufrufe: 49
Hallo,
du musst der Temporären-String-Variable erst die Gesamt-Länge im ersten Byte mitteilen (siehe Grafik)!!

SpsForum.JPG

Dann sollte es eigentlich funktionieren!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hm. ok.
ich dachte das macht die fc5 automatisch.
und warum klappt es dann im ersten aufruf? da beschreibe ich auch nicht dbb0
 
Es funktioniert deshalb da bei einem String der in einem DB angelegt wird die Gesamtlänge im ersten Byte automatisch eingetragen wird!

SpsForum.JPG

Die Funktion des FC5 braucht die Gesamtlänge des Strings um Ordnungsgemäß arbeiten zu können!
 
so das funktioniert jetzt. und schon mein nächstes problem.
ich möchte nun einen teil des temporären strings in einen db kopieren.
dazu bau ich mir einen any-zeiger auf den l-stack. die sfc20 meldet aber fehler 8124. also bereichlängenfehler beim lesen.

2. wenn ich LAR1 P##t_string lade steht ja 2.0 im ar1. ich brauche diese adresse nun dezimal, also 2 wie bekomm ich das hin?
 

Anhänge

  • Zwischenablage02.jpg
    Zwischenablage02.jpg
    74,5 KB · Aufrufe: 25
der pointer ergibt sich doch aus
LAR1 P##t_string //temp-var in meinem fall 2.0 im AR1

wie soll ich jetzt an die 2 kommen?

TAR1
SRD 3
das klappt aber nicht

das problem ist aber nur zweitrangig. im notfall greife ich direkt auf das LB zu. wäre halt schöner wenn ich das vermeiden könnte.

vorrangiges prob ist warum ich den l-stack nicht mit der sfc20 lesen kann
 
Hallo Volker,

das mit den Lokaldaten und dem SFC 20 ist ganz einfach:

Mit 86 (Speicherbereich L-Daten) versucht der SFC 20 seine eigenen Lokaldaten zu kopieren.
Du musst hier die 87 (vorherige L-Daten) eintragen. Dann funktioniert es.

Grüße
Gebs
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für den Tip. Funktioniert aber trotzdem nicht.
Die sfc20 meldet zwar keinen fehler mehr aber es werden keine daten kopiert

Ich habe das jetzt mit einer schleife ohne die sfc20 gelöst. aber mich würde trotzdem interessieren warum es mit der sfc nicht klappt.
 

Anhänge

  • Zwischenablage02.jpg
    Zwischenablage02.jpg
    120 KB · Aufrufe: 10
hatte ich so auch probiert und dabei aber nur im baustein online geguckt.
ich hatte erwartet das ich in der anzeige des akkus nach dem srd die 12 stehen habe.
dem ist aber nicht so. wenn man die var lädt steht da die erwartete 12. :oops:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
so langsam zweifel ich an meinen kenntnissen.

L LB [AR1,P#1.0] sollte eigentlich die tasächliche stringlänge liefern, liefert mir aber schon das erste zeichen. 43 also das plus.
:confused: :confused::confused::confused:
 

Anhänge

  • Zwischenablage02.gif
    Zwischenablage02.gif
    16,1 KB · Aufrufe: 15
Zuletzt bearbeitet:
voriges hat sich erledigt.
aus irgendeinem grund stimmte das ar1 nicht mehr (was man im status nicht sehen kann)

wenn ich nach dem aufruf des fc501 LAR1 P##t_string erneut aufrufe passt alles.
 

Anhänge

  • Zwischenablage02.gif
    Zwischenablage02.gif
    7,1 KB · Aufrufe: 13
Zuletzt bearbeitet:
Um nochmal auf die Zahl 2 zurückzukommen. Nach einem
Code:
TAR1
SRD 3
steht natürlich nicht "2" im Akku, da das Laden des AR1 mittels
Code:
LAR1 P##t_string
auch keinen typlosen Pointer, sondern einen auf die Lokaldaten geladen hat, nämlich: 16#86000010.

Also ergibt das Zurückrechnen eine 16#10C00002. Zum Erhalten des typlosen Pointers sollte man immer vorher alles oberhalb von Bit 18 wegmaskieren:
Code:
TAR1
L16#0007FFFF
UD
oder eben nach dem Schieben nur das untere Wort verwenden:
Code:
TAR1
SRD 3
L 16#ffff
UW
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und jetzt noch zum Problem mit dem SFC20:

Dein erster Versuch war ja fehlgeschlagen, da du als Typ die 86 (Lokaldaten) und nicht die 87 (Vorgängerlokaldaten) verwendet hattest wie Gebs geschrieben hatte.

Dein zweiter Anlauf kopiert etwas unsinnige Daten, da du jetzt versuchst den gesamten temporären String als Bytefolge in den Ziel-String zu kopieren. Dabei werden auch die Längenbytes des temporären Strings als Nutzzeichen in den Zielstring kopiert.
Entweder String nach String kopieren (also den qany als Pointer vom Typ String aufbauen) oder nur die eigentlichen Nutzdaten des temporären Strings als Bytes in den Ziel-String kopieren (so, wie du es im ersten Versuch probiert hast, der mit dem 86/87 Problem fehlgeschlagen war). Also bei einem Anypointer des Typs Byte als Startadresse des Pointers nicht den Anfang des Strings (die Längenbytes), sondern erst die Adresse des ersten Zeichens angeben, als Länge dann (in deinem Falle) maximal die 11 Bytes.
 
Um nochmal auf die Zahl 2 zurückzukommen. Nach einem
Code:
TAR1
SRD 3
steht natürlich nicht "2" im Akku, da das Laden des AR1 mittels
Code:
LAR1 P##t_string
auch keinen typlosen Pointer, sondern einen auf die Lokaldaten geladen hat, nämlich: 16#86000010.

Also ergibt das Zurückrechnen eine 16#10C00002. Zum Erhalten des typlosen Pointers sollte man immer vorher alles oberhalb von Bit 18 wegmaskieren:
Code:
TAR1
L16#0007FFFF
UD
oder eben nach dem Schieben nur das untere Wort verwenden:
Code:
TAR1
SRD 3
L 16#ffff
UW

Wie ich schon in #10 schrieb, geht das auch einfacher, indem man das Ergebnis von SRD 3 gleich in eine einfache INT transferiert, Da wird das High-Word mit der Typinfo einfach unter den Tisch fallen gelassen.
 
Und jetzt noch zum Problem mit dem SFC20:

Dabei werden auch die Längenbytes des temporären Strings als Nutzzeichen in den Zielstring kopiert.
das war nur ein test. nicht das was ich dann wirklich machen will.
nicht desto trotz hätte die sfc aber den gesamten string kopieren sollen.
der sfc ist es völlig egal was sie kopiert. ich kopiere einfach 13 byte und gut ist. oder ist das nicht so?
die sfc hat aber gar nichts gemacht.

poniterdadresse als int:
so wie ralle das geschrieben hat klappt das gut.
ich habe da nur falsch im status beobachtet und deshalb was falschen gesehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
aus irgendeinem grund stimmte das ar1 nicht mehr (was man im status nicht sehen kann)
Die Adressregister kann man im AWL-Programmstatus beobachten.
einblenden: rechter Mausklick im AWL-Programmstatus-Bereich > Einblenden > Adressregister 1
ausblenden: rechter Mausklick in die auszublendende Spalte > Ausblenden

Harald
 
weiss ich ;) schau dir das bild im post 12 an. da bleibt das ar1 auf 2.0
im bild des post 13 auch schön zu sehen bei
TAR1
LAR1
Ja richtig, ich hätte mir Deine Screenshots vorher ansehen sollen :oops: ... da sehe ich, daß Du es weißt.

Im Bild von #13 ist deutlich zu sehen, daß der AR1-Status bei TAR1 falsch angezeigt wird. (ich meine, das ist ein Bug von PLCSIM)

Allerdings wundere ich mich nicht, daß das AR1 nach dem Aufruf eines anderen Bausteins verändert ist. AR1 wird bei CALL nicht automatisch gesichert und wiederhergestellt. Das muß man ggf. selber machen.

Harald
 
Zurück
Oben