Test des "CopyTicks". - page 43

Nouveau commentaire
 
fxsaber:
Confronté à un bug lorsque CopyTicksRange renvoie correctement tous les ticks demandés, mais avec LastError == ERR_HISTORY_TIMEOUT(4403).


Ce n'est pas un bug, c'est une fonctionnalité. C'est la même chose avec CopyTicks, parfois. Je n'ai pas encore trouvé comment utiliser ce "truc".

dans la description de la fonction CopyTicksRange :

ERR_HISTORY_TIMEOUT – время ожидание синхронизации тиков вышло, функция отдала всё что было.

Bien entendu, j'aimerais que les développeurs expliquent ce que signifie cette erreur lorsqu'un tick est reçu avec la fonction CopyTicks. Comment gérer cette erreur. ps : je l'appelle dans un indicateur

 

Veuillez indiquer quelles données doivent être fournies pour résoudre ce problème dans les plus brefs délais.

void OnStart()
{
  MqlTick Ticks[];

  Print(CopyTicksRange(_Symbol, Ticks, COPY_TICKS_INFO, (ulong)D'2020.04.09 10:40:29' * 1000, (ulong)D'2020.04.11' * 1000)); // 8192
  Print(_LastError); // 4407

  ResetLastError();

  MqlTick Ticks2[];

  Print(CopyTicksRange(_Symbol, Ticks2, COPY_TICKS_INFO, (ulong)D'2020.04.09 10:40:30' * 1000)); // 131066
  Print(_LastError); // 0
}


Tiki n'est pas copié, ce qui donne une erreur.

Constant

Valeur

Description

ERR_HISTOIRE_SMALL_BUFFER

4407

Le tableau de réception est trop petit pour contenir toutes les données demandées.


Il est impossible de travailler correctement avec de telles surprises !


A travers le GUI (CTRL+U) les ticks sont pris sans aucun problème.

Nom de recherche: Oshibka 007.
 
fxsaber:

Veuillez indiquer quelles données doivent être fournies pour résoudre ce problème dans les plus brefs délais.

Tiki n'est pas copié, ce qui donne une erreur.

Constant

Valeur

Description

ERR_HISTOIRE_SMALL_BUFFER

4407

Le tableau de réception est trop petit pour contenir toutes les données demandées.

Testé localement de diverses manières - jusqu'à présent, pas de lecture. Besoin de plus de détails :

1. Quelle version du terminal ?

2. Avec quel serveur travaillez-vous ?

3. sur quel personnage le script est-il appelé ?

4. Si l'appel n'est pas effectué avec COPY_TICKS_INFO mais avec COPY_TICKS_ALL, l'erreur ERR_HISTORY_SMALL_BUFFER est-elle également activée ?

Merci !

 
Anton:

Testé localement de différentes manières - jusqu'à présent, pas de lecture. Besoin de détails :

1. Quelle version du terminal ?

2. Avec quel serveur travaillez-vous ?

3. sur quel personnage le script est-il appelé ?

4. Si vous ne l'appelez pas avec COPY_TICKS_INFO mais avec COPY_TICKS_ALL, l'erreur ERR_HISTORY_SMALL_BUFFER sera-t-elle également levée ?

Merci !

  1. 2380.
  2. Tout serveur - voir le point 3.
  3. Symbole personnalisé.
  4. Le drapeau ne change pas le comportement.

ZS Dans la remorque est personnalisé. Créer un symbole à partir de json, importer les ticks, exécuter le script sur le graphique de ce symbole. Veuillez indiquer si elle s'est reproduite ou non.

Dossiers :
EURUSD.zip  896 kb
 
fxsaber:

Veuillez écrire si elle a joué ou non.

Oui, c'est passé sur 2380.

Merci beaucoup ! Je fais le tri.

 
fxsaber:

  1. 2380.
  2. Tout serveur - voir le point 3.
  3. Symbole personnalisé.
  4. Le drapeau ne change pas le comportement.

ZY La remorque est personnalisée. Créer un symbole à partir de json, importer les ticks, exécuter le script sur le graphique de ce symbole. Veuillez écrire si cela s'est reproduit ou non.


Merci encore.

Oui, en 2380, le problème a été accidentellement introduit, puis il a été rapidement corrigé. Mais il a réussi à atteindre la version 2380.

Malheureusement, depuis lors, les nouvelles constructions où tous les correctifs sur MetaQuotes-Demo n'était pas encore.

Vous pouvez soit revenir à une version précédente, soit attendre la prochaine version de MetaQuotes-Demo.
 
Anton:
Vous pouvez soit revenir à une version précédente, soit attendre la prochaine version de MetaQuotes-Demo.

Merci, pour l'instant la construction précédente est réelle. Le 2380 a fait beaucoup...

 

MT5 dernière version, build 2361. Créez un symbole à partir de json, importez les ticks, exécutez l'EA sur un graphique de ce symbole.

EA

void OnTick()
{
  MqlTick Tick={0};
  if(SymbolInfoTick(_Symbol,Tick))
  {
    MqlTick OldTicks[];
    Print(CopyTicks(_Symbol,OldTicks,COPY_TICKS_ALL));
    Print(GetLastError());
    Print(CopyTicks(_Symbol,OldTicks,COPY_TICKS_ALL,(ulong)D'2020.04.06 00:00:00' * 1000));
    Print(GetLastError());
  }
  ExpertRemove();
}

Paramètres

[Tester]
Expert=test.ex5
Symbol=AUDNZD.RannForex
Period=M1
Optimization=0
Model=4
FromDate=2020.04.08
ToDate=2020.04.09
ForwardMode=0
Deposit=10000000
Currency=USD
ProfitInPips=1
Leverage=100
ExecutionMode=0
OptimizationCriterion=6
Visual=0

1. Compte de compensation.

1.1. Avec les dates données, la sortie est similaire à la vraie : 2000 0 2000 0.

1.2. Lorsque les dates sont modifiées en 07.04.2020-08.04.2020, la sortie devient étrange : -1 4004 1 0.

Tout d'abord, pourquoi l'erreur apparaît-elle dans le premier cas ? Deuxièmement, pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.

2. Compte de couverture.

2.1. Avec les dates données, la sortie devient étrange : 2000 0 1 0.

Pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.

2.2. Lorsque les dates passent au 07.04.2020-08.04.2020, la sortie cesse d'être étrange, mais reste la même : 2000 0 1 0.


D'où les questions suivantes : pourquoi les CopyTicks à paramètres fixes dépendent-ils non seulement des dates de test, mais aussi du type de compte ? Ou je ne comprends pas quelque chose et je fais quelque chose de mal ?

Cela rend le travail très difficile, veuillez corriger si possible. Avez-vous réussi à le reproduire ? Vous avez besoin de quelque chose d'autre de ma part pour la reproduction ? Merci.

Dossiers :
AUDNZD.zip  2448 kb
 
traveller00:

D'où les questions suivantes : pourquoi CopyTicks avec des paramètres fixes dépend-il non seulement des dates de test, mais aussi du type de compte ? Ou est-ce que je comprends mal quelque chose et fais quelque chose de mal ?

Dépendance vis-à-vis du type de compte - vous pouvez imaginer les raisons. Je ne dirais pas que c'est correct. Les symboles d'échange avec la dernière histoire - les développeurs doivent bien penser une fois là, ce qu'il faut en faire sur la haie, etc.

Je n'utilise pas moi-même les CopyTicks dans Tester. Les premières 24 heures ne sont pas importantes. Si vous avez vraiment besoin de signaux de négociation clairs, ne négociez pas le premier jour.

 
traveller00:

MT5 dernière version, build 2361. Créez un symbole à partir de json, importez les ticks, exécutez l'EA sur un graphique de ce symbole.

EA

Paramètres

1. Compte de compensation.

1.1. Avec les dates données, la sortie est similaire à la vraie : 2000 0 2000 0.

1.2. Lorsque les dates sont modifiées en 07.04.2020-08.04.2020, la sortie devient étrange : -1 4004 1 0.

