Label interessantes nicht nachvollziehbares Verhalten

vollmi

Level-3
Beiträge
5.433
Reaktionspunkte
1.409
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen.

Ich hatte gestern auf der Baustelle ein interessantes Verhalten in einem AWL Programm

Ich hab drei Bausteinaufrufe hintereinander

Also ein CALL FB1 dann ein CALL FB2 und danach ein CALL FB3

Jeweils mit Schnittstelle.

Der FB1 gibt mir einen REAL Wert aus. Den Ausgang beschalte ich mit LD0. LD0 kommt dann wiederum auf den Eingang von FB2 und an dessen ausgang kommt ein LD10 (ebenfalls REAL ausgabe) welcher wiederum an den Eingang des FB3 aufgeschaltet wird.

Nun soll der FB2 ein Skalierungsbaustein darstellen. Er skaliert also 0.0 - 100.0 nach 0.0 - 27000.0. Das machte er auch mehrere Dutzend male in dem Programm. Nur Hier nicht.

der Ausgang gibt immer 27000.0 auf den LD10 aus egal was am Eingang anliegt. Erneutes runterladen hat nichts gebracht. Danach hab ich gedacht ich ersetze die LD mal gegen MD200 und MD204. Und siehe da? Es funktioniert wie es sollte.

Also der Nachvollziehbarkeithalber nochmal die MD gegen LD ersetzt und was ist? Es funktioniert trotzdem?

Hat jemand eine ahnung wie sowas passieren kann?

mfG René
 
der lokaldatenstack wird willkürlich beschrieben ... jeder bausteinaufruf gibt ihn zum überschreiben frei ... besonders wenn du nur die adressen benutzt, die aber nicht in der bausteindeklaration reservierst...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja das schon. Aber die FBs folgten ja direkt hintereinander.

Also FB2 überschreibt den LD10 mit seinen daten, der FB3 liest ihn. Wenn später ein anderer baustein auch auf LD10 schreibt, kann mir das ja egal sein, sobald der Zyklus wieder beim FB2 ankommt überschreibt er ihn ja mit dem aktuellen Wert.

Oder hab ich da jetzt ein massives Verständnisproblem?
 
aber wie kanns denn nun zu dem verhalten kommen? Ich mein die Anlage war schon funktionierend in Betrieb und irgendwann hab ich gemerkt das die Heizung volle Kanne lief obwohl der Regler schon lange zurückgedreht hat.

Und warum funktionierts zuerst nicht, danach mit den Merkern schon und danach auch wieder mit den Lokaldaten?

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
der fehler ist nicht reproduzierbar, also nicht so ohne weiteres ... ist es mgl. dass da einer online einen bausteinaufruf eingefügt hat? oder ähnliche änderungen vorgenommen hat?

herausgefunden bis jetzt, habe ich: dass das erste (volle) bit nach der letzten lokalvariablen, also egal ob deklariert oder nicht, als puffer für bildoperatrionen vor dem bausteinaufruf benutzt wird. meine frage zielt darauf ab, ob diese anpassung bei online-änderungen auch durchgeführt wird. ich kann es grad nicht testen...
 
Eigentlich nicht. Ich ändere online kaum je etwas, normal wird offline programmiert und die Bausteine dann geladen.

Hm vermutlich bleibt mir jetzt nichts anderes übrig als mal abzuwarten ob sich das Verhalten wieder einmal zeigt. Aber bis jetzt ist mir noch nie abgeraten worden Lokaldaten zu verwenden. Mich würds jetzt ehrlich etwas nerven wenn ich stattdessen jeweils das Zeug in der Schnittstelle anlegen müsste um sicherzugehen dass auch wirklich alles so funktioniert wie angedacht.

Es ist alles in AWL programmiert.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ah, interessant:

die letzten doppelwörter wird quasi als schmierbereich verwendet.
beim FC aufruf ist es dieses ergebnis der nulloperation
beim FB aufruf wird da die speicherung des AR2 vorgenommen (die nullop/bildop speichert hier dann in dem nächsten (vollen) bit..)
 
Hm aber wenn ich doch z.B. LD10 an einer Schnittstelle verwende dürfte doch erst ab 14 wieder irgendwas für Interne Zwecke verwendet werden.

In welchen Unterlagen findet man denn überhaupt etwas über intern verwendete Speicherbereiche (Nullop und so)?

mfG René
 
Hm aber wenn ich doch z.B. LD10 an einer Schnittstelle verwende dürfte doch erst ab 14 wieder irgendwas für Interne Zwecke verwendet werden.

das halte ich für einen theoretischen wert!
normal ja, aber durch irgendeine übersetzungsmacke oder was auch immer, kann man sich eben wohl offensichtlich auch aufn arsch setzen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mal so allgemein find ich das eh mutig mit LD's werte zu übergeben in FB's rein die dort verarbeitet werden und dann wieder raus kommen. Denn die FB's rechnen ja auch intern

Viel spass bei der Fehlersuche wenn du nicht mehr da bist
 
wo liegt denn das problem wenn die FBs intern was weiterrechnen, die fbs haben ja mit den Lokaldaten des aufrufenden FBs nichts zu tun. Die kriegen ja nur die übergebenen Werte zu sehen? Liege ich da falsch?

Die Lokaldaten sind ja auch von der instanzierten Schnittstelle getrennt.

mfG René
 
Mal so allgemein find ich das eh mutig mit LD's werte zu übergeben in FB's rein die dort verarbeitet werden und dann wieder raus kommen. Denn die FB's rechnen ja auch intern

die theorie sagt, es würde funktionieren:

- wert wird an FB übergeben und damit in den I-DB geschrieben
- wert aus I-DB wird im FB verarbeitet
- verarbeiteter wert wird in den I-DB als out geschrieben
- nach BE wird der wert in den lokalen bereich des aufrufenden bausteins geschrieben

soweit die theorie :rolleyes:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der FB1 gibt mir einen REAL Wert aus. Den Ausgang beschalte ich mit LD0. LD0 kommt dann wiederum auf den Eingang von FB2 und an dessen ausgang kommt ein LD10 (ebenfalls REAL ausgabe) welcher wiederum an den Eingang des FB3 aufgeschaltet wird.

Nun soll der FB2 ein Skalierungsbaustein darstellen. Er skaliert also 0.0 - 100.0 nach 0.0 - 27000.0. Das machte er auch mehrere Dutzend male in dem Programm. Nur Hier nicht.
Hallo René,
mich würden jetzt mal zwei Punkte interessieren:
1. Bei den Dutzend male, bei denen es geht, werden da auch Lokaldaten verwendet?
2. Ist der Ausgang des FB ein OUT oder ein IN/OUT?
 
Das erste was ich ändern würde:
Keine Zugriffe auf LD ... sondern Lokaldaten symbolisch deklarieren und die verwenden.

Bei den KOP/FUP aufrufen werden ja auch nur die deklarierten LDs berücksichtigt,
möglicherweise ist das bei anderen Sachen auch so ...


Mfg
Manuel
 
Bei den KOP/FUP aufrufen werden ja auch nur die deklarierten LDs berücksichtigt,
möglicherweise ist das bei anderen Sachen auch so ...

das stimmt nicht, schau dir den MC7-code an ... es wird definitiv immer nach dem letzten verwendeten angefangen, wenn alles richtig übersetzt wurde...

ABER, du hast natürlich recht, deklariert ist schöner!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das stimmt nicht, schau dir den MC7-code an ... es wird definitiv immer nach dem letzten verwendeten angefangen, wenn alles richtig übersetzt wurde...

... nur wenn noch mal auf KOP/FUP mit anschliesenden Speichern umgeschalten wurde ...
Dafür brauch ich noch nicht mal den MC7-Code.

P.S. ist das jetzt irgendwie neu? Früher kam doch da immer eine Meldung, "wird bereits verwendet ..."

Mfg
Manuel
 
Guten Abend,

ist es nicht so, dass bei jedem neuem Bausteinaufruf die Lokaldaten neu beschrieben, bzw. verwendet werden können?
D.h: innerhalb eines Baustein's kann du Lx.x beliebig zuweisen und innerhalb abfragen.

Probleme entstehen bei:

Kolloision: bei einem Interrupt-Aufruf;


Oder: Adressierung? (was geschieht in den FC's)
sind diese multiinstanzfähig?
speicherindirekte Adressierung
registerindirekte Adressierung
Wird das AR2 gerettet? ; bzw. verwendet? (innerhalb der Bausteine)

Quintessenz: wenn das AR2 verändert wird, und nicht wiedergergestellt sind die Lokal-Stacks versaut. (Lx.x)

Guta Nacht
jb
 
Zurück
Oben