Vladimir, il problema non si verifica nel tester... Come mai c'è questo problema? O perché c'è solo un Expert Advisor nel tester?
Ho anche suggerito nella SD che l'unico cambiamento era mettere il secondo EA su una coppia diversa...
L'intero ambiente di trading nel tester è preparato in anticipo. Tutto è su un piatto. Non c'è da preoccuparsi. L'ambiente di trading reale è diverso, in caso di comportamento non standard (lavorando sul timeframe di qualcun altro e/o sul simbolo di qualcun altro) dobbiamo preoccuparci della pertinenza dell'ambiente di trading.
Karputov Vladimir: In un terminale (su timeframe M15 c'erano EAs) non ha funzionato su un simbolo - sono sicuro al 99% che il problema è che quando si usa il timeframe di qualcun altro è necessario "smanettare" la storia tutto il tempo. Penso che sia meglio farlo tramite CopyTime().
E CopyRates() fa a pezzi la storia. C'è tempo nella struttura...
Questo non è un errore. State lavorando sul tempo di qualcun altro. In tal caso, dovete occuparvi voi stessi dei dati sul calendario di qualcun altro per assicurarvi che siano aggiornati.
Personalmente non vedo alternative.
Non è un fatto che non sappiamo come funzionaSERIES_LASTBAR_DATE. Può essere che non ci sia bisogno di aggiornare nulla perché il tempo dell'ultima barra può essere calcolato usando TimeCurrent() del simbolo specificato. Dobbiamo chiedere agli sviluppatori.
Ma finora un fatto chiaro e indiscutibile è che se due variabili sono impostate come vere, allora insieme (quando si controlla &&) queste variabili daranno anche vero.
Il problema della caduta della cache degli altri strumenti/TF esiste.
Il controllo degli errori e l'attesa in loop per il caricamento non sempre aiutano. Abbiamo parlato con Service Desk, ma MQ non ha fatto alcun progresso, solo un accenno:
Support Team2016.02.29 11:45
Il sospetto è che i dati storici siano scaricati dal timeout.
Ci sono 2 soluzioni:
1. accedere ai dati più spesso di una volta ogni 3 minuti
2. Mettere qualche indicatore molto semplice sui dati. Il volume, per esempio. Non c'è calcolo, solo un buffer è occupato. La disponibilità dell'indicatore manterrà la cache storica in memoria indipendentemente dalla frequenza di accesso
Il 2° suggerimento non funziona, gli indicatori sono chiamati tutto il tempo, ma ad un certo punto la cache fallisce e diventa impossibile ottenere i dati.
Restituisce il numero di barre nella storia per il simbolo del periodo corrispondente. Ci sono 2 varianti della funzione.
Solo la seconda opzione è interessante.
Richiedere il numero di barre su un dato intervallo
intBars(
string symbol_name, // имя символаENUM_TIMEFRAMES timeframe, // периодdatetime start_time, // с какой датыdatetime stop_time // по какую дату
);
Risulta che tra 2016.06.22 00:00:00 e 2016.06.24 00:00:00 ci sono tre barre giornaliere e tra 2016.06.22 00:01 e 2016.06.24 00:00:00 ci sono solo due...
Dmitry Fedoseev: Il limite di tempo superiore non è incluso nell'intervallo in cui si determina il numero di barre.
Dimitri, non è strano? È apparsa una nuova barra, ma non la contiamo ancora.
Ascolta, non è la ragione di tale comportamento del SeriesInfoInteger(_Symbol, PERIOD_D1, SERIES_LASTBAR_DATE); ? È apparsa una nuova barra, il codice disponibile in tick viene eseguito, ma il tempo non è ancora preso in considerazione?
Vladimir, il problema non si verifica nel tester... Come mai c'è questo problema? O perché c'è solo un Expert Advisor nel tester?
Ho anche suggerito nella SD che l'unico cambiamento era mettere il secondo EA su una coppia diversa...
In un terminale (su timeframe M15 c'erano EAs) non ha funzionato su un simbolo - sono sicuro al 99% che il problema è che quando si usa il timeframe di qualcun altro è necessario "smanettare" la storia tutto il tempo. Penso che sia meglio farlo tramite CopyTime().
Questo non è un errore. State lavorando sul tempo di qualcun altro. In tal caso, dovete occuparvi voi stessi dei dati sul calendario di qualcun altro per assicurarvi che siano aggiornati.
Personalmente non vedo alternative.
Non è un fatto che non sappiamo come funzionaSERIES_LASTBAR_DATE. Può essere che non ci sia bisogno di aggiornare nulla perché il tempo dell'ultima barra può essere calcolato usando TimeCurrent() del simbolo specificato. Dobbiamo chiedere agli sviluppatori.
Ma finora un fatto chiaro e indiscutibile è che se due variabili sono impostate come vere, allora insieme (quando si controlla &&) queste variabili daranno anche vero.
Il problema della caduta della cache degli altri strumenti/TF esiste.
Il controllo degli errori e l'attesa in loop per il caricamento non sempre aiutano. Abbiamo parlato con Service Desk, ma MQ non ha fatto alcun progresso, solo un accenno:
Il sospetto è che i dati storici siano scaricati dal timeout.
Ci sono 2 soluzioni:
1. accedere ai dati più spesso di una volta ogni 3 minuti
2. Mettere qualche indicatore molto semplice sui dati. Il volume, per esempio. Non c'è calcolo, solo un buffer è occupato. La disponibilità dell'indicatore manterrà la cache storica in memoria indipendentemente dalla frequenza di accesso
Il 2° suggerimento non funziona, gli indicatori sono chiamati tutto il tempo, ma ad un certo punto la cache fallisce e diventa impossibile ottenere i dati.
Ho risolto il problema con questa stampella - chiamo questo codice ogni 150 secondi per tutti gli strumenti/FT coinvolti:
Funziona abbastanza velocemente, l'errore 4806 sembra scomparire dopo questo aggiornamento.
La prego di commentare un altro malinteso.
Bars
Restituisce il numero di barre nella storia per il simbolo del periodo corrispondente. Ci sono 2 varianti della funzione.
Solo la seconda opzione è interessante.
Testo di Expert Advisor
Capisco che l'ora 00:00:00 appartiene al giorno, proprio come l'ora 00:00:01
Ma... le stampe proposte non sono d'accordo.
Risulta che tra 2016.06.22 00:00:00 e 2016.06.24 00:00:00 ci sono tre barre giornaliere e tra 2016.06.22 00:01 e 2016.06.24 00:00:00 ci sono solo due...
O sto fraintendendo qualcosa?
E se si aggiunge un secondo al tempo della barra corrente
si ottiene quanto segue
Il tempo 2016.06.24 00:00:01 sembra appartenere alla prossima barra o cosa?
Il limite di tempo superiore non è incluso nell'intervallo in cui si determina il numero di barre.
Dimitri, non è strano? È apparsa una nuova barra, ma non la contiamo ancora.
Ascolta, non è la ragione di tale comportamento del SeriesInfoInteger(_Symbol, PERIOD_D1, SERIES_LASTBAR_DATE); ? È apparsa una nuova barra, il codice disponibile in tick viene eseguito, ma il tempo non è ancora preso in considerazione?
Beh, il batterista si è sgonfiato... Ed è stato completamente ignorato...
Vladimir, puoi almeno rispondere a questa domanda?
CopyRates() tira la storia? C'è tempo nella struttura...?
Beh, l'uomo nero si è sgonfiato... Ed è stato totalmente ignorato...
Vladimir, puoi almeno rispondere a questa domanda?