Tout d'abord, pourquoi l'erreur apparaît-elle dans le premier cas ? Deuxièmement, pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.

2. Compte de couverture.

2.1. Avec les dates données, la sortie devient étrange : 2000 0 1 0.

Pourquoi le deuxième cas ne prend-il qu'un seul tic ? La date de la demande de coche n'a pas changé.

2.2. Lorsque les dates passent au 07.04.2020-08.04.2020, la sortie cesse d'être étrange, mais reste la même : 2000 0 1 0.


D'où les questions suivantes : pourquoi les CopyTicks à paramètres fixes dépendent-ils non seulement des dates de test, mais aussi du type de compte ? Ou je ne comprends pas quelque chose et je fais quelque chose de mal ?

Cela rend le travail très difficile, veuillez corriger si possible. Avez-vous réussi à le reproduire ? Vous avez besoin de quelque chose d'autre de ma part pour la reproduction ? Merci.

La toute première course. En regardant les logs du testeur.

2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: symbol to be synchronized
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: symbol synchronized, 3720 bytes of symbol info received
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: load 23 Kb of history data to synchronize in 0:00:00.009
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: history synchronized from 2020.04.06 to 2020.04.08
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: ticks synchronization started
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: load 567 Kb of tick data to synchronize in 0:00:00.031
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex: history ticks synchronized from 2020.04.08 to 2020.04.08
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex,M1: history cache allocated for 3897 bars and contains 2868 bars from 2020.04.06 00:05 to 2020.04.07 23:59
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex,M1: history begins from 2020.04.06 00:05
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex,M1 (MetaQuotes-Demo): generating based on real ticks
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex,M1: testing of Experts\test.ex5 from 2020.04.08 00:00 to 2020.04.09 00:00 started
2020.04.21 10:53:10.573 Core 01 AUDNZD.RannForex : real ticks begin from 2020.04.08 00:00:00
2020.04.21 10:53:10.573 Core 01 2020.04.08 00:01:11   -1
2020.04.21 10:53:10.573 Core 01 2020.04.08 00:01:11   4004
2020.04.21 10:53:10.573 Core 01 2020.04.08 00:01:11   1
2020.04.21 10:53:10.573 Core 01 2020.04.08 00:01:11   0
2020.04.21 10:53:10.573 Core 01 2020.04.08 00:01:11   ExpertRemove() function called
2020.04.21 10:53:10.573 Core 01 removed itself within OnTick

Le testeur a synchronisé les tics pour un seul jour, le 8 avril. C'est-à-dire qu'il n'y a pas de tiques avant le 8 avril.

Au début, nous avons obtenu l'erreur 4004 (pas assez de mémoire pour les ticks demandés). C'est un message invalide, nous allons l'examiner. Il semble que ce soit parce que la demande avec les paramètres par défaut se trouve à la limite des ticks existants.

La requête suivante vous a donné, à juste titre, 1 coche. Parce que depuis 2020.04.06 00:00:00 jusqu'au testeur actuel, lorsque le premier tick est arrivé, il n'y a qu'un seul tick existant.

Ajustons un peu l'EA

void OnTick()
  {
   MqlTick Tick= {0};
   if(SymbolInfoTick(_Symbol,Tick))
     {
      MqlTick OldTicks[];
      Print(CopyTicks(_Symbol,OldTicks,COPY_TICKS_ALL));
      if(GetLastError()!=0)
         return;
      Print(GetLastError());
      Print(CopyTicks(_Symbol,OldTicks,COPY_TICKS_ALL,(ulong)D'2020.04.06 00:00:00' * 1000));
      Print(GetLastError());
     }
   ExpertRemove();
  }

et nous voyons, qu'à partir de la deuxième tique, les tiques ont commencé à être ramassées. Dans les deux cas, il s'agit de 2 ticks.

