Idee: Systemvariablen Pushen statt mit GETCCUSYSVAR Pullen

[Familienvater]

Hi,

ohne "doppelte Buchführung" wird ein Wiffi keine Chance haben, nur geänderte Werte zu übertragen.
Für meine Programme in VB6 habe ich u.a. eine Klasse geschrieben, und jedes (notwendige) HPCL-Objekt wird einer Instanz der Klasse zugewiesen. Die kennt den Wert, den die zuletzt an HPCL gesendet hat. Wird der zu sendende "Wert" der Instanz geändert (gegenüber dem zuletzt gesendeten), dann wird das Dirty-Flag der Instanz gesetzt, und am Ende laufe ich durch alle Instanzen und nur die Dirty sind, werden gesendet und dann Dirty gelöscht (und jede Instanz kennt den eindeutigen Objekt-Index vom HPCL-Objekt, und kann dieses deshalb direkt per Index schnell aktualisieren). Die ganze Indexgeschichte dürfte aber die Fähigkeiten von so einem kleinen Wemos/arduino/... sprengen, zu CCU1-Zeiten hat die erstmalige Abfrage der Objektliste von der HPCL-Execengine bei mir bis zu 80 Sekunden gedauert (die CCU braucht immer noch mehr als 20 Sekunden bei meinem Projekt), dann bekommt man ein viele KB großes XML zurück (was ich dann geparsed auf einem SQL-Server speichere, so das es nur einmal pro neuem Projekt gemacht werden muss, danach kann ich schnell über SQL auf die Variablenindices zugreifen).

Der Familienvater

[Daimler]

Hi Tobias,

tja, alle Wünsche gleichzeitig zu erfüllen ginge nur, wenn Contronics die Systemvariablen nativ integrieren würde - und am Besten dann auch gleich noch die CUxD Geräte

Manchmal geschehen ja Wunder.

(natürlich freiwillig / nicht für Dich ).

Danke.

Ich habe übrigens mit der "Lesewertedatei-Geschichte" weit mehr schlechte Erfahrung gemacht.....defekten USB Sticks, die jeweils nach ~ 1 Jahr ihre maximale Lebenserwartung erreicht haben!

Aus diesem Grunde setze ich eigentlich seit Umstieg auf die CCU bzw. LXCCU SSDs ein - da sehe ich das eher locker.

...als mit dem getccusysvar. Letzteres scheint bereits seit einigen Releases ziemlich robust zu funktionieren!

Wenn da nicht diese beiden Errors bei jeder getccusysvar Abfrage wären.
Die aber laut R.K. zu vernachlässigen sind.

Hi Vadder,

....ein Wiffi keine Chance haben, nur geänderte Werte zu übertragen.

Das macht er ja eigentlich schon.

ohne "doppelte Buchführung"....

Da liegt der Haken.
Aber eventuell sieht Eugen eine Möglichkeit, die Werte zusätzlich anderweitig zu übertragen.

...zu CCU1-Zeiten hat die erstmalige Abfrage der Objektliste von der HPCL-Execengine bei mir bis zu 80 Sekunden gedauert..

Ich habe auch jetzt auf dem Raspy in HPCL noch eine Pause von 3 Minuten nach Neustart des Projektes eingerichtet, bevor ich die alten gespeicherten Werte einlese und die Ausführung freigebe.

...was ich dann geparsed auf einem SQL-Server speichere...

Das wäre zwar eine Möglichkeit. sähe ich aber hier nur für ein paar Variablen als ein klein wenig oversized.

Aber egal:
Ich habe den Wiffi jetzt einmal an meinen Test Raspy gehangen und in HPCL ein Makro angelegt, welches alle SV's des Wiffi jede Sekunde abholt.
Sicherheitshalber habe ich einmal das Logging der Logigschicht in der CCU deaktiviert.
Schau'n mer mal, wie lange das gut geht.

Werde berichten.

[Daimler]

Hi,

kurzer Zwischenstand:
Nachdem ich die Wiffi-Abfrage auf dem Test-Raspy eine Woche ohne Probleme (außer den Errors im Log) laufen hatte - Noise und Bewegung werden jede Sekunde , der Rest alle 5 Minuten per getccusysvar abgefragt, ist der Wiffi nun seit einer Woche auf den Produktiv-Raspy umgezogen.
Auch hier keine 'besonderen Vorkommnisse'!

Hätte ja trotzdem gedacht, dass uns Eugen sich mal meldet.