Step 7 Frage: Aufbau Any-Pointer

[Stevemilla]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Gemeinde,

ich beschäftige mich gerade mit dem Thema Any-Pointer. Danke an Volker für die kurze Anleitung (Any-Zeiger für Datentypen).
Meine Frage: Steht im Byte 0 (10h für S7) der max. zu adressierbare Speicherbereich des geöffneten DBs? oder was bedeutet 10h für S7 ???

Gruss steve

 

[MFreiberger]

Moin Stevemilla,

nein. Die 10h in Byte 0 steht dafür, dass es sich um eine S7 handelt. Vielleicht gibt es noch einmal eine andere Steuerung von SIEMENS, bei der der Wert dann geändert werden müsste. Auf jeden Fall soll der Wert konstant sein und immer 10h betragen.
In der Hilfe gibt es eine sehr gute Beschreibung für den Any-Pointer: suche nach "Format der Parametertyps Any"

Gruß

MFreiberger

 

[Stevemilla]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo MFreiberger,
vielen Dank für die schnelle Antwort.

 

[vierlagig]

In der Hilfe gibt es eine sehr gute Beschreibung für den Any-Pointer: suche nach "Format der Parametertyps Any"

aber nicht für die Syntax-ID und den tieferen Sinn dahinter.
auch die Siemens-Seiten schweigen sich dazu aus.

Deine Vermutung klingt naheliegend aber: wozu?

Schon mal mit einer anderen Syntax-ID probiert?

 

[MFreiberger]

Moin vierlagig,

Schon mal mit einer anderen Syntax-ID probiert?

nein.

in dem Buch "Automatisieren mit STEP 7 in AWL und SCL" von Hans Berger steht unter 25.1.3 "Im ersten Byte des ANY-Zeigers steht die Syntax-ID; sie ist bei STEP 7 immer 10[SUB]hex[/SUB].".
Auch hier keine weitere Beschreibung.
Allerdings könnte der Hinweis "...bei STEP 7..." vielleicht eher auf eine andere Programmiersoftware, als auf eine andere Steuerung hinweisen?
Aber so kommen wir nicht weiter. Ist allerdings auch völlig unerheblich, weil man offensichtlich auf dem System Step 7 nichts Anderes damit anfangen kann

Gruß

MFreiberger

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe auch schon oft darüber nachgedacht wofür man diese Syntax-ID brauchen könnte. Wenn man mal die Begriffe "Syntax" und "ID" näher betrachtet, dann wird es schon etwas deutlicher. Diese ID beschreibt eindeutig den Aufbau des Pointers. Offensichtlich gibt es hierfür jedoch keinen einheitlichen Standard, bzw. ist ein einziger Standard bei verschieden System garnicht möglich. Im www habe auch ich nirgendwo Informationen dazu gefunden.

Entweder ist in irgendwelchen Spezifikationen definiert dass das erste Byte im ANY die Syntax des Pointers festlegt oder Siemens hat in weiser Voraussicht diesen Datenpunkt festgelegt. Man muss bedenken dass nach Veröffentlichung der Ur-Version eines Systems nachträgliche Änderungen fundamentaler Dinge sehr schwierig werden können. So gesehen, hätte ich auch eine ID für die Syntax eingebaut. Frei nach dem Motto "Passt schon irgendwie und schadet ja auch nicht".

 

[psu]

Ich sitze Aktuell bei einer IBN vor einem Problem, was mich zu diesem Post geführt hat...
Vlt kann mir ja jemand weiter helfen, weil ich glaube dass mein Problem daher rührt.

Ich mache derzeit einen Retrofit, bei dem Steuerungen mit einer 319F als Kopfsteuerungen kommunizieren.
Eine dieser Steuerungen haben wir jetzt als erstes getauscht gegen eine 1500er
Die Kommunikation passt soweit, alles was bis 1 Byte groß ist kommt auf der Kopfsteuerung auch richtig an und wird sauber in den DB gepackt.
Das Abgreifen dieser Eingangsdaten geschieht in der Kopfsteuerung Indirekt in AWL und eben auch mit Any-Pointern.
Ich habe das Gefühl als würde der Zugriff jetzt anders sein oder Low und High Byte getauscht.
Vlt mag sich ja jemand der sich mit den ANY-Pointern auskennt zu diesem alten Post äußern und mir helfen. Dann würde ich einen Screenshot des Netzwerks einfügen.

 

