Variabelnproblem

[weneu]

Hallo (Werner),
warum liefert folgende Anweisung

%unit_off%%ws_setmem[21]=%ws_calc[/]=%ws_baro1h%~33,86~5%% %ws_getmem[21]% inHg/1h<br>
%ws_setmem[22]=%ws_calc[/]=%ws_baro2h%~33,86~5%% %ws_getmem[22]% inHg/2h<br>
%ws_setmem[23]=%ws_calc[/]=%ws_baro3h%~33,86~5%% %ws_getmem[23]% inHg/3h<br>
%ws_setmem[24]=%ws_calc[/]=%ws_baro12h%~33,86~5%% %ws_getmem[24]% inHg/12h<br>%unit_on%

kein vollständiges Ergebnis, sondern nur:

inHg/1h
0,00000 inHg/2h
inHg/3h
0,02953 inHg/12h

Mit anderen Worten: es werden 2 Variablen auasgewertet (berechnet) und zwei nicht.
Hintergrund:
Es sollen die Variablen %ws_baro1h% usw. von hPa auf inHG umgesetzt werden.

[Holli]

Hallo (Werner),
warum liefert folgende Anweisung
[..]
kein vollständiges Ergebnis, sondern nur:

inHg/1h
0,00000 inHg/2h
inHg/3h
0,02953 inHg/12h

<ganz breit grins>Hat es dich auch mal erwischt...
Bei mir kommt mit deinem Code immerhin ein bißchen mehr raus, wenn auch nichts richtiges:

Code: Alles auswählen

 0,00591 inHg/1h<br> 
 0,00295 inHg/2h<br> 
 0,01477 inHg/3h<br> 
   inHg/12h<br>

Besser, aber nicht gut.

Brauchst du unbedingt den Umweg über die Speichervariablen? Wenn ich mir die nämlich spare und die errechneten Werte direkt ausgebe, bekomme ich das:

Code: Alles auswählen

0,00295 inHg/1h<br> 
0,00295 inHg/2h<br> 
0,01181 inHg/3h<br> 
0,11223 inHg/12h<br>
0,41937 inHg/24h<br>

Und das sieht weitaus logischer aus...

Wenn du die Speichervariablen später noch brauchst, reicht es, das Setzen der Variablen und die Abfrage in verschiedene Zeilen zu bringen:

Code: Alles auswählen

%unit_off%
%ws_setmem[21]=%ws_calc[/]=%ws_baro1h%~33,86~5%%
%ws_setmem[22]=%ws_calc[/]=%ws_baro2h%~33,86~5%%
%ws_setmem[23]=%ws_calc[/]=%ws_baro3h%~33,86~5%%
%ws_setmem[24]=%ws_calc[/]=%ws_baro12h%~33,86~5%%
%ws_getmem&#91;21&#93;% inHg/1h<br> 
%ws_getmem&#91;22&#93;% inHg/2h<br> 
%ws_getmem&#91;23&#93;% inHg/3h<br> 
%ws_getmem&#91;24&#93;% inHg/12h<br>
%unit_on%

Zumindest bei mir ergibt das sinnvolle Werte...

Es scheint dasselbe Parser-Problem zu sein, weswegen ich letztens bei meinem Beispiel für die Durchschnittsberechnung einen Umweg machen mußte. ws_calc scheint damit ein Problem zu haben und keine oder falsche Ergebnisse zu liefern. Ich kann damit leben, solange ich mit einem Workaround zu verwertbaren Ergebnissen komme.

[weneu]

Hallo Dietmar,
kann zwar deine Freude nachvollziehen , aber so geht es bei mir (seltsamerweise) auch nicht. Das ist eh der Weg, den ich zuvor versucht habe. Hier kommt bei mir überhaupt nichts raus, also so:

inHg/1h
inHg/2h
inHg/3h
inHg/12h

Das war eben der Grund, warum ich dann nacheinnander verschiedene Wege (erfolglos) durchgetestet habe. Wenn ich nur eine Umwandlung vornehme, geht es natürlich.

[weneu]

Hallo,
muss nochmals nachhaken:
Das Seltsame ist, dass ich immer wieder andere Ausgaben erhalte und daher keinen Ansatzpunkt finde:
Jetzt aktuell z.B.

inHg/1h
0,00000 inHg/2h
0,00000 inHg/3h
0,00000 inHg/12h

Wobei in diesem Fall die Werte für 2h/3h/12h stimmen, da keine Änderung vorhanden war, aber eben die Berechnung für 1h fehlt.

[Werner]

Hallo Werner,

soviel ich mich entsinne, wird bei diesen Barovariablen (wenn Unitoff verwendet) der hintere Text nur abgeschnitten.

Es könnte sein, dass hier ein Leerzeichen übrigbleibt.

Und Leerzeichen bei Berechnungen veranlasst das Programm, die Berechnung abzubrechen.
Wobei es hier teilsweise toleranter wurde (ab V2.85..
Bei Verwendung von Speichervariablen funktioniert das aber nicht.

Wenn getmem und setmem in der gleichen Zeile verwendet wird (mit selben Index), muss man beachten, dass getmem Vorrang hat.
In Deinem Fall hat getmem in der Regel nicht den Inhalt von setmem!!!
(nur wenn sich der Wert nicht geändert hat, dann funktioniert das)

Besser ist es deshalb: setmem und getmem in verschiedenen Zeilen zu verwenden, damit ist sichergestellt das vorher zugewiesene auch verwendet wird.

Verwende in diesem Fall besser die Variablen
%curminmaxhour[4,3,33]%
%curminmaxhour[4,6,33]%
%curminmaxhour[4,12,33]%
%curminmaxhour[4,24,33]%

Wobei diese Variable die Umrechnung auf andere Einheiten direkt unterstützt.

Werner

[weneu]

Hallo Werner,
das dürfte wohl der Grund sein. Werde die anderen Variablen (curminmaxhour) verwenden, ist ja auch einfacher.

[Holli]

Hallo Dietmar,
kann zwar deine Freude nachvollziehen , aber so geht es bei mir (seltsamerweise) auch nicht.

Das ist aber mehr als merkwürdig... Klappen denn irgendwelche anderen ws_calc-Berechnungen?

Da ist aber noch viel mehr merkwürdig. Bei mir kommen mit deinem Code jetzt zwar alle Ausgaben, die Zahlen passen aber nicht zu den Ausgangswerten... Moment...

Bei deinem Code werden anscheinend die Variableninhalte des vorherigen WsWin-Laufs ausgegeben, obwohl sie direkt vorher neu beschrieben worden sein müßten. Um Mißverständnisse auszuschließen, hier zunächst der Code:

Code: Alles auswählen

%ws_baro1h%
%ws_baro2h%
%ws_baro3h%
%ws_baro12h%

%unit_off%%ws_setmem&#91;21&#93;=%ws_calc&#91;/&#93;=%ws_baro1h%~33,86~5%% %ws_getmem&#91;21&#93;% inHg/1h<br> 
%ws_setmem&#91;22&#93;=%ws_calc&#91;/&#93;=%ws_baro2h%~33,86~5%% %ws_getmem&#91;22&#93;% inHg/2h<br> 
%ws_setmem&#91;23&#93;=%ws_calc&#91;/&#93;=%ws_baro3h%~33,86~5%% %ws_getmem&#91;23&#93;% inHg/3h<br> 
%ws_setmem&#91;24&#93;=%ws_calc&#91;/&#93;=%ws_baro12h%~33,86~5%% %ws_getmem&#91;24&#93;% inHg/12h<br>%unit_on%

%unit_off%
%ws_calc&#91;/&#93;=%ws_baro1h%~33,86~5% inHg/1h<br> 
%ws_calc&#91;/&#93;=%ws_baro2h%~33,86~5% inHg/2h<br> 
%ws_calc&#91;/&#93;=%ws_baro3h%~33,86~5% inHg/3h<br> 
%ws_calc&#91;/&#93;=%ws_baro12h%~33,86~5% inHg/12h<br>
%unit_on%

Und hier zwei Ausgaben hintereinander:

Code: Alles auswählen

Zeit 14:51

-0,2hPa/1h
-0,6hPa/2h
-0,8hPa/3h
0,0hPa/12h

 0,00295 inHg/1h<br> 
 -0,01181 inHg/2h<br> 
 -0,02067 inHg/3h<br> 
 0,00591 inHg/12h<br>
 
-0,00591 inHg/1h<br> 
-0,01772 inHg/2h<br> 
-0,02363 inHg/3h<br> 
0,00000 inHg/12h<br>

Zeit 14&#58;56

-0,2hPa/1h
-0,5hPa/2h
-0,9hPa/3h
0,0hPa/12h

 -0,00591 inHg/1h<br> 
 -0,01772 inHg/2h<br> 
 -0,02363 inHg/3h<br> 
 0,00000 inHg/12h<br>


-0,00591 inHg/1h<br> 
-0,01477 inHg/2h<br> 
-0,02658 inHg/3h<br> 
0,00000 inHg/12h<br>

Für mich paßt das. WsWin gibt dabei gar nicht die Speicherinhalte des aktuellen Durchlaufs aus, sondern des vorigen.

Bleiben bei dir die Ergebnisse auch leer, wenn du WsWin denselben Code mehrmals hintereinander berechnen läßt, so daß die Variablen nicht jedesmal frisch initialisiert und damit leer sind?

[weneu]

Hallo Dietmar,

Bleiben bei dir die Ergebnisse auch leer, wenn du WsWin denselben Code mehrmals hintereinander berechnen läßt

Ja
Aber ich denke, die Erklärung von Werner liefert (indirekt) die Begründung für dieses zunächst seltsam erscheinende Verhalten (er sollte es ja auch wissen )

Klappen denn irgendwelche anderen ws_calc-Berechnungen

Ja, die funktionieren alle, da ich sie ständig für irgendwelche Testzwecke verwende.
Das war auch mit der Grund, warum ich bei dem obigen Beispiel nicht curminmaxhour verwendet habe. Ich wollte es mal auf die andere Art versuchen, sehe aber nun, dass es aus verschiedenen Gründen nicht geht.

[Holli]

Hallo Dietmar,

Bleiben bei dir die Ergebnisse auch leer, wenn du WsWin denselben Code mehrmals hintereinander berechnen läßt

Ja
Aber ich denke, die Erklärung von Werner liefert (indirekt) die Begründung für dieses zunächst seltsam erscheinende Verhalten (er sollte es ja auch wissen )

Wer sonst?
Die Erklärung für die Speicherausgabe ist plausibel, den Rest kann ich hier aber nicht nachvollziehen. Beim dem Code, bei dem Setzen und Auslesen in verschiedenen Zeilen erfolgen, habe ich hier nach wie vor korrekte Ausgaben mit den ws_baro-Variablen.

Ich wollte es mal auf die andere Art versuchen, sehe aber nun, dass es aus verschiedenen Gründen nicht geht.

Die Gründe wüßte ich aber auch gern. Macht irgendwie keinen Spaß, vor einem syntaktisch richtigen Codestück zu sitzen und merkwürdige Werte zu bekommen , auch wenn es jetzt gerade umgekehrt ist: Ich bekomme korrekte Werte und du nicht. Insofern paßt Werners Begründung nicht so ganz. Entweder sollten wir beide falsche oder beide richtige Ausgaben bei identischem Code haben.

Andererseits bin ich aber der Meinung, daß sowieso die Ausgabe fast nur über allgemeine Variablen wie curminmaxhour, curval u.ä. gemacht werden sollte, weil damit eben alle möglichen Werte für alle möglichen Sensoren zugänglich wären. Deshalb werde ich mich jetzt nicht beschweren, daß dieser Weg funktioniert und hoffen, daß Werner irgendwann ein Einsehen hat und auch Spezialvariablen, die zur Zeit nur für einen Sensor(typ) funktionieren, auf die allgemeine Syntax umsetzt.

[Werner]

@Hallo Dietmar,

vor einem syntaktisch richtigen Codestück zu sitzen und

... der Code ist syntatisch nicht richtig!

Da %ws_getmem% in einer Zeile mit %ws_setmem Vorrang hat ...
%unit_off%%ws_setmem[21]=%ws_calc[/]=%ws_baro1h%~33,86~5%% %ws_getmem[21]% inHg/1h<br>

... erhält man hier immer den einmal vorher zugewiesener Wert mit
%ws_getmem

Werner