Simboli personalizzati. Errori, bug, domande, suggerimenti. - pagina 27

Nuovo commento
 
Stanislav Korotky:

L'aggiunta di tick uno a uno (in particolare da EURUSD su MQ Demo) a un nuovo simbolo personalizzato vuoto dà errore 5310 (non immediatamente, ma in un ciclo da una data arbitraria).

Cosa c'è che non va? Come faccio a sapere quali zecche specifiche vengono rimproverate? Mettere gli array nel log - nessuna violazione cronologica lì.

Provate a inserire il controllo delle zecche copiando.
Ho un indicatore sui dati in tempo reale nell'elaborazione dei tick, quando copio CopyClose, a volte scatta l'errore di copia.
Non capisco quale possa essere la ragione. Forse nel tuo caso c'è un errore di copiatura.

Inoltre, in CopyTicks, si copiano un sacco di tick Limit, e poi nel ciclo while, cioè ad ogni iterazione si copia un grande array di tick.
E in CustomTicksAdd si passa lo stesso grande numero di tick all'array.
Prova a copiare un tick e a passare un tick.
State correndo in un ciclo while.

input int Limit = 10000;
input datetime Start = D'2020.06.01';

int fillArray(ulong &_start)
{
  MqlTick array[];
  int size = CopyTicks(_Symbol, array, COPY_TICKS_ALL, _start, Limit);

  if(size <= 0) 
  {
     Print("Ошибка копирования ценовых данных "+_Symbol+" "+(string)size+" ",GetLastError());
     return(size);
  }

  if(size > 0)
  {
    _start = array[size - 1].time_msc + 1;
    if(CustomTicksAdd(symbolName, array) == -1)
    {
      Print("Error:", GetLastError());
      return(-1);
    }
  }
  return(size);
}

...
{
  ulong startMsc = (ulong)Start * 1000;
  while(fillArray(startMsc) > 0);
}
Aggiunto. Non correlato ai simboli personalizzati.
Ho appena catturato nell'indicatore, nel tick real time la causa dell'errore di copia con il periodo M5 con la funzione CopyClose.
La connessione Internet è stata interrotta per alcuni secondi e dopo la connessione è apparso l'errore di copia 4401Lo storico richiesto non è stato trovato
 È strano, il periodo M5 non è ancora cambiato in una nuova barra, ma l'errore è apparso.
 
Roman:

Prova a inserire il controllo per la copia delle zecche.
Nel mio indicatore su dati in tempo reale in elaborazione tick, quando si copia CopyClose, a volte si verifica un errore di copia.
Non capisco quale possa essere la ragione. Forse nel tuo caso c'è un errore di copiatura.

Inoltre, in CopyTicks, si copiano un sacco di tick Limit, e poi nel ciclo while, cioè ad ogni iterazione si copia un grande array di tick.
E in CustomTicksAdd si passa lo stesso grande numero di tick all'array.
Prova a copiare un tick e a passare un tick.

Non ci sono errori di copia, il codice ottiene un valore normale del numero di tick copiati (dimensione), l'array è riempito con dati normali per tutto il tempo. Il limite può essere cambiato, ma un errore si verifica a qualsiasi valore significativo da uno a diverse migliaia. Copiare tutti i tick in una volta sola (come in alcuni codici) è ovviamente sbagliato perché può causare un errore di allocazione della memoria e bloccare il thread per molto tempo senza poter mostrare all'utente i progressi. E copiare le zecche in piccoli lotti di 10 (figuriamoci 1) rallenta l'intero processo - questo è inaccettabile.

La variante suggerita è ottimale. E anche se è discutibile per qualcuno, formalmente il codice è corretto (o citare dove mi sbaglio) e il comportamento attuale è un errore, cioè i tick devono essere aggiunti senza il codice 5310.

Inoltre, c'è ancora un problema di lunga data con la cancellazione del database delle zecche. Chiama CustomTicksDelete(symbolName, 0, LONG_MAX); non vuole cancellare tutti i tick e ne lascia alcuni (si osserva non costantemente, ma circa una volta ogni tanto). Se si riavvia l'Expert Advisor, il simbolo personalizzato viene cancellato completamente. Come nel caso di CopyTicks - nessun errore.

 
Se volete scrivere tick senza generare più eventi OnTick, potrebbe essere meglio usare una funzione diversa.
 
Stanislav Korotky:

Forse ci sono zecche con lo stesso ms all'incrocio dei pacchetti e questo conta come un errore?

Solo un'ipotesi

 
Andrey Khatimlianskii:

Forse ci sono zecche con lo stesso ms all'incrocio dei pacchetti e questo conta come un errore?

Solo un'ipotesi.

Si può vedere dal codice che ci sono zecche duplicate. In questo caso, le bandiere delle zecche possono non corrispondere l'una all'altra.

 
fxsaber:
Se avete bisogno di scrivere tick senza generare più eventi OnTick, è meglio usare una funzione diversa.

Sono d'accordo. Farò un tentativo. Ma non vedo perché il metodo attuale non dovrebbe funzionare.

 
Stanislav Korotky:

Non ci sono errori di copia, il codice ottiene un valore normale del numero di tick copiati (dimensione), l'array è riempito con dati normali per tutto il tempo. Il limite può essere cambiato, ma un errore si verifica a qualsiasi valore significativo da uno a diverse migliaia. Copiare tutti i tick in una volta sola (come in alcuni codici) è ovviamente sbagliato perché può causare un errore di allocazione della memoria e bloccare il thread per molto tempo senza poter mostrare all'utente i progressi. E copiare le zecche in piccoli lotti di 10 (figuriamoci 1) rallenta l'intero processo.

La variante suggerita è ottimale. E anche se è discutibile per qualcuno, formalmente il codice è corretto (o citare dove mi sbaglio) e il comportamento attuale è un errore, cioè i tick devono essere aggiunti senza il codice 5310.

Inoltre, c'è ancora un problema di lunga data con la cancellazione del database delle zecche. Chiama CustomTicksDelete(symbolName, 0, LONG_MAX); non vuole cancellare tutti i tick e ne lascia alcuni (si osserva non costantemente, ma circa una volta ogni tanto). Se si riavvia l'Expert Advisor, il simbolo personalizzato viene cancellato completamente. Come nel caso di CopyTicks - nessun errore.

ERRORE_CUSTOM_TICKS_WRONG_ORDER

5310

Arraydi ticknon ordinati per tempo


È possibile che non abbiate il tempo di cancellare le zecche in grandi lotti, perché state sovrascrivendo quelle già esistenti nella prossima iterazione.
Cioè, si sovrappongono l'uno sull'altro come una matrice, mentre vola senza ritardi, quindi la memoria non ha il tempo di essere cancellata quando arriva un altro pacchetto.
Ecco perché ho suggerito di aggiungere una zecca alla volta, ho copiato una zecca alla volta, senza problemi.

Per quanto riguarda la cancellazione del database dei tick, non mi piace la costante LONG_MAX in questo caso.
L'aiuto della funzione CustomTicksDelete dice: Tempo dell'ultimo tick nella storia dei prezzi dall'intervallo specificato da cancellare. Il tempo in millisecondi dal 01.01.1970.
E LONG_MAX è molto più grande di questo valore. Cioè, viene passato un valore più grande, per il quale questo parametro non è progettato.
Cercate di usare il numero corrispondente alla cifra dei millisecondi, cioè 13 valori.

 
fxsaber:

Si può vedere dal codice che ci sono zecche duplicate. In questo caso, le bandiere elementari delle zecche possono non corrispondere.

I tick duplicati nell'array ricevente sono CopyTicks? Come è chiaro che si tratta di zecche duplicate e non delle stesse zecche (le zecche non hanno identificatori unici, dopo tutto)? Anche se ci sono duplicati, in teoria, le zecche con tagli uguali non rompono la sequenza. Infine, si pone la domanda: come si formano i duplicati?

 
Roman:

ERRORE_CUSTOM_TICKS_WRONG_ORDER

5310

Arraydi ticknon ordinati per tempo


È possibile che i grossi pacchetti di zecche non abbiano il tempo di essere cancellati, dato che si sovrascrivono quelli che si hanno già nella prossima iterazione.
Cioè, si sovrappongono l'uno sull'altro come una matrice, mentre vola senza ritardi, quindi la memoria non ha il tempo di essere cancellata quando arriva un altro pacchetto.
Ecco perché ho suggerito di aggiungere una zecca alla volta, ho copiato una zecca alla volta, non ci sono stati problemi.

Non una parola sulla cancellazione, niente viene sovrascritto. Le iterazioni sono cronometrate senza sovrapposizione. Sempre in un carattere personalizzato vuoto - o uno nuovo, o dopo aver cancellato con successo tutte le zecche.

 
Stanislav Korotky:

Ticchettii duplicati nell'array ricevente CopyTicks? Come è chiaro che si tratta di zecche duplicate e non identiche (le zecche non hanno identificatori unici, dopo tutto)? Anche se ci sono duplicati, in teoria, le zecche con tagli uguali non rompono la sequenza. Infine, sorge una domanda: come si formano i duplicati?

Ho guardato il codice più da vicino. Ti mancano le zecche quando le ricevi in lotti. Ci può essere una situazione in cui Ticks[Limit - 1].time_msc == Ticks[Limit + k], k >= 0.

Di conseguenza, quando si aggiunge con un salto, le bandiere potrebbero non corrispondere.


Assicurati che tutte le zecche storiche con lo stesso tempo siano alla fine della porzione. Cioè, l'inizio del prossimo chunk dovrebbe avere un tempo diverso. Altrimenti ci saranno perdite anche quando si scrive su misura.

Se volete usare CopyTicks, il modo più semplice è quello di scartare i tick più estremi con il tempo più lungo dal pacchetto ricevuto. E rendere _start uguale a questo tempo.
1...202122232425262728293031323334
Nuovo commento