Ankündigung

**Jambala** · 05.03.2014, 20:24

Ein erster Schritt zur Fehlereingrenzung ist für mich der Minimalcode aus dem Anhang.

Diesen einspielen und die Auslastung des EibPC beobachten.

Angehängte Dateien

Luxtronik 1 Minimalcode.epc.zip (5,0 KB, 3x aufgerufen)

**Jambala** · 05.03.2014, 21:02

Wenn der Minimalcode aus dem ersten Schritt ohne erhöhte Auslastung des EibPC läuft, dann im nächsten Schritt diesen Code einspielen.

Vorher aber im Code die IP Adresse des eigenen PC/Mac eintragen (z.B. Debug_IP = 192.168.0.10).

Durch Aufruf von NetCat über die Windos Kommandozeile (nc -p 5050 -u -l) können die grundsätzlichen Ausführungsschritte des Luxtronik Gateways und alle Temperaturinformationen beobachtet werden.

Wenn jetzt noch immer alles ohne Auslastungsprobleme des EibPC läuft, ist der Fehler im Zusammenhang mit dem persönlichen Code zu suchen.

Die beiden Testcodes habe ich nicht testen können, da ich keine Luxtronik 1 mehr im Einsatz haben.

Viele Erfolg

Michael

Angehängte Dateien

Luxtronik 1 Minimalcode Debug-Info.epc.zip (5,6 KB, 3x aufgerufen)

**Matthias** · 05.03.2014, 22:45

Hallo Michael (Jambala),

danke für Deine Mühe!!!

Habe gleich die Debug-Version getestet.
Habs auch noch etwas modifiziert (size(Buffer) eingefügt)

Hmm, da haben wir noch ein Problem. Die 20s Delay sind wieder da.
Hier die NetCat Ausgabe:

