direkter Lokaldatenzugriff

[sunny22]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen,

ich hab hier ein S7 Programm und mich würde mal eure Meinung dazu interessieren.
Es wird dort wild über direkte Adressen auf Lokaldaten zugegriffen ohne diese in der Temp-Deklaration zu reservieren.
Kann man das so machen? Sollte man das so machen? Kann sich das auf Lokaldaten anderer Bausteine auswirken?

Grüße Oliver

 

[Larry Laffer]

Wie du siehst kann man das so machen ... 8)
Es wird sich so erstmal nicht auf andere Basusteine auswirken ...
Ich persönlich würde es so nicht haben wollen (es strickt verbieten !!!) - es gibt ganz sicher eine Möglichkeit, das Ganze auch "vernünftig" hinzubekommen ...

Gruß
Larry

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn der Programmierer schon nicht weiß wie er den TEMP-Speicher symbolisch ansprechen kann (oder keine Lust dazu hat) dann sollte er wenigstens für die Kollegen den verwendeten Speicherbereich irgendwie markieren/reservieren/deklarieren, z.B. als BYTE-Array mit dem Kommentar "Achtung! Nicht verschieben! Wird direkt adressiert!"

Anscheinend hat er sich bei den LB-Zugriffen auch noch verzählt, weil LB8 und LB9 treffen den Speicherbereich der Variable DBZVT. Oder ist da schon jemand unbedarft drauf 'reingefallen und hat die Variable erst nach dem Kunstprojekt angelegt? Oder das Programm soll wirklich so saumäßig im Speicher 'rumschreiben?

Zum Glück geht solches direktes absolut adressiertes 'rumschmieren im TEMP-Speicher nur für Adressen ab dem Beginn des Baustein-eigenen TEMP-Bereiches, so daß kein aktuell belegter Speicher anderer Bausteine damit beeinflusst wird.

Harald

 

[Banana Joe]

Was für ein geniales Konstrukt!

Kann man das so machen? Sicherlich (es scheint ja zu funktionieren).

Sollte man das so machen? Sicherlich nicht.

Jeder der hier noch mal nachträglich was am Lokaldatenbereich ändert und nicht darauf achtet das weiter unten Wild durch die Gegend gev*gelt wird, wird ziemlich ordentlich auf die Schnauze fallen. Wenn man seine Kollegen hasst ist das natürlich ein probates Mittel, um dies zum Ausdruck zu bringen.

 

[ducati]

Ja, man kann halt absolut auf alles mögliche zugreifen.

Bei E/As, Merkern und Global-DBs rechnet man damit. Bei Tempvariablen/Lokaldaten eher nicht.

Bei absoluten Zugriffen auf Instanz-DBs ists auch schon unschön, falls mal jemand ne Statische Variable hinzufügt.

Was machen die hier: Die wollen die Bytes in nem Doppelwort drehen. Abgesehn davon, dass es nen AWL-Befehl dafür gibt, gibts auch sonst schönere Varianten, um an die Bytes in nem Doppelwort zuzugreifen...

Und die Überschneidung mit ner deklarierten Variablen ist ganz doof...

Naja, irgendwo kommt der Code her, vermutlich aus nem Forum kopiert


Ich hab so Code auch schon gesehen... Hab auch schon Rettung von Lokaldaten über den Bausteinaufruf hinaus gesehen, da denkst dann, was treibt der da wenn er Lokaldaten setzt und rücksetzt...

Also neu würd ich den Zugriff auf Lokaldaten auch sicher nicht mehr machen... Wenn man sich den AWL-Code der aus KOP/FUP/SCL/CFC entsteht mal anschaut, wird da aber auch seeeehr viel mit Lokaldaten hantiert...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man sich den AWL-Code der aus KOP/FUP/SCL/CFC entsteht mal anschaut, wird da aber auch seeeehr viel mit Lokaldaten hantiert...

Da macht das aber ein Compiler, der weiß was er tut und die Übersicht behält, welche Adressen er gerade belegt, und das Ganze bei späteren Programmänderungen auch verschieben kann. Wenn ein Programmierer das tut, dann weiß der nach ein paar Wochen nichts mehr wie das zusammenhängt und sein Update/Nachfolger erst recht nicht.

Harald

 

[NBerger]

Zum Glück geht solches direktes absolut adressiertes 'rumschmieren im TEMP-Speicher nur für Adressen ab dem Beginn des Baustein-eigenen TEMP-Bereiches, so daß kein aktuell belegter Speicher anderer Bausteine damit beeinflusst wird.

So ganz stimmt das nicht: Wird dieser Baustein unterbrochen so wird der Tempstack um die bekannten/deklarierten Variablen erhöt, für die Tempvariablen des unterbrechenden Bausteins.
Der kann nun fleißig Werte ändern die nach Rückkehr in diesen Baustein dann verändert/verfälscht sind.

Beim Suchen solcher Fehler kommt freude auf.

 

[ducati]

So ganz stimmt das nicht: Wird dieser Baustein unterbrochen so wird der Tempstack um die bekannten/deklarierten Variablen erhöt, für die Tempvariablen des unterbrechenden Bausteins.
Der kann nun fleißig Werte ändern die nach Rückkehr in diesen Baustein dann verändert/verfälscht sind.

Beim Suchen solcher Fehler kommt freude auf.

Hmm, ich hätt gedacht, alle Interrupt-OBs haben nen eigenen Lokaldatenstack...

Aber gut, so genau hab ich das noch nie ausgetestet...

Oder meinst Du, in nem FC wird nen weiterer FC aufgerufen? Da wüsst ich jetzt auch nicht, wie das gehändelt wird.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zum Glück geht solches direktes absolut adressiertes 'rumschmieren im TEMP-Speicher nur für Adressen ab dem Beginn des Baustein-eigenen TEMP-Bereiches, so daß kein aktuell belegter Speicher anderer Bausteine damit beeinflusst wird.

So ganz stimmt das nicht: Wird dieser Baustein unterbrochen so wird der Tempstack um die bekannten/deklarierten Variablen erhöt, für die Tempvariablen des unterbrechenden Bausteins.
Der kann nun fleißig Werte ändern die nach Rückkehr in diesen Baustein dann verändert/verfälscht sind.

Beim Suchen solcher Fehler kommt freude auf.

So stimmt das aber nicht. Nach meiner Erfahrung hat jede OB-Ebene (Task) einen ganz eigenen TEMP-Stack, was wie man sieht ganz viel Sinn macht. "Solche" Fehler braucht man nicht suchen, weil die gibt es gar nicht. Versuche doch mal absichtlich, irgendwie versteckt/verpointert in höheren TEMP-Bereich zuzugreifen, und schau, ob Du Rückstände von irgendwelchen unterbrechenden Bausteinen findest
Oder meinst Du Bausteine, die durch den Baustein selber aufgerufen werden? Direkte Zugriffe ala "T LB nn" werden vom Compiler zuverlässig erkannt und der Stack für den aufgerufenen Baustein beginnt erst hinter diesen Adressen nn, egal wieviel TEMP-Speicher offiziell mit Variablen deklariert oder nicht deklariert ist. (ist zumindest in Step7 classic so, ob TIA auch so schlau ist weiß ich nicht)

Gehört zugreifen in nicht-deklarierten TEMP-Speicher zu Deinem Programmierstil und Du bekommst nun unerklärliche Probleme bei TIA? Zeig uns doch mal ein Stück Beispielcode, wo das zutrifft, was Du hier verkündest. Sollte ja nicht schwer sein, wo Du doch schon Freude beim Suchen solcher Fehler hattest...

Harald

 

[Thomas_v2.1]

Hmm, ich hätt gedacht, alle Interrupt-OBs haben nen eigenen Lokaldatenstack...

Aber gut, so genau hab ich das noch nie ausgetestet...

Oder meinst Du, in nem FC wird nen weiterer FC aufgerufen? Da wüsst ich jetzt auch nicht, wie das gehändelt wird.

Weil das was NBerger geschrieben hat auch nicht stimmt. Die SPS prüft am Code beim Hochladen am Code deine Lokaldatenzugriffe und legt den Lokaldatenbereich für den Baustein danach aus, die Deklaration kennt die SPS auch überhaupt nicht.

Das kann man selber überprüfen, indem man versucht einen Baustein mit einem Zugriff auf einen zu großen Lokaldatenbereich (z.B. LW 2050 bei kleinen 300ern) in die SPS hochzuladen, was diese dann ablehnt.
Wenn man die SPS in Stopp schickt, dann kann man sich zudem über den Baugruppenzustand der CPU die L-Stacks der jeweiligen Bausteine anzeigen lassen. Aus der Anzeige ist ersichtlich, dass die Größe des Lokaldatenbereichs eines Bausteins anhand des Codes bestimmt wird. Die dort angezeigten Größen der L-Stacks je Baustein werden von der SPS gemeldet und nicht von Step7 aus dem Code generiert.

Da kommt mir gerade die Idee, dass man evtl. mit etwas indirekter Adressierung unter dem Radar auf den L-Stack von ganz anderen Bausteinen zugreifen könnte, wenn das nicht angefangen wird.

 

[JSEngineering]

Da macht das aber ein Compiler, der weiß was er tut und die Übersicht behält, welche Adressen er gerade belegt, und das Ganze bei späteren Programmänderungen auch verschieben kann. Wenn ein Programmierer das tut, dann weiß der nach ein paar Wochen nichts mehr wie das zusammenhängt und sein Update/Nachfolger erst recht nicht.

Harald

Vielleicht ist das ja mal aus einer CPU "gerettet" worden und ist garnicht von einem Menschen verzapft....

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe so etwas schon unfreiwillig gesehen. Einer programmiert in FUP und hat die "Typüberprüfung von Operanden" ausgeschaltet und programmiert da etwas, was mit der eingeschaltetet Prüfung nicht erlaubt wäre. Der nächste öffnet den Baustein mit eingeschalteter Überprüfung. Bei ihm wird nun dieses Netzwerk dann als AWL dargestellt, der Rest im FB aber wie gehabt in FUP. Dieses AWL-Netzwerk enthält je nach Programmierung absolute Adressen aus dem Temp-Bereich. Wenn nun der zweite Bearbeiter temporäre Variablen deklariert, sind diese aber auf den selben Adressen wie die vom AWL-Netzwerk, ja nach Programmierreihenfolge der verwendeten Temp-Variablen kommt es jetzt zu ungewollten Ergebnissen. Ich habe mir angewöhnt, die Typprüfung bei eigenen Projekten eingeschaltet zu lassen um "saubereren" Code zu schreiben. Wenn ich fremde Projekte zu bearbeiten habe, gehe ich dann als erstes den kompletten Code durch und prüfe alle Netzwerke ob sie als AWL abgebildet werden, alternativ schalte ich die Typprüfung temporär für das eine Projekt ab.

 

[Oberchefe]

Ergänzung: es kommt beim Anlegen der Temp-Variablen zwar eine Warnung, die wird aber erfahrungsgemäß oft überlesen.

 

[PN/DP]

Seit Step7 V5.5 SP4 HF? Anfang 2016 ist die "Typüberprüfung von Operanden" in KOP/FUP dauerhaft deaktiviert und kann nicht mehr aktiviert werden. Feld Typprüfung von Operanden ausgegraut.

Harald

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da kommt mir gerade die Idee, dass man evtl. mit etwas indirekter Adressierung unter dem Radar auf den L-Stack von ganz anderen Bausteinen zugreifen könnte, wenn das nicht angefangen wird.

Das geht übrigens nicht, die SPS geht in Stopp wenn indirekt auf einen Bereich außerhalb der reservierten Lokaldaten zugegriffen wird. Daran kann man auch sehen, dass die SPS den hochgeladenen Code analysiert und danach den Lokaldatenbereich für den Baustein auslegt.

Ein FC ohne Variablendeklaration und mit diesem Code geht in Stopp:

      L     W#16#AFFE
      T     LW   100

      L     P#104.0
      LAR1  
      L     W#16#BABE
      T     LW [AR1,P#0.0]

Mit P#102.0 funktioniert es einwandfrei.

 

[PN/DP]

Vielleicht ist das ja mal aus einer CPU "gerettet" worden und ist garnicht von einem Menschen verzapft....

Glaube ich nicht. So wie der Code aussieht ist der nicht von einem Compiler automatisch erzeugt. So stupider Code wird nur von Menschen verzapft.
Höchstens daß vielleicht jemand nachträglich die TEMP-Deklarationen gelöscht oder geändert hat - aber auch das hätte ein Mensch gemacht.

Harald

 

[Thomas_v2.1]

Ich würde mich nicht davon freisprechen wollen, dass ich nicht schon einmal so etwas geschrieben hätte ;-)

Vermutlich lief es so ab:
Sauber strukturierter und dokumentierter Code wurde im Büro anhand der Dokumentation vorbereitet.
Bei der Inbetriebnahme war mal wieder alles ganz anders, vermutlich die leidige Endianess.
Es wurde getestet warum die Werte nicht passen, die Bytes wurden beim Herumprobieren an einem Wert so lange gedreht bis sie passen.
Ein funktionierendes Schema wurde gefunden, und des Programmierers flinke Finger haben selbiges gleich auf alle Werte ausgerollt.
Doku und Schick machen kommt später in einer ruhigen Minute...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da kommt mir gerade die Idee, dass man evtl. mit etwas indirekter Adressierung unter dem Radar auf den L-Stack von ganz anderen Bausteinen zugreifen könnte, wenn das nicht angefangen wird.

Das geht übrigens nicht, die SPS geht in Stopp wenn indirekt auf einen Bereich außerhalb der reservierten Lokaldaten zugegriffen wird.

Ein kleines bisschen kann man auf Lokaldaten anderer Bausteine zugreifen, nämlich indirekt auf die Lokaldaten des aufrufenden Bausteins (Vorgänger-Lokaldaten), aber auch nur in der Größe wie die da eingestellt sind (wenn ich mich recht erinnere, was ich mal getestet hatte). Da würde ich aber sagen, daß sowas eher nicht aus Versehen passiert.

Harald

 

[ducati]

Interessantes Thema
Das einzige Problem was ich immer wieder mit Lokaldaten an verschiedenen Anlagen habe ist, dass gelesen wird ohne vorher zu schreiben oder dass jemand setzen/rücksetzen will. Manchmal aus Versehen manchmal aus Unwissenheit...
Ob jetzt absolute Adressierung "böse" ist, kann man geteilter Meinung sein.
Man wird sehen, wie in 20 Jahren über die heutigen "Hochsprachenkonstrukte" in der SPS gedacht wird.
Jedenfalls Temp.-Variablen funktionieren in der 300/400er auch mit Interrupt-OBs und FC/FB Aufrufen, seh ich auch so.
Bei 1200/1500 kann mans wenigstens hoffen

Nichtsdestotrotz versuch ich schon immer symbolisch zu programmieren und so dass man über Querverweise alles findet.

Aber wie Thomas schon schreibt, oft zählt nicht Schönheit auf der Baustelle sondern Zeit und Geld. Und ganz ganz vielen ist Schönheit auch komplett egal...

Achja, hatte da auch schon Kollegen die absolute Adressierung und Pointerrei als Lebenseinstellung gesehen haben, erstens weil der Code kürzer/schneller sei und zweitens weil sie allen anderen Beweisen wollten, dass sie pointern können

 

[ducati]

Hmm, da fällt mir nen neuer Programmierwettbewerb ein. Eine Aufgabe, SPS incl. HMI und verschiedene Programmierstile. Am Ende ne Abstimmung, welche Lösung am einfachsten zu verstehen ist und wo an den Lösungen der anderen eine einfache kleine Änderung vorzunehmen ist.