[Boxy]

Ich sitze Aktuell bei einer IBN vor einem Problem, was mich zu diesem Post geführt hat...
Vlt kann mir ja jemand weiter helfen, weil ich glaube dass mein Problem daher rührt.

Ich mache derzeit einen Retrofit, bei dem Steuerungen mit einer 319F als Kopfsteuerungen kommunizieren.
Eine dieser Steuerungen haben wir jetzt als erstes getauscht gegen eine 1500er
Die Kommunikation passt soweit, alles was bis 1 Byte groß ist kommt auf der Kopfsteuerung auch richtig an und wird sauber in den DB gepackt.
Das Abgreifen dieser Eingangsdaten geschieht in der Kopfsteuerung Indirekt in AWL und eben auch mit Any-Pointern.
Ich habe das Gefühl als würde der Zugriff jetzt anders sein oder Low und High Byte getauscht.
Vlt mag sich ja jemand der sich mit den ANY-Pointern auskennt zu diesem alten Post äußern und mir helfen. Dann würde ich einen Screenshot des Netzwerks einfügen.

Kann ggf. das Problem mit optimiert nicht optimiert sein ^^

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe das Gefühl als würde der Zugriff jetzt anders sein oder Low und High Byte getauscht.

Kannst du dein Gefühl mal etwas genauer beschreiben? Was genau geht nicht so wie du es erwartest?
ANY-Pointer sind in der S7-1500 genau wie in der S7-300 aufgebaut, funktionieren allerdings nicht mit "optimiertem" Speicher

 

[psu]

Kann ggf. das Problem mit optimiert nicht optimiert sein ^^

Das glaube ich bald nicht, da auf der 1500er ein migriertes Projekt mit extra nicht optimieren DB‘s läuft.
Darauf hatte ich geachtet, da ich schonmal darüber gestolpert bin.

Ich habe das Problem auch nur bei einem DINT.
Alles was maximal so groß wie ein Byte ist, wird sauber abgelegt im DB auf der Controller Seite.

Mich wundert es eben auch dass die AusgangsPeripherie auf 1500 und eingangsperipherie auf der 319 deckungsgleich ist. Daher muss es ja etwas mit diesem scheiß any Pointer und indirekten Zugriffen zutun haben….

 

[Rabi]

Kannst du eventuell einmal einen Codeausschnitt zeigen?
Dann wäre es vermutlich etwas einfacher dem Fehler auf den Grund zu gehen.

Wie genau wird hier miteinander kommuniziert?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anstatt Gefühlsausbrüche könntest du hier einfach mal deine Fakten präsentieren, dann hätten wir bestimmt schon die Erklärung und eine Lösung
Also: wie sieht dein Code aus? Was funktioniert nicht wie erwartet? Was erwartest du? Was passiert tatsächlich?

 

[NBerger]

Hast auch dran gedacht das die 319 eigendlich eine 400'er ist, also auch 4 Accus hat?

 

[312C]

Hast auch dran gedacht das die 319 eigendlich eine 400'er ist, also auch 4 Accus hat?

Das gilt meines Wissens nach für die (längst abgekündigte) 318-2 DP. Die 319er verhalten sich wie die kleineren 300er

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast auch dran gedacht das die 319 eigendlich eine 400'er ist, also auch 4 Accus hat?

Das war die 318-2 (6ES7318-2AJ00-0AB0), nicht die 319.

 

[psu]

Anstatt Gefühlsausbrüche könntest du hier einfach mal deine Fakten präsentieren, dann hätten wir bestimmt schon die Erklärung und eine Lösung
Also: wie sieht dein Code aus? Was funktioniert nicht wie erwartet? Was erwartest du? Was passiert tatsächlich?

Sehr gerne doch...
Und entschuldigt bitte den Gefühlsausbruch, so eine IBN kann strapazieren.


Kurz zu dem was passieren müsste bzw zum genaueren Aufbau:
Ich habe als eine Art Leitsteuerung eine 319F (6ES7 307-1EA01-0AA0).
An dieser sind 75 I-Devices über eine IWlan Verbindung mit Siemens Scalance Geräten angebunden. Die 75 Device-Steuerungen waren bisher ausschließlich IM151-8F (6ES7 151-8FB01-0AB0). Von diesen 75 Device-Steuerungen wurde eine durch eine ET200SP 1514F CPU ersetzt.
Die Devices tauschen jeweils sowohl F-Signale mit dem Controller aus als auch 40Bytes (beide Richtungen) Applikationsdaten.
Hinter diesen 40 Bytes verbirgt sich sozusagen ein DB, welcher ebenfalls 40 Bytes groß ist und verschiedene, für die Leitsteuerung relevante, Daten enthält, welche ich zyklisch füttere und anschließend auf meine Ausgangsdaten schreibe welche an die Leitsteuerung geschickt werden.

Angefügt habe ich euch einmal sowohl den DB welchen ich dann in angefügter Stelle rausschreibe und die Gegenseite auf der Kopfsteuerung, wo dies verarbeitet wird.
Drum herum gibt es auf der Kopfseite noch ein paar Netzwerke, diese dienen Entweder dem Abfangen von möglichen Programmierfehlern oder sind für das Watchdog handling zuständig. Kommt dieser in bestimmten abständen nicht, wird der DB auf Null geschrieben. Also nicht weiter relevant. Das funktioniert auch weiterhin Fehlersicher.

Jetzt zum Problem:
Ich schicke dort eine Position in Form eines DINT nach oben. Es ist auch der einzige Wert der größer als ein Byte ist.

Dieser wird in der Kopfsteuerung mit einem Dummywert im entsprechenden DB belegt und eben nicht mit dem Wert welchen ich von unten rausschicke. Aus- und Eingangsperipheriedaten sind allerdings identisch, daran kann es also nicht liegen.
Das Problem habe ich nur mit der 1500er Steuerung. Allerdings ist dort alles so aufgebaut wie bei den "Bestandssteuerungen".
Ich finde weder heraus wo dieser ominöse Dummy-Wert herkommt, noch warum ich bei der neuen Steuerung die Probleme habe dass das was größer als ein Byte ist, scheinbar nicht sauber verarbeitet wird.
Alle anderen Werte/Bits und Bytes die ich mitgebe, kommen korrekt an und werden auch sauber im Ziel-DB der Kopfsteuerung abgelegt.

 

[DeltaMikeAir]

Ich habe als eine Art Leitsteuerung eine 319F (6ES7 307-1EA01-0AA0).

6ES7307... ist ein 24V Netzteil.
Du meinst wohl 6ES7319-3FL00 oder 01

 

[psu]

Zuviel Werbung?
-> Hier kostenlos registrieren

6ES7307... ist ein 24V Netzteil.
Du meinst wohl 6ES7319-3FL00 oder 01

Jap, 6ES7319-3FL01 meine ich… Bin beim kopieren in der Zeile verrutscht…

 

[PN/DP]

Jetzt zum Problem:
Ich schicke dort eine Position in Form eines DINT nach oben. Es ist auch der einzige Wert der größer als ein Byte ist.

Meinst du den DInt "Position" an Offset 12.0 ? Da sind auch noch weitere Int und DInt in dem DB. Kommen die auch falsch an?

Dieser wird in der Kopfsteuerung mit einem Dummywert im entsprechenden DB belegt und eben nicht mit dem Wert welchen ich von unten rausschicke. Aus- und Eingangsperipheriedaten sind allerdings identisch, daran kann es also nicht liegen.

Also in den E-Adressen kommen die Daten noch korrekt an? Erst in dem Ziel-DB ist ein oder mehrere Werte falsch? Ändert sich der falsche Wert auch mal?
Wenn du vor dem kopieren aus den E-Adressen in den Ziel-DB (vor dem Kopier-Code) den Position-Wert auf 0 schreibst, was steht direkt nach dem kopieren drin? Schreibe mal die Werte direkt vorher und nachher weg zum vergleichen.
Wie kommst du auf das Gefühl von "Bytes vertauscht"? Hast du mal ein Beispiel für den Wert aus der E-Adresse und den falschen Wert im DB?

Bei den AWL-Codes "Einlesen der Istwerte" und "Schreiben der Istwerte in Ziel-DB":
Wo ist T_Istwerte deklariert? Wird der ANY da immer vor der Verwendung korrekt reingeschrieben?
Wird nach den BLKMOV der Rückgabewert auch mal ausgewertet oder immer verworfen/ignoriert?

Ich vermute, dass ein anderer Programmteil später mit falschem/ungewollten Pointer indirekt den Wert im "ZielDB".DBD12 überschreibt, oder vielleicht auch direkt auf "ZielDB".DBD12 ? Die Programmstelle sollte man mit PLCSIM und nach und nach deaktivieren von Codeteilen finden können, falls nicht über die Querverweise zu finden.

 

[psu]

Meinst du den DInt "Position" an Offset 12.0 ? Da sind auch noch weitere Int und DInt in dem DB. Kommen die auch falsch an?

Ja, genau. Ich meine den Dint „Position“.
Der eine weitere Dint wird nicht benötigt und ist nur Reserve, also immer null.
Die Integer werden vom Zahlenwert nur bis zum bytebereich beschrieben, diese Werte kommen richtig an.

Also in den E-Adressen kommen die Daten noch korrekt an? Erst in dem Ziel-DB ist ein oder mehrere Werte falsch? Ändert sich der falsche Wert auch mal?
Wenn du vor dem kopieren aus den E-Adressen in den Ziel-DB (vor dem Kopier-Code) den Position-Wert auf 0 schreibst, was steht direkt nach dem kopieren drin? Schreibe mal die Werte direkt vorher und nachher weg zum vergleichen.
Wie kommst du auf das Gefühl von "Bytes vertauscht"? Hast du mal ein Beispiel für den Wert aus der E-Adresse und den falschen Wert im DB?

Ja, die E-Adressen sind wie gesagt noch korrekt. Im Ziel-DB steht immer der gleiche Wert drin, eine Art Dummy-Wert.
Meine Vermutung kommt durch den dummy wert, der Wert scheint in dem Moment nicht plausibel zu sein und wir von irgendwo überschrieben.

Bei den AWL-Codes "Einlesen der Istwerte" und "Schreiben der Istwerte in Ziel-DB":
Wo ist T_Istwerte deklariert? Wird der ANY da immer vor der Verwendung korrekt reingeschrieben?
Wird nach den BLKMOV der Rückgabewert auch mal ausgewertet oder immer verworfen/ignoriert?

T_Istwerte ist als Lokale in dem Baustein deklariert.
Der rückgabewert wird, zumindest dort, nicht ausgewertet.
Ein Querverweis führt durch diese super übersichtliche und verständliche kacke leider auch ins Leere…

Ich vermute, dass ein anderer Programmteil später mit falschem/ungewollten Pointer indirekt den Wert im "ZielDB".DBD12 überschreibt, oder vielleicht auch direkt auf "ZielDB".DBD12 ? Die Programmstelle sollte man mit PLCSIM und nach und nach deaktivieren von Codeteilen finden können, falls nicht über die Querverweise zu finden.

Deine Vermutung könnte durchaus auch stimmen, da war ich auch schon.
Allerdings ergibt die Querverweissuche nichts.
PLCSIM ist ein gutes Stichwort, damit werde ich mich wohl heute mal beschäftigen…

Ich komme eigentlich aus der Beckhoffwelt und durfte wenn es Siemens war bisher immer neu im TIA-Portal unterwegs sein, um Step7 und vor allem AWL mit solchen schweinereien bin ich drum herum gekommen. Jetzt muss ich aber…