Vérification du stop minimum dans les EAs publiés sur la place de marché. - page 17

 
Vladislav Andruschenko:

Mon conseiller expert capte les mouvements mineurs, il frappe donc le serveur, mais pas avec un stoploss de 1 pip, mais avec un niveau min normal + spread, mais le spread est flottant. C'est pourquoi EA martèle le serveur jusqu'à ce qu'il retrouve un écart normal.

En d'autres termes, au moment de l'ouverture, il vérifie l'arrêt min - reconstruit ses valeurs - puis il frappe le serveur. Mais si vous avez besoin de mettre un stop de 10 pips, vous devez attendre le spread min et piler le serveur.

Frapper le serveur n'est pas une bonne idée. Vous risquez de vous heurter à une interdiction de l'autotrading. (Qui voudrait faire face à des attaques DDOS sur le serveur avec son EA ?)

Tout d'abord, avant d'envoyer une requête, nous devons obtenir le spread, le niveau de stop, ajuster les stops et si le stop est acceptable pour le trading, alors envoyer une requête. Si la taille de l'arrêt n'est pas acceptable, il n'y a pas lieu de déranger qui que ce soit. Si mon serveur avait été pilonné comme ça, je l'aurais tué...

Mais si, après avoir envoyé une demande avec une taille d'arrêt acceptable, nous obtenons à nouveau l'erreur 130 (les conditions de nivellement des arrêts ont changé pendant l'envoi de la demande), nous pouvons alors ajuster la taille de l'arrêt et envoyer la demande (avec une taille acceptable de l'arrêt nouvellement calculé). Le nombre de ces demandes devrait être limité, sinon ce sera un autre bavardage stupide.

Maintenant je vois pourquoi vous n'êtes pas autorisé à entrer dans le marché.

 

c'est une situation légèrement différente ici,

Je ne veux pas ciseler tout le temps.

Naturellement, après l'erreur, il y a un contrôle d'erreur - Slip. Mais cela ne fonctionne pas dans le testeur.

C'est à propos de l'écart flottant.

comme je l'ai écrit ci-dessus - avant d'envoyer une requête - les niveaux de stop sont corrigés et envoyés au serveur, - le serveur renvoie une erreur 130 - Expert Advisor corrige à nouveau le niveau et envoie à nouveau au serveur.

et ainsi de suite.

Le glissement ne fonctionne pas dans le testeur, c'est pourquoi il n'y a pas de délai.

Pour l'instant, j'ai résolu le problème de la façon suivante : le stop ne doit pas être inférieur au niveau du stop sur le serveur + spread + 1.

Que dois-je faire si le serveur renvoie le niveau d'arrêt à 0, c'est-à-dire s'il est flottant ?

Option - ajuster par erreur 130 - pas une option - le modérateur ne permettra pas cette façon.

Comme suggéré précédemment = Erreur 130 - augmenter de 1 et ainsi de suite, jusqu'à ce que le serveur ne rate aucune transaction. - pas une option.

Mes amis, merci de m'avoir aidé à résoudre le problème. Mais il cherchera une solution rationnelle à ce problème.

Merci à tous pour votre participation.

 
Vladislav Andruschenko:

c'est une situation légèrement différente ici,

Je ne veux pas ciseler tout le temps.

Naturellement, après l'erreur, il y a un contrôle d'erreur - Slip. Mais cela ne fonctionne pas dans le testeur.

C'est à propos de l'écart flottant.

comme je l'ai écrit ci-dessus - avant d'envoyer une requête - les niveaux de stop sont corrigés et envoyés au serveur, - le serveur renvoie une erreur 130 - Expert Advisor corrige à nouveau le niveau et envoie à nouveau au serveur.

et ainsi de suite.

Le glissement ne fonctionne pas dans le testeur, c'est pourquoi il n'y a pas de délai.

Pour l'instant, j'ai résolu le problème de la façon suivante : le stop ne doit pas être inférieur au niveau du stop sur le serveur + spread + 1.

Que dois-je faire si le serveur renvoie le niveau d'arrêt à 0, c'est-à-dire s'il est flottant ?

Option - ajustement par erreur 130 - pas une option - le modérateur n'autorisera pas cette méthode.

Comme suggéré précédemment = Erreur 130 - augmenter de 1 et ainsi de suite, jusqu'à ce que le serveur ne rate aucune transaction. - pas une option.

Mes amis, merci de m'avoir aidé à résoudre le problème. Mais il cherchera une solution rationnelle à ce problème.

Merci à tous pour votre participation.

En principe, il est possible d'obliger l'utilisateur à saisir manuellement le facteur de multiplication de la propagation lorsque stoplevel==0. C'est à dire, lors de l'initialisation (pas de changement d'horizon temporel), vérifier le stoplevel et, s'il est nul, afficher une demande de saisie du coefficient. Si l'utilisateur refuse d'entrer, utilisez alors le coefficient. 2 (spread*2), puis augmenter soit le coefficient, soit la taille de l'arrêt en cas d'erreur 130. Si un utilisateur sait comment le niveau de stop est calculé (demandez par exemple au support technique du département des transactions), utilisez alors le coefficient qu'il a entré, mais n'oubliez pas de répondre à une 130ème erreur en augmentant la taille du stop (au cas où elle apparaîtrait encore). Mais généralement (je l'ai rencontré plusieurs fois et je l'ai appris empiriquement), si vous utilisez stop=stopplavel*coefficient+1, aucune erreur ne se produira. Si vous n'ajoutez pas 1 point, des erreurs apparaissent.

Par conséquent, vérifiez sur le serveur MC comment ils calculent le stoplevel et entrent le coefficient requis dans l'EA. Même si le modérateur refuse de saisir le coefficient manuellement, celui-ci sera saisi automatiquement.

 

Merci, c'est le réglage par défaut de 2 +1 points.

C'est une bonne idée de demander. Je vais créer un formulaire et le laisser entrer lui-même.

 

Parfois, le courtier interdit le trading automatique pendant quelques minutes si une vingtaine de commandes sont envoyées sans pause.
En d'autres termes, vous devez modifier/fermer un ensemble d'ordres avec une pause d'au moins 300-500 ms entre les ordres. (Mais l'erreur n'est plus 130)

 
MqlTick MS_MqlTick;

enum EnumStopLevel
  {
   a0 = 0, // Real StopLevel
   a1 = 1, // StopLevel correction spread
   a2 = 2, // StopLevel correction 2*spread
   a3 = 3, // StopLevel correction 3*spread
   a4 = 4, // StopLevel correction 4*spread      
   a5 = 5, // StopLevel correction 5*spread         
  };
input EnumStopLevel Mode_StopLevel = 0;


//========================================== StopLevFun
double StopLevFun(int Mode_StopLevelF)
{
   double StopLL = SymbolInfoInteger(_Symbol, SYMBOL_TRADE_STOPS_LEVEL) * _Point;
 
   if(MQLInfoInteger(MQL_TESTER) && Mode_StopLevelF < 3) Mode_StopLevelF = 3; ///////////////////////// Это для тестера при модерации
 
   switch(Mode_StopLevelF)
   {
      case 0: break;
      case 1: While_SymbolInfoTick(_Symbol); StopLL = MathMax(MS_MqlTick.ask - MS_MqlTick.bid, StopLL); break;
      case 2: While_SymbolInfoTick(_Symbol); StopLL = MathMax((MS_MqlTick.ask - MS_MqlTick.bid) * 2, StopLL); break;
      case 3: While_SymbolInfoTick(_Symbol); StopLL = MathMax((MS_MqlTick.ask - MS_MqlTick.bid) * 3, StopLL); break;
      case 4: While_SymbolInfoTick(_Symbol); StopLL = MathMax((MS_MqlTick.ask - MS_MqlTick.bid) * 4, StopLL); break;
      case 5: While_SymbolInfoTick(_Symbol); StopLL = MathMax((MS_MqlTick.ask - MS_MqlTick.bid) * 5, StopLL); break;
   }
 
   return(NormalizeDouble(StopLL, _Digits) );   
}


//=========================================== While SymbolinfoTick
bool While_SymbolInfoTick(string Fsymbol)
{
   int WhTi = 0;
   
   while(!SymbolInfoTick(Fsymbol, MS_MqlTick) ) 
   {
      if(WhTi % 10 == 0) Print(Fsymbol, " >> SymbolInfoTick(Fsymbol, MS_MqlTick)= false     Try= ", WhTi);
      
      WhTi++;
      
      if(WhTi > 100) return(false);
      
      Sleep(10);
   }
   
   return(true);
}
А если вот такой вариант.
Если реал или демо, то по умолчанию выбирается вариант 0 Mode_StopLevelF, и в этом случае возвращается реальный стоплевел.
Но можно выбрать и коррекцию стоплевела спредом, с разным коэффициентом. При этом если стоплевел будет больше чем спред, то будет учитываться стоплевел.
А для тестера, при модерации, выбирается всегда режим не ниже 3 Mode_StopLevelF, в этом случае стоплевел будет больше спреда в 3 раза и больше.
П.С. Как пишет разработчик SymbolInfoTick  предпочтительнее чем SymbolInfoDouble для Ask и Bid.
https://www.mql5.com/ru/docs/marketinformation/symbolinfodouble
 
Vladislav Andruschenko:

Salut à tous, mes amis !

Il y aune caractéristique de Marketplace : nous devons vérifier toutes les valeurs pour l'arrêt min.

Si la valeur de la variable est inférieure à la butée minimale, il faut alors assigner une butée minimale, de manière à ce qu'il n'y ait pas d'erreur 130.

Actuellement, 90% des courtiers ont un spread flottant et un STOP min et un rendement de 0.

Il existe une construction de code qui affecte toutes les variables à l'arrêt min.

Mais cela ne fonctionne plus sur le marché, car min.stop = 0 partout maintenant,

Qui s'occupe de ce problème ?

Bonjour Vladislav, j'ai lu le problème que j'ai également rencontré et j'ai décidé que si le niveau d'arrêt flottant renvoie une valeur de 0 ou proche de zéro, alors il faut utiliser des signaux inverses pour fermer.

Pensez-vous que cette solution est acceptable ?

 
Bonjour, le signal de fermeture est-il inversé, dans le sens des arrêts virtuels ?
 
Oui, mais j'ai une meilleure idée, alors je vais le faire. Par exemple, si le calcul automatique des niveaux de stop par ATR a donné un résultat de zéro ou proche de zéro, ce qui est inférieur à la valeur du spread moyen, alors nous utilisons les données précédentes jusqu'à ce que les nouvelles données apparaissent avec l'ouverture de l'ordre suivant. C'est mieux que les signaux inversés.
 
Si vous utilisez le système, tout va bien, mais la question portait sur la vérification sur le marché. Malheureusement, l'erreur 130 empêche le produit d'aller plus loin.