Step 7 Zusammenhang Temporär-Variablen und Ausgangsbereich (A)

thomasgull · 5 Oktober 2018

Hallo zusammen

Ich habe da eine Frage in der ihr mir vielleicht Auskunft geben könnt:

Wir hatten eine Anlage in der in 2 Schritten Erweiterungen getätigt wurden:

In einem FC wurde eine temporäre Variable benutzt im Bereich L 1.1

in einer Umprogrammierung ist dann der Fehler passiert

es wurde ein Sprung eingefügt.

Leider wurde dabei übersehen dass die Temporäre Variable während dem Sprung nicht mehr bearbeitet wurde und so undefiniert war.

Die Anlage hat nun 1 Jahr so funktioniert bis in 2 Bausteinen davor Anpassungen gemacht wurden:

der FB wurde erweitert und ein PN Knoten eingefügt.
Nun ist es so dass wen der Ausgang A4.1 gesetzt wird auch die Temporäre Variable im darauffolgenden FC22 auf "True" gesetzt wird
Was ist der Zusammenhang von einem Ausgang hier 4.1 mit einer temporären Variable?
Mir wäre noch klar dass eine Andere temporäre aus einem Vorhergehenden Prozess dazwischen spielen könnte das war aber nicht der fall, sondern es ist nur der Ausgang 4.1 haben wir durch diverse Test so ermittelt.
was ich noch nachgeforscht habe ist dass das PEB und PAB im selben Speicherbereich liegen in der Hardware wie die Temporären-Variablen, nur dachte ich dass das diese nicht überschneidend sein sollten da das PAB und PEB ja über das ganze Programm Konsistent sein müssen.

hat da jemand eine Erklärung wie der A4.1 die temporäre Variable L1.1 in diesem FC22 beeinflusst.

Was mir klar ist Temporäre müssen versorgt werden, hat diese Beispiel gezeigt,

Abfolge:

OB1
- FBxx mit dem Ausgang A4.1
- FByy
- FC22 mit der Temporär-Variable1.1

grüsse

Thomas

Thomas_v2.1 · 5 Oktober 2018

Vermutlich ist nicht direkt die Zuweisung auf den Ausgang dafür verantwortlich, sondern eine wie auch immer damit zusammenhängende Beeinflussung der Lokaldaten.
So wie bei FUP/KOP-Netzwerken Lokaldaten als Zwischenvariablen genutzt werden, gibt es diese Verwendung auch bei anderen Funktionen und Operationen die für dich nicht immer direkt sichtbar sind.

thomasgull · 5 Oktober 2018

Thomas_v2.1 schrieb:
Vermutlich ist nicht direkt die Zuweisung auf den Ausgang dafür verantwortlich, sondern eine wie auch immer damit zusammenhängende Beeinflussung der Lokaldaten.
So wie bei FUP/KOP-Netzwerken Lokaldaten als Zwischenvariablen genutzt werden, gibt es diese Verwendung auch bei anderen Funktionen und Operationen die für dich nicht immer direkt sichtbar sind.

OK nach Anmerkung:

1. Programmierung ist durchgängig in AWL
2. Neuster Versuch: wenn der Ausgang A4.1 irgendwo im Programmteil davor direkt im OB 1 aktiv gesetzt wird mit "S A4.1" dann tritt das Phänomen auch auf

Thomas_v2.1 · 5 Oktober 2018

Auch wenn du alles in AWL programmierst gibt es immer noch eine Ebene darunter die du nicht direkt sehen kannst.
Und auch da wird auf Lokaldaten zugegriffen, vor allem wird das bei der Parameterübergabe an Funktionen/Funktionsbausteine genutzt. Der Übersetzer verwendet dann die Adressen nach deiner letzten manuellen Deklaration in Temp-Bereich, oder auch Absolutzugriffe mit L x.y werden erkannt und dann die internen Zugriffe auf Speicherbereiche dahinter verschoben.

Thomas_v2.1 · 5 Oktober 2018

Mal ein einfaches Beispiel konstruiert. Im Screenshot wird aus einem FC ohne Variablendeklaration im Temp-Bereich ein weiterer FC aufgerufen.
Über indirekte Adressierung wird L0.0 auf False gesetzt. Nach Aufruf der Funktion hat L0.0 jedoch den Wert True, ohne dass ersichtlich ist warum.

PN/DP · 5 Oktober 2018

Das wird nicht direkt am A4.1 liegen, sondern der FC22 verwendet wohl zufällig den selben TEMP-Speicher den vorher der FBxx verwendet hat (oder einen Teil davon). Dann hat die uninitialisierte Variable L1.1 in FC22 den Wert, den der FBxx da hinterlassen hat.

Kann es sein, daß der FBxx den OUTPUT oder IN_OUT liest, an dem außen der A4.1 angeschlossen ist? Dann könnte ein externes Beeinflussen des A4.1 als Folge auch den internen Ablauf und die internen TEMP-Variablen des FBxx beeinflussen.

Harald

thomasgull · 5 Oktober 2018

Thomas_v2.1 schrieb:
Auch wenn du alles in AWL programmierst gibt es immer noch eine Ebene darunter die du nicht direkt sehen kannst.
Und auch da wird auf Lokaldaten zugegriffen, vor allem wird das bei der Parameterübergabe an Funktionen/Funktionsbausteine genutzt. Der Übersetzer verwendet dann die Adressen nach deiner letzten manuellen Deklaration in Temp-Bereich, oder auch Absolutzugriffe mit L x.y werden erkannt und dann die internen Zugriffe auf Speicherbereiche dahinter verschoben.

Ja sowas vermutete ich das Hintergrundaktivitäten laufen.

war nur Speziell dass es gerade der A-Bereich mit der Temp kreuzt.

So wie es aussieht ist das ganze in der SPS extrem Komplex mit den Zusammenhängen der Datenbereichen

man hat nie ausgelernt

danke

thomasgull · 5 Oktober 2018

Thomas_v2.1 schrieb:
Mal ein einfaches Beispiel konstruiert. Im Screenshot wird aus einem FC ohne Variablendeklaration im Temp-Bereich ein weiterer FC aufgerufen.
Über indirekte Adressierung wird L0.0 auf False gesetzt. Nach Aufruf der Funktion hat L0.0 jedoch den Wert True, ohne dass ersichtlich ist warum.

Was machst du intern im FC 101

wenn du da auch noch Indirekte Adressierung hast wäre dann der Inhalt von AR2 nicht mehr identisch nach dem Bausteinaufruf

den Inhalt von AR2 sehe ich auf dem Printscreen nicht

grüsse Thomas

Thomas_v2.1 · 5 Oktober 2018

thomasgull schrieb:
Was machst du intern im FC 101

wenn du da auch noch Indirekte Adressierung hast wäre dann der Inhalt von AR2 nicht mehr identisch nach dem Bausteinaufruf

Im FC101 wird nichts besonderes gemacht. Das liegt auch nicht am AR2, sondern am Call-Makro welches intern in zwei BLD und eine =Lx.y Anweisung aufgelöst wird (und noch etwas drumherum).
Das bekommst du aber nicht so ohne weiteres zu sehen.
Die Lokaldatenadresse die für dieses Makro verwendet wird, liegt immer hinter der letzten eigenen Verwendung. Damit der Übersetzer nicht mitbekommt dass ich mit dieser Adresse arbeite, muss ich das über indirekte Adressierung etwas verschleiern. Das dient aber nur dazu es für den Screenshot sichtbar zu machen, darum auch das SET vor dem Call-Aufruf.

Bei der Parameterübergabe gibt es noch mehr solche Dinge wo Any-Pointer im Temp-Bereich intern konstruiert werden.

Heinileini · 5 Oktober 2018

Oooops,
1) ". . . ohne Variablendeklaration im Temp-Bereich . . . wird . . . über indirekte Adressierung L0.0 . . ."
und
2) ". . . uninitialisierte Variable . . ."
das sind ja schon zwei bis drei grobe Schnitzer, die man tunlichst nicht den Vorbildern Siemens oder Fanuc nachmachen sollte!

Wenn man das BetriebsSystem überlistet, darf man sich nicht wundern!
Wenn man jenseits des deklarierten Bereichs in den Stack greift, also im Wirklichkeit in einen Bereich, der nicht mehr zum entsprechenden Baustein gehört, dann geht das - ganz wörtlich - daneben.
Wenn der Programmierer nicht für eine Initialisierung sorgt, obwohl der Compiler sich auch nicht darum kümmert . . . nun gut, das kann passieren, darf es aber nicht ;o)

Thomas_v2.1 · 5 Oktober 2018

Heinileini schrieb:
Oooops,
1) ". . . ohne Variablendeklaration im Temp-Bereich . . . wird . . . über indirekte Adressierung L0.0 . . ."
und
2) ". . . uninitialisierte Variable . . ."
das sind ja schon zwei bis drei grobe Schnitzer, die man tunlichst nicht den Vorbildern Siemens oder Fanuc nachmachen sollte!

Dass es ein Programmierfehler ist wurde doch schon lange erkannt. Die Frage war doch, warum das Programm trotz dieses Fehlers so lange lief (zufälligerweise richtig) und dann nach einer kleinen Änderung die damit augenscheinlich nichts zu tun hat, auf mal das Problem zutage tritt.
Und das liegt u.a. daran, dass da noch mehr auf den Lokaldaten passiert als das was man im AWL-Editor sehen kann.

thomasgull · 5 Oktober 2018

wieder was neues gelernt

Danke

thomasgull · 5 Oktober 2018

Thomas_v2.1 schrieb:
Dass es ein Programmierfehler ist wurde doch schon lange erkannt. Die Frage war doch, warum das Programm trotz dieses Fehlers so lange lief (zufälligerweise richtig) und dann nach einer kleinen Änderung die damit augenscheinlich nichts zu tun hat, auf mal das Problem zutage tritt.
Und das liegt u.a. daran, dass da noch mehr auf den Lokaldaten passiert als das was man im AWL-Editor sehen kann.

die Variable wurde auch noch deklarierte, aber dasselbe Problem.

und das mit dem Initialisieren wurde beim Einbau vom Sprung übersehen

Gruss Thomas

Heinileini · 6 Oktober 2018

Thomas_v2.1 schrieb:
. . . Die Frage war doch, warum das Programm trotz dieses Fehlers so lange lief (zufälligerweise richtig) und dann nach einer kleinen Änderung die damit augenscheinlich nichts zu tun hat, auf mal das Problem zutage tritt. . . .

Hmmm. Das ist doch ein ganz normales Phänomen, wenn die Initialisierung geschlabbert wird. Man fragt eine Variable ab und lässt sich überraschen, welchen Inhalt sie hat.
Dass oft erst nach Jahren plötzlich ein verändertes Verhalten bemerkt wird, mag verblüffend erscheinen, ist es aber nicht.
Das ist ja das gemeine an solchen Fehlern, dass kein nachvollziehbarer Zusammenhang zwischen der vermeintlichen Ursache und der Wirkung besteht.
Die vermeintliche Ursache ist z.B. eine Änderung "irgendwo" in der SW, während man die wirkliche Ursache vor Augen hat und sie trotzdem so leicht überlesen kann.
Richtig gemein wird es, wenn sich die tatsächliche Ursache in einem Baustein versteckt, der vor neugierigen Blicken geschützt ist.

thomasgull schrieb:
die Variable wurde auch noch deklarierte, aber dasselbe Problem.
und das mit dem Initialisieren wurde beim Einbau vom Sprung übersehen

Aha!

Thomas_v2.1 schrieb:
. . . Und das liegt u.a. daran, dass da noch mehr auf den Lokaldaten passiert als das was man im AWL-Editor sehen kann. . . .

Da muss nicht noch mehr passieren - allein das Vergessen der Initialisierung führt schon zu "zauberhaften" Effekten.

thomasgull · 6 Oktober 2018

Ja alles Klar

Mal weitere Frage:

Wie passiert mit allen Zugriffen auf Merker , E, A und IDB? passieren die direkt aus dem Prozessor auf diese Bereiche oder lädt der Prozess diese in einen Arbeitsbereich und bearbeitet sie und schreibt sie am Ende zurück?

Heinileini · 6 Oktober 2018

Mit ArbeitsBereich meinst Du vermutlich nicht den Akku und die Register des Prozessors.
Und am Ende von was soll das Zurückschreiben stattfinden? Am Ende eines jeden PLC-Zyklus?
ProzessAbbilder der E und A sind Dir ein Begriff, denke ich.
Ich will nicht behaupten, dass der AdressRaum der heute verwendeten Prozessoren von Intel und "kompatiblen" seit rund 40 Jahren unverändert bei mickrigen 64 KB geblieben ist. Ich hoffe (weiss aber nicht wirklich), dass z.B. 64-Bit-Prozessoren auch ohne MemoryManagementGedöns schon deutlich mehr adressieren können.
Wie sieht es aus mit CacheSpeicher in SPS? Weiss ich auch nicht.
Auch bei nicht "PC-basierten" SPS wird letztendlich PC-Technik im weiteren Sinne verbaut.
Die Bereiche "zyklische SPS" und Windows sowie HochSprachenOrientierung haben längst angefangen, zusammenzuwachsen.
Aber dennoch bleiben die SchwerPunkte bei zyklischen SPS und RealTimeAnwendungen andere als im Rest der digitalen Welt, allenfalls mit GeräteTreibern vergleichbar bzw. mit der Software, die längst in die µC der Geräte ausgelagert wurde.
Ich denke, dass in einer SPS nicht mehr Daten zwischen einem "ArbeitsBereich" und "abgelegeneren" Bereichen hin- und hergeschaufelt werden, als unbedingt nötig.
Warum ist das überhaupt für Dich relevant?

PN/DP · 6 Oktober 2018

thomasgull schrieb:
bearbeitet sie und schreibt sie am Ende zurück?

Wie meinst Du "am Ende"?
Merker, E, A, DB, IDB sind für das SPS-Anwenderprogramm globaler Speicher auf den per Multitasking zugegriffen werden kann. Die Programmabarbeitung in einem OB (Task) kann durch andere OB unterbrochen werden, die anderen OB können ebenfalls auf die globalen Speicherbereiche zugreifen. Daher verbietet es sich, auf Ebene des Anwenderprogramms mit temporären Kopien von Speicherteilen zu arbeiten und "später" ("am Ende") wieder zurückzuschreiben. Wie genau Speicherzugriffe des Prozessors aussehen und ob da vielleicht Caches oder Auslagerungsspeicher verwendet werden ist nicht relevant. Selbst wenn (wie z.B. in Windows) im Hintergrund Speicherbereiche zeitweise auf eine Speicherkarte ausgelagert würden, dann müsste das so transparent passieren, daß das Anwenderprogramm davon nichts mitbekommt - daß es nicht relevant ist.

Harald

Step 7 Zusammenhang Temporär-Variablen und Ausgangsbereich (A)

thomasgull

Level-2

Thomas_v2.1

Level-1

thomasgull

Level-2

Thomas_v2.1

Level-1

Thomas_v2.1

Level-1

Anhänge

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

thomasgull

Level-2

thomasgull

Level-2

Thomas_v2.1

Level-1

Heinileini

Level-3

Thomas_v2.1

Level-1

thomasgull

Level-2

thomasgull

Level-2

Heinileini

Level-3

thomasgull

Level-2

Heinileini

Level-3

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

Similar threads

Wir schützen deine Privatsphäre