Ich habe einen benutzerdefinierten ProScreener (ProBuilder), der ca. 33 Instrumente in Echtzeit auswertet, implementiert in zwei unabhängigen Skripten, die dieselbe Logik zur Berechnung der Zeitfenster-Spanne (Range) verwenden. Am 02.10.2026 änderte sich für den DAX eine interne Variable meines Codes (die den höchsten innerhalb eines festen Zeitfensters erreichten Kurs speichert, 00:00–08:59 MESZ plus eine einzige erlaubte Verlängerung bis 09:05) auf der Kerze von 09:00:00–09:05:00 MESZ. Mein Kerzenchart (5-Minuten-Timeframe) zeigt für genau diese Kerze ein Hoch von 25.012,1 — niedriger als der Wert, den mein Code bereits vor 09:00 Uhr akkumuliert hatte (25.063,9). Meine Logik (IF high > CajaMax THEN CajaMax = high) hätte diesen Wert also gar nicht ändern dürfen. Trotzdem erfasste mein Skript als Endwert 25.111 — eine Differenz von 99 Punkten gegenüber dem im Chart angezeigten Hoch dieser Kerze. Fast zwei Stunden später (10:53 MESZ) hatte sich dieselbe interne Variable erneut geändert, diesmal auf 25.143,9 — ein dritter, abweichender Wert, weit außerhalb jedes Zeitfensters, das meine Logik zur Berechnung dieser Spanne verwendet. Ich konnte dies zum selben Zeitpunkt identisch in meinen zwei unabhängigen Skripten bestätigen, was einen eigenen Programmierfehler ausschließt und auf ein Problem an der Datenquelle hindeutet. Soweit ich weiß, führt ProScreener den gesamten Code nach Abschluss jedes Scan-Zyklus über das gesamte Instrumenten-Universum erneut von der ersten Kerze an aus. Könnte eine verspätete Korrektur/Konsolidierung einer bereits “geschlossenen” Kerze durch den Datenfeed erklären, dass sich meine akkumulierte Variable bei späteren Neuberechnungen ändert, Stunden nach dieser Kerze? Ich habe dasselbe Muster (eine Bereichsgrenze mit einem Wert, der nicht dem Chart entspricht) bei anderen Instrumenten (CL, GBPUSD) in früheren Sitzungen reproduziert. Plattformversion: [bitte ergänzen] Kontotyp / Datenfeed: [bitte ergänzen] Instrument / genaues Ticker-Symbol: DAX, [genauen Code ergänzen] Chart-Timeframe: 5 Minuten ProScreener-Timeframe: [bitte ergänzen] Eingestellte Zeitzone: MESZ (UTC+2) Datum der Reproduktion: 02.10.2026 Beobachtete Werte (DAX): – Reales Box-Hoch (Chart, Box-Indikator): 25.063,9 – Hoch der Kerze 09:00–09:05 (Chart): 25.012,1 – Intern erfasster Wert (~09:00–09:55): 25.111 – Später intern erfasster Wert (10:53 MESZ, gleicher Tag): 25.143,9 Ich kann bei Bedarf den relevanten Code-Ausschnitt (nur Box-Konstruktion, ohne die proprietäre Trading-/Scoring-Logik) sowie Screenshots von Chart und Screener-Ausgabe für diesen Fall nachreichen.
Anbei der relevante Codeausschnitt (nur Berechnung der Sitzungsspanne/Box, ohne die eigentliche Handelslogik), der das in der Anfrage beschriebene Verhalten reproduziert. CajaMax/CajaMin entsprechen den im Text genannten internen Werten; UltimaExtCaja ist eine zusätzlich eingebaute Diagnosevariable, die die Uhrzeit der letzten Änderung von CajaMax/CajaMin speichert.
// ============================================================
// Codeausschnitt zur Fehlermeldung an ProRealTime-Support
// DAX, Sitzung 02.10.2026 — Berechnung der Sitzungsspanne (Box)
// ------------------------------------------------------------
// Auszug OHNE die eigentliche Handels-/Scoring-Logik (Entry, SL,
// TP1/TP2, Filter, Score-Gewichtung usw.) — nur der Teil, der die
// Variablen CajaMax/CajaMin (Session-Hoch/-Tief) berechnet und der
// im gemeldeten Fall das beschriebene Verhalten zeigt. Identisch in
// den zwei unabhaengigen Skripten, die denselben Fehler zeigen.
// ============================================================
// --- Sommerzeit-Berechnung (Europe/Berlin, automatisch) ---
aDay = date MOD 100
aMonth = (date MOD 10000 - date MOD 100) / 100
aDayOfWeek = DayOfWeek
IF aDayOfWeek = 7 THEN
aDayOfWeek0Dom = 0
ELSE
aDayOfWeek0Dom = aDayOfWeek
ENDIF
aLastSunDay = aDay - aDayOfWeek0Dom
IF aMonth >= 4 AND aMonth <= 9 THEN
aAutoDST = 1
ELSIF aMonth = 3 THEN
IF aLastSunDay >= 25 THEN
aAutoDST = 1
ELSE
aAutoDST = 0
ENDIF
ELSIF aMonth = 10 THEN
IF aLastSunDay >= 25 THEN
aAutoDST = 0
ELSE
aAutoDST = 1
ENDIF
ELSE
aAutoDST = 0
ENDIF
IF aAutoDST = 1 THEN
berlinOffset = 2
ELSE
berlinOffset = 1
ENDIF
utcStartHour = 0
utcEndHour = 7
HoraInicioBox = (utcStartHour + berlinOffset) * 10000
HoraFinBox = (utcEndHour + berlinOffset) * 10000 - 100
// --- Erkennung Sitzungswechsel (taeglicher Reset um 00:00 CET/CEST) ---
NewSessionCET = (time < time[1]) OR (DayOfWeek <> DayOfWeek[1] AND DayOfWeek[1] = 5)
// --- Initialisierung / Carry-forward, jede Kerze ---
CajaMax = CajaMax[1]
CajaMin = CajaMin[1]
inBox = inBox[1]
// Diagnosevariable (read-only, nur zur Fehlersuche hinzugefuegt):
// speichert die Uhrzeit (HHMMSS) der letzten Aenderung von CajaMax/CajaMin.
UltimaExtCaja = UltimaExtCaja[1]
// --- Taeglicher Reset ---
IF NewSessionCET THEN
CajaMax = 0
CajaMin = 0
UltimaExtCaja = 0
ENDIF
// --- Aufbau der Sitzungsspanne (00:00-08:59 CEST im gemeldeten Fall) ---
IF time > HoraInicioBox AND time <= HoraFinBox THEN
IF NewSessionCET OR inBox = 0 THEN
CajaMax = high
CajaMin = low
inBox = 1
UltimaExtCaja = time
ELSE
IF high > CajaMax THEN
CajaMax = high
UltimaExtCaja = time
ENDIF
IF low < CajaMin THEN
CajaMin = low
UltimaExtCaja = time
ENDIF
ENDIF
ELSE
inBox = 0
ENDIF
// --- Einzige erlaubte Verlaengerung: die eine Kerze, die HoraFinBox kreuzt ---
IF time > HoraFinBox AND time[1] <= HoraFinBox THEN
IF CajaMax > 0 AND CajaMin > 0 THEN
IF high > CajaMax THEN
CajaMax = high
UltimaExtCaja = time
ENDIF
IF low < CajaMin THEN
CajaMin = low
UltimaExtCaja = time
ENDIF
ENDIF
ENDIF
// ------------------------------------------------------------
// Am Ende des Skripts (ProScreener-Ausgabe) werden u.a. folgende
// Werte angezeigt, auf die sich die Fehlermeldung bezieht:
// CajaMax, CajaMin -> interner Session-Hoch/-Tief-Wert
// UltimaExtCaja -> Uhrzeit der letzten Aenderung (Diagnose)
//
// Beobachtete Werte fuer DAX, 02.10.2026:
// Reales Box-Hoch (Chart): 25.063,9
// Hoch der Kerze 09:00-09:05 (Chart): 25.012,1
// CajaMax, erstmals beobachtet (~09:xx): 25.111
// CajaMax, spaeter beobachtet (10:53 CEST):25.143,9
// UltimaExtCaja zeigte in beiden Faellen: 09:00:00
// -----------------------------------------------------------
In der ProRealTime-Sprache sind diese Anweisungen:
CajaMax = CajaMax[1]
CajaMin = CajaMin[1]
inBox = inBox[1]
UltimaExtCaja = UltimaExtCaja[1]
überflüssig, da ALLE Variablen mit demselben Wert, den sie in der vorherigen Kerze hatten, in die neue Kerze übernommen werden.
Die Verwendung von [1] für den Zugriff auf den Wert der vorherigen Kerze ist also nur dann sinnvoll, wenn dieser Wert in der Zwischenzeit geändert wurde.
Das dient allerdings nur der Dokumentation; es ist mit Sicherheit nicht die Ursache für dein Problem.
Warum fragst du nicht die KI?
Ich weiß nicht, ob dir diese hier weiterhelfen kann:
https://ai.prorealcode.com/
ansonsten kannst du es mit ChatGPT, Gemini, Copilot usw. versuchen.
Danke für den Hinweis zu den [1]-Zeilen — verstanden, das ist nur Dokumentation und sicher nicht die Ursache.
Bevor ich die eigentliche Frage wiederhole, die naheliegenden Alternativerklärungen habe ich bereits geprüft und ausgeschlossen:
- Alle betroffenen Scripts/Instrumente laufen auf demselben Timeframe (M5) — kein Timeframe-Unterschied zwischen ProScreener und Chart.
- Das Problem tritt auch bei Instrumenten auf, die eindeutig nur einem Symbol/Feed zugeordnet sind — kein Symbol-Mapping- oder Feed-Unterschied.
- Die Sitzungserkennung in meinem Code basiert ausschließlich auf
time/DayOfWeek der jeweiligen Kerze, nicht auf deren Position innerhalb der ProScreener-Rekonstruktion. - Laut Handbuch verarbeitet ProScreener maximal die letzten 256 Kerzen (1.024 auf Premium-Plattformen) — bei M5 deckt das aber meine komplette Sitzung plus mehrere Stunden danach ab, das erklärt die Größenordnung meines Falls nicht.
Ich habe die Frage zusätzlich mit Perplexity, ChatGPT und der ProRealCode-KI (ai.prorealcode.com) geprüft, wie vorgeschlagen. Keine davon konnte eine offizielle Dokumentation oder einen Forenbeitrag mit Moderator-Bestätigung finden, die bestätigt, dass der High/Low-Wert einer bereits abgeschlossenen Kerze sich zwischen zwei ProScreener-Zyklen ändern kann — alle drei stufen das explizit als “nicht bestätigt” ein, nicht als widerlegt.
Die eigentliche Frage bleibt also: Kann der High/Low-Wert einer bereits abgeschlossenen Kerze zwischen zwei vollständigen ProScreener-Zyklen (für dasselbe Instrument, Konto, Feed und Timeframe) unterschiedlich ausfallen? In meinem Fall änderte sich mein akkumulierter Session-Höchstwert für den DAX zwischen 09:00 und 10:53 Uhr gleich zweimal (25.111 → 25.143,9), obwohl die betroffene Kerze laut Chart (Hoch 25.012,1) diese Änderung logisch nicht hätte auslösen dürfen — und das bei einer Kerze, die zu diesem Zeitpunkt längst abgeschlossen war.
Gibt es einen dokumentierten Mechanismus (späte Datenkorrektur/-konsolidierung des Feeds für eine bereits geschlossene Kerze, oder etwas anderes), der das erklären könnte?