HTML-Code:

 @ 22:12:33.0, systemstart()
 @ 22:13:32.549, Luxtronik1: RS232 Request gesendet
 @ 22:13:32.639, Luxtronik1: RS232 Daten empfangen (Buffer=194 Byte)
 @ 22:13:32.639, Luxtronik1: Parsen der Rohdatenbloecke(Buffer=194 Byte)
 @ 22:13:32.833, Luxtronik1: Parsen der Temperaturwerte
 @ 22:13:32.833, Luxtronik1: WP_Temp_Heizkreis_Ist_Vorlauftemperatur = 29.30
 @ 22:13:32.833, Luxtronik1: WP_Temp_Heizkreis_Ist_Ruecklauftemperatur = 29.30
 @ 22:13:32.833, Luxtronik1: WP_Temp_Heizkreis_Soll_Ruecklauftemperatur = 28.70
 @ 22:13:32.833, Luxtronik1: WP_Temp_Heissgastemperatur = 20.50
 @ 22:13:32.833, Luxtronik1: WP_Temp_Aussentemperatur = 7.20
 @ 22:13:32.833, Luxtronik1: WP_Temp_Warmwasser_Ist_Temperatur = 43.80
 @ 22:13:32.833, Luxtronik1: WP_Temp_Brauchwarmwasser_Soll_Temperatur = 45.00
 @ 22:13:32.833, Luxtronik1: WP_Temp_Waermequellen_Eintrittstemperatur = -50.00
 @ 22:13:32.833, Luxtronik1: WP_Temp_Waermequellen_Austrittstemperatur = -50.00
 @ 22:13:32.833, Luxtronik1: WP_Temp_Mischkreis_1_Ist_Vorlauftemperatur = 75.00
 @ 22:13:32.833, Luxtronik1: WP_Temp_Mischkreis_1_Soll_Vorlauftemperatur = 0.00
 @ 22:13:32.833, Luxtronik1: WP_Temp_Raumstation = 0.00
 @ 22:13:32.833, Luxtronik1: Parsen der W├ñrmepumpeneingaenge
 @ 22:13:32.833, Luxtronik1: Parsen der W├ñrmepumpenausgaenge
 @ 22:13:32.833, Luxtronik1: Parsen der Ablaufzeiten
 @ 22:13:32.833, Luxtronik1: Parsen der Betriebsstunden
 @ 22:13:32.833, Luxtronik1: Parsen der Fehler
 @ 22:13:32.833, Luxtronik1: Parsen der Abschaltungen
 @ 22:13:32.833, Luxtronik1: Parsen des Anlagenstatus

 @ 22:13:50.999, Luxtronik1: RS232 Daten empfangen (Buffer=647 Byte
 @ 22:13:50.999, Luxtronik1: Parsen der Rohdatenbloecke(Buffer=647 Byte
 @ 22:13:51.0, Luxtronik1: Parsen der Temperaturwerte
 @ 22:13:51.0, Luxtronik1: WP_Temp_Heizkreis_Ist_Vorlauftemperatur = 29.30
 @ 22:13:51.0, Luxtronik1: WP_Temp_Heizkreis_Ist_Ruecklauftemperatur = 29.30
 @ 22:13:51.0, Luxtronik1: WP_Temp_Heizkreis_Soll_Ruecklauftemperatur = 28.70
 @ 22:13:51.0, Luxtronik1: WP_Temp_Heissgastemperatur = 20.50
 @ 22:13:51.0, Luxtronik1: WP_Temp_Aussentemperatur = 7.20
 @ 22:13:51.0, Luxtronik1: WP_Temp_Warmwasser_Ist_Temperatur = 43.80
 @ 22:13:51.0, Luxtronik1: WP_Temp_Brauchwarmwasser_Soll_Temperatur = 45.00
 @ 22:13:51.0, Luxtronik1: WP_Temp_Waermequellen_Eintrittstemperatur = -50.00
 @ 22:13:51.0, Luxtronik1: WP_Temp_Waermequellen_Austrittstemperatur = -50.00
 @ 22:13:51.0, Luxtronik1: WP_Temp_Mischkreis_1_Ist_Vorlauftemperatur = 75.00
 @ 22:13:51.0, Luxtronik1: WP_Temp_Mischkreis_1_Soll_Vorlauftemperatur = 0.00
 @ 22:13:51.0, Luxtronik1: WP_Temp_Raumstation = 0.00
 @ 22:13:51.0, Luxtronik1: Parsen der W├ñrmepumpeneingaenge
 @ 22:13:51.0, Luxtronik1: Parsen der W├ñrmepumpenausgaenge
 @ 22:13:51.0, Luxtronik1: Parsen der Ablaufzeiten
 @ 22:13:51.0, Luxtronik1: Parsen der Betriebsstunden
 @ 22:13:51.0, Luxtronik1: Parsen der Fehler
 @ 22:13:51.0, Luxtronik1: Parsen der Abschaltungen
 @ 22:13:51.0, Luxtronik1: Parsen des Anlagenstatus

Das Parsing beginnt obwohl der Buffer noch gar nicht voll ist?

Zeitgleich hab ich noch jede Sekunde die Zeit auf den Bus geschickt.
Aus Sicht des EibPCs:

HTML-Code:

% 2014-03-05 22:13:31 | Sender: EibPC | GA: ?%  | Wert: ?%  | Typ: ?%  |  Schreiben
% 2014-03-05 22:13:32 | Sender: EibPC | GA: ?%  | Wert: ?%  | Typ: ?%  |  Schreiben

% 2014-03-05 22:13:51 | Sender: EibPC | GA: ?%  | Wert: ?%  | Typ: ?%  |  Schreiben

% 2014-03-05 22:14:10 | Sender: EibPC | GA: ?%  | Wert: ?%  | Typ: ?%  |  Schreiben
% 2014-03-05 22:14:11 | Sender: EibPC | GA: ?%  | Wert: ?%  | Typ: ?%  |  Schreiben
% 2014-03-05 22:14:12 | Sender: EibPC | GA: ?%  | Wert: ?%  | Typ: ?%  |  Schreiben

Aus Sicht ETS (13s Zeit Offsetverschiebung):

HTML-Code:

#    Zeit    Quelladr    Zieladr    Typ    Daten
67    22:13:15.031    15.15.11    15/3/0    Write    76 0D 1D
68    22:13:16.046    15.15.11    15/3/0    Write    76 0D 1E
69    22:13:17.078    15.15.11    15/3/0    Write    76 0D 1F
70    22:13:18.093    15.15.11    15/3/0    Write    76 0D 20
                    
74    22:13:36.921    15.15.11    15/3/0    Write    76 0D 32
                    
77    22:13:56.531    15.15.11    15/3/0    Write    76 0E 0A
78    22:13:57.515    15.15.11    15/3/0    Write    76 0E 0B
79    22:13:58.546    15.15.11    15/3/0    Write    76 0E 0C

Das mit dem verfrühten Parsen scheint aber nicht wirklich das (einzige?) Problem zu sein.
Auch nach dem zweiten Parsen des Buffers kommt es zu dem Delay.
Werd morgen mir mal Gedanken machen ob ich da noch was gegen tun kann..

Grüße
Matthias

**saft6luck** · 05.03.2014, 23:03

Zitat von Matthias Beitrag anzeigen

Das mit dem verfrühten Parsen scheint aber nicht wirklich das (einzige?) Problem zu sein.

Das könnte aber den regelmäßigen worst case erklären, denn dann ändern sich auch alle Teilstrings und das change() erkennt eine Änderung. Auch sind die 0°C Temperaturen hiermit erklärbar.

**Matthias** · 05.03.2014, 23:04

kleines Update.

habe noch mal das Skript verändert, dass erst 5s nach Beginn der RS232 Kommunikation mit ver Verarbeitung begonnen werden kann:

hinzugefügt: if change(RS232_Statusabfrage) and RS232_Statusabfrage == AUS

[highlight=epc]
if after(RS232_Statusabfrage == EIN,5000u64) then \\
RS232_Statusabfrage = AUS \\
endif

// Empfangen des Anlagenstatus �S232 und f�des Buffers

if RS232_Statusabfrage == EIN and event(readrs232(Rawdata1, Len1)) then \\
Buffer = split(Rawdata1, 0u16, Len1); \\
DataParsingWP = EIN; \\
sendudp(Debug_Port, Debug_IP, $@ $ + Currenttime + $, Luxtronik1: $ + $RS232 Daten empfangen (Buffer=$+convert(size(Buffer),$$)+$ Byte$+NewLine); \\
endif

// Parsen der einzelnen Informationsbl� der W㱭epumpendaten

if change(RS232_Statusabfrage) and RS232_Statusabfrage == AUS and DataParsingWP == EIN then \\
[/highlight]

Das Verhalten hat sich auch schon geändert:

HTML-Code:

 @ 22:50:58.0, systemstart()
 @ 22:51:57.549, Luxtronik1: RS232 Request gesendet
 @ 22:51:57.639, Luxtronik1: RS232 Daten empfangen (Buffer=122 Byte
 @ 22:51:57.707, Luxtronik1: RS232 Daten empfangen (Buffer=335 Byte
 @ 22:51:57.752, Luxtronik1: RS232 Daten empfangen (Buffer=555 Byte
 @ 22:51:57.797, Luxtronik1: RS232 Daten empfangen (Buffer=646 Byte
 @ 22:52:2.572, Luxtronik1: Parsen der Rohdatenbloecke(Buffer=646 Byte
 @ 22:52:2.798, Luxtronik1: Parsen der Temperaturwerte
 @ 22:52:2.798, Luxtronik1: WP_Temp_Heizkreis_Ist_Vorlauftemperatur = 26.20
 @ 22:52:2.798, Luxtronik1: WP_Temp_Heizkreis_Ist_Ruecklauftemperatur = 27.30
 @ 22:52:2.798, Luxtronik1: WP_Temp_Heizkreis_Soll_Ruecklauftemperatur = 28.80
 @ 22:52:2.798, Luxtronik1: WP_Temp_Heissgastemperatur = 18.70
 @ 22:52:2.798, Luxtronik1: WP_Temp_Aussentemperatur = 7.00
 @ 22:52:2.798, Luxtronik1: WP_Temp_Warmwasser_Ist_Temperatur = 43.12
 @ 22:52:2.798, Luxtronik1: WP_Temp_Brauchwarmwasser_Soll_Temperatur = 45.00
 @ 22:52:2.798, Luxtronik1: WP_Temp_Waermequellen_Eintrittstemperatur = -50.00
 @ 22:52:2.798, Luxtronik1: WP_Temp_Waermequellen_Austrittstemperatur = -50.00
 @ 22:52:2.798, Luxtronik1: WP_Temp_Mischkreis_1_Ist_Vorlauftemperatur = 75.00
 @ 22:52:2.798, Luxtronik1: WP_Temp_Mischkreis_1_Soll_Vorlauftemperatur = 0.00
 @ 22:52:2.798, Luxtronik1: WP_Temp_Raumstation = 0.00
 @ 22:52:2.798, Luxtronik1: Parsen der W├ñrmepumpeneingaenge
 @ 22:52:2.798, Luxtronik1: Parsen der W├ñrmepumpenausgaenge
 @ 22:52:2.798, Luxtronik1: Parsen der Ablaufzeiten
 @ 22:52:2.798, Luxtronik1: Parsen der Betriebsstunden
 @ 22:52:2.798, Luxtronik1: Parsen der Fehler
 @ 22:52:2.798, Luxtronik1: Parsen der Abschaltungen
 @ 22:52:2.798, Luxtronik1: Parsen des Anlagenstatus

 @ 22:53:16.550, Luxtronik1: RS232 Request gesendet
 @ 22:53:16.640, Luxtronik1: RS232 Daten empfangen (Buffer=87 Byte
 @ 22:53:16.710, Luxtronik1: RS232 Daten empfangen (Buffer=317 Byte
 @ 22:53:16.757, Luxtronik1: RS232 Daten empfangen (Buffer=535 Byte
 @ 22:53:16.802, Luxtronik1: RS232 Daten empfangen (Buffer=646 Byte
 @ 22:53:21.596, Luxtronik1: Parsen der Rohdatenbloecke(Buffer=646 Byte
 @ 22:53:21.805, Luxtronik1: Parsen der Temperaturwerte
 @ 22:53:21.805, Luxtronik1: WP_Temp_Heizkreis_Ist_Vorlauftemperatur = 26.10
 @ 22:53:21.805, Luxtronik1: WP_Temp_Heizkreis_Ist_Ruecklauftemperatur = 27.30
 @ 22:53:21.805, Luxtronik1: WP_Temp_Heizkreis_Soll_Ruecklauftemperatur = 28.80
 @ 22:53:21.805, Luxtronik1: WP_Temp_Heissgastemperatur = 18.70
 @ 22:53:21.805, Luxtronik1: WP_Temp_Aussentemperatur = 7.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Warmwasser_Ist_Temperatur = 43.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Brauchwarmwasser_Soll_Temperatur = 45.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Waermequellen_Eintrittstemperatur = -50.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Waermequellen_Austrittstemperatur = -50.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Mischkreis_1_Ist_Vorlauftemperatur = 75.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Mischkreis_1_Soll_Vorlauftemperatur = 0.00
 @ 22:53:21.805, Luxtronik1: WP_Temp_Raumstation = 0.00
 @ 22:53:21.805, Luxtronik1: Parsen der W├ñrmepumpeneingaenge
 @ 22:53:21.805, Luxtronik1: Parsen der W├ñrmepumpenausgaenge
 @ 22:53:21.805, Luxtronik1: Parsen der Ablaufzeiten
 @ 22:53:21.805, Luxtronik1: Parsen der Betriebsstunden
 @ 22:53:21.805, Luxtronik1: Parsen der Fehler
 @ 22:53:21.805, Luxtronik1: Parsen der Abschaltungen
 @ 22:53:21.805, Luxtronik1: Parsen des Anlagenstatus

Der Cycle stand auf 1 Minute - hier sieht man sogar dass die 20s Verzögerung den Cycle durcheinander bringen.
Der erste Aufruf lief bei 22:51:57. Somit hätte der nächste Cycle bei 22:52:57 laufen müssen. Aber nein, der lief erst 22:53:16...

Ach neee...

So, muss erst mal wieder das reguläre Programm einspielen.

Grüße
Matthias

**Jambala** · 06.03.2014, 05:08

Den Verdacht mit dem RS232 Buffer hatte ich auch schon bei anderen Makros in der Vergangenheit.

Ursprünglich hatte ich das Verständnis, dass der EibPC die RS232 Daten intern zwischenspeichert und dann als Block in den Buffer schiebt. Tatsächlich wird der Datensatz (trotzdem er kurz ist) aber offensichtlich in mehreren Schritten in den Buffer geschrieben:

@ 22:51:57.639, Luxtronik1: RS232 Daten empfangen (Buffer=122 Byte
@ 22:51:57.707, Luxtronik1: RS232 Daten empfangen (Buffer=335 Byte
@ 22:51:57.752, Luxtronik1: RS232 Daten empfangen (Buffer=555 Byte
@ 22:51:57.797, Luxtronik1: RS232 Daten empfangen (Buffer=646 Byte

Das sollte aus meiner Sicht das change() der Datenauswertung unnötig häufig auslösen. In diesem Beispiel wird die gesamte Auswertung 4x pro Request an die WP angestossen.

Da hier einige "Spezialisten" Ihre WP alle 30 Sekunden abgefragt haben, würden so alle 7,5 Sekunden die Datenauswertung mit jeweils ca. 800 Zeilen Code durchlaufen werden. Das kann ich mir schon als Ursache für Performance Probleme vorstellen. Insbesondere wenn daneben noch andere Makros und eine umfangreiche Visu läuft.

Ich würde daher empfehlen bei der ursprünglich verwendeten Zykluszeit von 5 Minuten für die Abfragen an die WP zu bleiben.

Bei meinen IP basierten Makros kann eine Mehrfachauswertung nicht entstehen, weil ich den Status der Schnittstelle abfrage:

WP_TCP_ConnectionState = connecttcp(WP_Port, WP_IP)

Das Parsen der Daten erfolgt dann erst wenn der richtige Verbindungsstatus vorliegt für eine erfolgreiche beendete Abfrage vorliegt:

if after(WP_Query_State == WP_Query_State_QuerySuccess,1u64) then ...

Viele Grüße

Michael

**Jambala** · 06.03.2014, 05:28

Um eine durch den RS232 Buffer initiierte Mehrfachauswertung der Rohdaten zu unterbinden, würde ich den Code wie folgt anpassen:

// Empfangen des Anlagenstatus über RS232 und füllen des Buffers
if RS232_Statusabfrage == EIN and event(readrs232(Rawdata1, Len1)) then \\
Buffer = split(Rawdata1, 0u16, Len1); \\
if after(RS232_Statusabfrage == EIN, 3000u64) then DataParsingWP = EIN endif \\
endif

// Parsen der einzelnen Informationsblöcke der Wärmepumpendaten
if DataParsingWP == EIN then ...

So würde das Parsen immer erst 3 Sekunden nach dem RS232 Request starten und eine bei change() mögliche Mehrfachauswertung der Rohdaten wäre vermieden.

**Jambala** · 06.03.2014, 05:42

Hier eine aktualisierte Version des Makros bei der die erste Auswertung der Rohdaten immer nur 3 Sekunden nach der RS232 Abfrage erfolgt.

Damit kann pro Anfrage an die Wärmepumpe auch nur 1x eine Auswertung der Daten erfolgen.

Das Makro konnte ich aufgrund fehlender Luxtronik1 nicht live testen.

Viele Grüße

Michael

Angehängte Dateien

Alpha_Innotec_Luxtronik1_v5.lib.zip (6,1 KB, 8x aufgerufen)

**Matthias** · 06.03.2014, 09:42

Zitat von Jambala Beitrag anzeigen

Hier eine aktualisierte Version des Makros bei der die erste Auswertung der Rohdaten immer nur 3 Sekunden nach der RS232 Abfrage erfolgt.

Damit kann pro Anfrage an die Wärmepumpe auch nur 1x eine Auswertung der Daten erfolgen.

Das Makro konnte ich aufgrund fehlender Luxtronik1 nicht live testen.

Viele Grüße

Michael

Hallo Michael,

danke für Deine Mühe.
Du hast zwei Fehler im Makro.

Die

if after(RS232_Statusabfrage == EIN, 3000u64)
if after(RS232_Comfortabfrage == EIN, 3000u64)

müssen aus den übergeordneten if-Abfragen raus. Sollte ja an der Logik nichts ändern.

Bringt trotzdem alles nichts. Meine 20s wollen nicht weichen.
Habe jetzt sogar schon eine sequentielle Abarbeitung der Rohdaten nach folgendem Schema erzwungen:

[highlight=epc]
if change(DataParsingWPStep) and (DataParsingWPStep == 6) and Data_Fehler1 != $$ then \\
/* Parsen von Fehler 1 */; \\
...
DataParsingWPStep = 7; \\
endif

if change(DataParsingWPStep) and (DataParsingWPStep == 7) and Data_Fehler2 != $$ then \\
/* Parsen von Fehler 2 */; \\
...
DataParsingWPStep = 8; \\
endif

if change(DataParsingWPStep) and (DataParsingWPStep == 8) and Data_Fehler3 != $$ then \\
/* Parsen von Fehler 3 */; \\
...
DataParsingWPStep = 9; \\
endif
[/highlight]

Fehlerbild bleibt das Selbe (20s delay).
Es macht langsam echt keinen Spaß mehr..

Grüße
Matthias

**saft6luck** · 06.03.2014, 10:08

Zitat von Jambala Beitrag anzeigen

Ursprünglich hatte ich das Verständnis, dass der EibPC die RS232 Daten intern zwischenspeichert und dann als Block in den Buffer schiebt. Tatsächlich wird der Datensatz (trotzdem er kurz ist) aber offensichtlich in mehreren Schritten in den Buffer geschrieben:

@ 22:51:57.639, Luxtronik1: RS232 Daten empfangen (Buffer=122 Byte
@ 22:51:57.707, Luxtronik1: RS232 Daten empfangen (Buffer=335 Byte
@ 22:51:57.752, Luxtronik1: RS232 Daten empfangen (Buffer=555 Byte
@ 22:51:57.797, Luxtronik1: RS232 Daten empfangen (Buffer=646 Byte

Was ich dabei aber nicht verstehe: Warum wird der Inhalt immer mehr? Das macht doch gar keinen Sinn.

Ich verstehe zwar jetzt, warum eine Längenabfrage irgendwann den endgültigen Wert erreicht, wann wird denn dann aber der Buffer wieder gelöscht? Muss man das u.U. händisch machen???

Das sollte aus meiner Sicht das change() der Datenauswertung unnötig häufig auslösen. In diesem Beispiel wird die gesamte Auswertung 4x pro Request an die WP angestossen.

Am Ende bin ich doch froh, dass meine Beobachtung richtig war

Da hier einige "Spezialisten" Ihre WP alle 30 Sekunden abgefragt haben, würden so alle 7,5 Sekunden die Datenauswertung mit jeweils ca. 800 Zeilen Code durchlaufen werden. Das kann ich mir schon als Ursache für Performance Probleme vorstellen. Insbesondere wenn daneben noch andere Makros und eine umfangreiche Visu läuft.

Die verwenden alle keinen eibPC.
Aber wer noch weiteren Code laufen hat, wird hier evtl. Probleme bekommen, so wie bei mir.

Bleibt die Frage, was der eibPC macht, wenn die Laufzeit derart ansteigt. Michael hat Probleme bei über 900ms angegeben, nur welche Probleme sind das?

**saft6luck** · 06.03.2014, 10:12

Zitat von Matthias Beitrag anzeigen

Fehlerbild bleibt das Selbe (20s delay).

Und der Fehler verschwindet, wenn das Makro raus ist?

**Jambala** · 06.03.2014, 10:36

Zitat von saft6luck Beitrag anzeigen

Was ich dabei aber nicht verstehe: Warum wird der Inhalt immer mehr? Das macht doch gar keinen Sinn.

Ich verstehe zwar jetzt, warum eine Längenabfrage irgendwann den endgültigen Wert erreicht, wann wird denn dann aber der Buffer wieder gelöscht? Muss man das u.U. händisch machen???

Wieso macht das keinen Sinn?

Der Datensatz der Luxtronik hat eine Größe von ca. 640Bytes.

Diese Daten werden in mehreren Einzelblöcken (hier 4) aus dem interen Speicher in die Buffer Variable geschrieben.

Warum das so ist und nicht direkt die gesamte Variable in einem Zyklus gefüllt wird, kann nur Michael beantworten, aber grundsätzlich falsch ist diese Vorgehensweise nicht (man muß es nur wissen um vernünftig programmieren zu können).

Der Buffer wird in der Praxis immer weiter gefüllt, bis sein Ende erreicht ist. Dann werden die vorhandenen Daten wieder von vorne an überschrieben.

Bei stark wechselnden Datensatzlängen, würde ich den Buffer nach jeder Verarbeitung manuell löschen (Buffer = $$), da er meiner Meinung nach nicht von selbst gelöscht wird.

**Matthias** · 06.03.2014, 12:02

Zitat von Jambala Beitrag anzeigen

Der Buffer wird in der Praxis immer weiter gefüllt, bis sein Ende erreicht ist. Dann werden die vorhandenen Daten wieder von vorne an überschrieben.

Bei stark wechselnden Datensatzlängen, würde ich den Buffer nach jeder Verarbeitung manuell löschen (Buffer = $$), da er meiner Meinung nach nicht von selbst gelöscht wird.

Hey Michael,

ich versteh die Aussage nicht.
Du leerst den Buffer (und Rawdata) ja sowieso am Start jedes Abfragezyklus?!
Oder was meinst Du?

Das mit dem Verhalten des Füllens des Buffers ist mir klar.

Grüße
Matthias

**Matthias** · 06.03.2014, 12:03

Zitat von saft6luck Beitrag anzeigen

Und der Fehler verschwindet, wenn das Makro raus ist?

Natürlich, sind würd ich ja hier nicht so einen Wind machen..

**saft6luck** · 06.03.2014, 12:30

Zitat von Matthias Beitrag anzeigen

Natürlich, sind würd ich ja hier nicht so einen Wind machen..

Ja, dacht ich mir ja, nur was bleibt denn dann noch, also wie sieht das restliche Programm jetzt aus?

Ankündigung

Anlagenstatus einer Alpha Innotec Wärmepumpe (Luxtronik 1.0)

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar