# e!Cockpit: Variable meldet <Der Wert des Ausdrucks kann nicht gelesen werden>



## Nilzon (30 Dezember 2021)

Hallo liebes Forum,

ich habe keinen Ansatz, in welche Richtung ich suchen muss, daher sind hier sicher nicht alle relevanten Informationen.
Die werde ich natürlich ergänzen, je nachdem, wohin die Reise geht. 

Was bisher geschah: 
Ich baue an der Rolladensteuerung
Die hardwareseitige Ansteuerung erfolgt von einem PFC200 über ModBus RTU an einen Arduino Nano und dann auf Relais.
Geschalten wird es über die Webvisu.
Parametriert wird mit e!Cockpit.
Das Erdgeschoss ist fertig und funktionierte seit längerem einwandfrei.

Nun wollte ich das Obergeschoß hinzufügen.
Ich habe dazu erstmal das Projekt erweitert. 
Das heißt: Neuen ModBus Slave hinzugefügt und erstmal im bestehenden Programm die neuen Variablen deklariert. Und alles auf den PFC geladen.
Die Visu habe ich noch nicht erweitert.

Das führte dann schon dazu, dass nun bei zwei bestehenden Variablen vom Erdgeschoß drei Fragezeichen stehen und <Der Wert des Ausdrucks kann nicht gelesen werden>. Leider animiert das die Steuerung jetzt, auf der ModBus-Steuerung ein TRUE zu schreiben. 

An der Webvisu habe ich nichts verändert. 
Interessant fand ich, dass eine neue Variable für's OG dasselbe Verhalten zeigt, obwohl sie lediglich deklariert und nirgends verwendet wurde:



Wenn ich alles zurücksetze und neu starte, dann wird alles erstmal mit FALSE (also korrekt) initialisiert und nach ein paar Sekunden wechseln die besagten Variablen (und nur diese( dann in den beschriebenen Zustand.

Ich bin ratlos und dankbar für jeden Ansatz.

Schöne Grüße,
Nils


----------



## JSEngineering (30 Dezember 2021)

Moin Nilzon,

hast Du nur Änderungsladen gemacht oder gesamt neu übersetzt?
Durch das Hinzufügen verschieben sich die Adressen, je nach dem, was da noch in Deinem Programm passiert, könnten eventuell solche Effekte auftauchen.
Ist OG_hi_li_auf als lokale Variable, als globale Variable, als Merker definiert?

Fragezeichen und nicht lesbare Ausdrücke sind entweder Zeichen für Inkonsistenzen oder daß vom FB keine Instanz ausgewählt ist.

Gruß
    Jens


----------



## Nilzon (30 Dezember 2021)

Hallo Jens,

danke für die Hilfe.
Ich habe alles neu übersetzt und geladen. Online-Aktualisierung verwende ich nie, eben wegen der von Dir beschriebenen Effekte.
OG_hi_li_auf ist eine lokale Variable.

Ich hab versucht, das "zurückzubauen", also die o.g. Änderungen gegenüber den letzten funktionierenden Stand wieder zu entfernen.
Der Fehler bleibt.

Irgendein Speicher-Thema könnte schon sein.
Wobei es zunächst ja funktioniert.
Ich kann die Variablen auch über die VISU steuern. Dann stimmt der Zustand wieder. Zumindest kurz.

Ich habe auch einen Ursprungs-Reset durchgeführt. Ohne Erfolg.


Ein ähnlicher Fall ist hier beschrieben:





						e!cockpit "Der Wert des Ausdrucks kann nicht gelesen werden"
					

Hallo zusammen,  ich zerbreche mir gerade den Kopf über ein Problem in meiner Software. Ich habe eine Lichtsteuerung am Laufen - die auch ganz gut funktioniert soweit.  Vor kurzem musste ich mein StandardProgramm aber von maximal 8 DALI-Gruppen auf 16 DALI Gruppen erweitern. Um unnötige...




					www.sps-forum.de
				



Leider ohne Lösung.

Viele Grüße,
Nils


----------



## JSEngineering (30 Dezember 2021)

Du hast den Modbus hinzugefügt?
Irgendwie habe ich das Gefühl, daß der Modbus Dir die Werte überschreibt... Versuche mal, den raus zu nehmen.
Denn das müssen ja Werte sein, die sich "langsam" aktualisieren, sonst würden die Werte ja nicht eine gewisse Zeit stehen bleiben.


----------



## Nilzon (30 Dezember 2021)

Den ModBus hab ich raus. Hat keine Besserung gebracht. 
Ich hatte auch mal in die Richtung überlegt, ob das vielleicht ein Timing-Problem ist. 
Das hab ich wieder verworfen. Um das Relais am Slave zu setzen schreibe ich ein Bit in einem Register. 

z.B. 
Modbus.Slave1.Word0.0 := OG_hi_li_auf 

Somit greift da niemand anderes drauf zu. 
Wobei ich ja nichtmal diese Zeile mehr drin habe. 
Da steht nur noch die Variablendeklaration im Kopfteil. Allen Code habe ich schon gelöscht.


----------



## .:WAGO::0104607:. (30 Dezember 2021)

Hallo Nilzon,

benutzt du für die Modbus-Kommunikation in e!COCKPIT den Feldbuskonfigurator? Nach deiner Beschreibung hört es sich so an, als ob hier Modbus Channel überschrieben werden und somit ein undefinierter Zustand entsteht.
Eine Meldung dazu würdest du im Feldbuskonfigurator finden.




Falls dies der Fall sein sollte, könntest du ggf. die Register der Modbus-Slave-Variablen anpassen.


----------



## Nilzon (30 Dezember 2021)

Hallo Wago! 

Danke für die Hilfe. 

Ja, ich verwende den Feldbuskonfigurator. 

Ich habe dort eben das Word. 
Und dann setze ich die einzelnen Bits davon im Programmcode. 




Wo würde ich die entsprechende Meldung finden?
Was mich stutzig macht ist, dass ich das ja alles auskommentiert habe und gleichzeitig das Verhalten nach wie vor beobachte.

Viele Grüße,
Nils


----------



## .:WAGO::0104607:. (30 Dezember 2021)

Die Meldung würde direkt dort durch ein Ausrufezeichen angezeigt werden.

Werden bei dir im Programm zufällig in Schleifen Array-Indizes hochgezählt oder Ähnliches?
Wichtig ist, dass die Indexgrenzen eingehalten werden. 
Gibt es Feldgrenzenverletzungen kann es auch zu solchen Problemen kommen.


----------



## Nilzon (30 Dezember 2021)

Schade, dann ist da keine Fehlermeldung. 

Hier noch die Querverweisliste für die Variable, die ungültig angezeigt wird.
Wie man sieht ist sie nirgends verwendet. 




In diesem POU gibt es keine Schleifen oder ähnliches. 

Das hier ist der ganze Code.

// TP13(IN:= OG_hi_li_auf, PT:= T#20S, Q=> OG_hi_li_auf_T, ET=> );
// MODBUS.UV_OG_rtu.OG_Rollaeden.0 := OG_hi_li_auf_T OR OG_hi_li_auf_V;
// MODBUS.UV_OG_rtu.OG_Rollaeden.0 := OG_hi_li_auf_T OR OG_hi_li_auf_V;


----------



## JSEngineering (30 Dezember 2021)

Das kann auch in einem anderen POU passieren, wenn Du dort Schleifen hast.

Suche mal in der Hilfe nach CheckBounds und füge die mal in dein Programm ein (selber schreiben, keine Bibliotheksfunktion)


----------



## Nilzon (30 Dezember 2021)

Dankeschön! Das werde ich tun. Wird ein Weilchen dauern. Ich melde mich wieder, wenn ich fertig bin.


----------



## Nilzon (30 Dezember 2021)

Hallo Jens, 
hallo Wago-Support,

es läuft wieder. Juhu! 

Ursache: 
Ein übergelaufener Index.

Fehlersuche: 
Ich habe CheckBounds implementiert und eine Exception werfen lassen. 
Wie beschrieben ging das eine Weile gut, bis eben das Array voll war. 
Dann habe ich nach dem betroffenen Array gesucht. 
Um das einzugrenzen habe ich den Aufruf einzelner POUs auskommentiert. 

Was hat mir geholfen? 
Der Tipp von Wago aus Beitrag #8 mit den Indizes in Zusammenhang mit dem Hinweis von Jens auf Beitrag #10, dass ich in der gesamten Anwendung suchen muss. Und der Hinweis auf das richtige Werkzeug (CheckBounds) war naürlich auch top.

Was ist noch offen?? 

Ich habe einiges über Speichermanagement gelernt und natürlich ist das (vom oberen Stand der Lernkurve betrachtet) logisch, dass das den Controller nicht interessiert, ob es im selben POU ist oder nicht. Der denkt in anderen Kategorien. Das Wissen würde ich gerne vertiefen und nehme jeden Lektürehinweis dankbar entgegen. 
CheckBounds ist cool. Ich hatte dann nur einige Sucherei. Ich habe den Verdacht, dass das einfacher gehen könnte als ich es getan habe. Kann man von der Exception aus zu dem Punkt im Programmablauf kommen, der sie ausgelöst hat?
Ich danke Euch beiden herzlich für die Unterstützung. 
Danke, dass ihr Euch Zeit genommen habt, um mir zu helfen. 
Ich wünsche Euch einen guten Rutsch ins neue Jahr!

Viele Grüße,
Nils


----------



## JSEngineering (30 Dezember 2021)

Ich mach es, sofern im Prozeß möglich, mit Breakpoints in CheckBounds. Breakpoint setzen auf das Innere der If-Anweisung, wo die Korrektur des Index vorgenommen wird. Dann Schrittweise weiter, dann kommst Du an die Stelle, wo CheckBounds aufgerufen wurde.
Sonst kann man zumindest Zähler oder Merker setzen lassen, so dass man sieht, ob es eine obere oder untere Grenzwertverletzung gibt, kann auch helfen, um die Stelle einzugrenzen.


----------



## paro (30 Dezember 2021)

Genau! Haltepunkte in den beiden Zeilen setzen, in denen der obere bzw. der untere Grenzwert gesetzt wird, falls über-/unterschritten (nicht in der Zeile, in der einfach der Index übergeben wird). Sollte dein Programm dann tatsächlich dort anhalten, kannst du unter dem Reiter „Debug“ ->  „Ausführen bis Rücksprung“ anklicken und so kommst du zu der Programmstelle an der die Verletzung aufgetreten ist.

Gruß


----------



## Nilzon (17 Februar 2022)

Danke für die ergänzenden Infos!


----------