2020.04.21 11:14:13.256 Core 01 AUDNZD.RannForex : real ticks begin from 2020.04.08 00:00:00
2020.04.21 11:14:13.256 Core 01 2020.04.08 00:01:11   -1
2020.04.21 11:14:13.256 Core 01 2020.04.08 00:01:19   2
2020.04.21 11:14:13.256 Core 01 2020.04.08 00:01:19   0
2020.04.21 11:14:13.256 Core 01 2020.04.08 00:01:19   2
2020.04.21 11:14:13.256 Core 01 2020.04.08 00:01:19   0
2020.04.21 11:14:13.256 Core 01 2020.04.08 00:01:19   ExpertRemove() function called

En d'autres termes, l'hypothèse relative à l'erreur de demande sur la limite du tick s'est avérée correcte.

Changeons la date de début au 7 avril.

2020.04.21 11:18:17.775 Core 01 AUDNZD.RannForex: history ticks synchronized from 2020.04.07 to 2020.04.08
2020.04.21 11:18:17.775 Core 01 AUDNZD.RannForex,M1: history cache allocated for 3486 bars and contains 1429 bars from 2020.04.06 00:05 to 2020.04.06 23:59
2020.04.21 11:18:17.775 Core 01 AUDNZD.RannForex,M1: history begins from 2020.04.06 00:05
2020.04.21 11:18:17.775 Core 01 AUDNZD.RannForex,M1 (MetaQuotes-Demo): generating based on real ticks
2020.04.21 11:18:17.775 Core 01 AUDNZD.RannForex,M1: testing of Experts\test.ex5 from 2020.04.07 00:00 to 2020.04.09 00:00 started
2020.04.21 11:18:17.775 Core 01 AUDNZD.RannForex : real ticks begin from 2020.04.07 00:00:00
2020.04.21 11:18:17.775 Core 01 2020.04.07 00:01:28   -1
2020.04.21 11:18:17.775 Core 01 2020.04.07 00:01:28   4004
2020.04.21 11:18:17.775 Core 01 2020.04.07 00:01:28   1
2020.04.21 11:18:17.775 Core 01 2020.04.07 00:01:28   0
2020.04.21 11:18:17.775 Core 01 2020.04.07 00:01:28   ExpertRemove() function called
2020.04.21 11:18:17.775 Core 01 removed itself within OnTick

Tout est identique, à l'exception du fait que les ticks sont synchronisés pour 2 jours déjà - la base de données du testeur contient les ticks des 7 et 8 avril.

Nous avons reporté la date de début au 8 avril. Et nous voyons le résultat attendu

2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex: load 47 bytes of history data to synchronize in 0:00:00.000
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex: history synchronized from 2020.04.06 to 2020.04.08
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex: ticks synchronization started
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex: load 54 bytes of tick data to synchronize in 0:00:00.000
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex: history ticks synchronized from 2020.04.07 to 2020.04.08
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex,M1: history cache allocated for 3897 bars and contains 2868 bars from 2020.04.06 00:05 to 2020.04.07 23:59
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex,M1: history begins from 2020.04.06 00:05
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex,M1 (MetaQuotes-Demo): generating based on real ticks
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex,M1: testing of Experts\test.ex5 from 2020.04.08 00:00 to 2020.04.09 00:00 started
2020.04.21 11:20:51.257 Core 01 AUDNZD.RannForex : real ticks begin from 2020.04.07 00:00:00
2020.04.21 11:20:51.257 Core 01 2020.04.08 00:01:11   2000
2020.04.21 11:20:51.257 Core 01 2020.04.08 00:01:11   0
2020.04.21 11:20:51.257 Core 01 2020.04.08 00:01:11   2000
2020.04.21 11:20:51.257 Core 01 2020.04.08 00:01:11   0
2020.04.21 11:20:51.257 Core 01 2020.04.08 00:01:11   ExpertRemove() function called
2020.04.21 11:20:51.257 Core 01 removed itself within OnTick

Parce qu'il y a plus de tics dans le testeur que dans la toute première exécution. Et cela n'a rien à voir avec la couverture et la compensation.

1...363738394041424344454647
Nouveau commentaire
Raison: