Checking the minimum stop in EAs published in the marketplace. - page 17

 
Vladislav Andruschenko:

My Expert Advisor is catching min moves, so it is pounding the server, but not with 1 pip stoploss, but with a normal min level + spread, but the spread is floating. That is why EA is pounding the server until it returns a normal spread.

In other words, at the moment of opening it checks for min stop - rebuilds its values - then it hits the server. But if you need to put a 10 pips stop, you have to wait for the min spread and pound the server.

Banging the server is not a good idea. You may encounter a ban on autotrading. (Who would want to deal with DDOS attacks on the server with his EA?)

First of all, before sending a request, we need to get the spread, Stop Level, adjust stops and if the stop is acceptable for trading, then send a request. If the stop size is not acceptable, then there's no need to bother anyone. If my server was pounded like that, I would have killed it...

But if, after sending a request with an acceptable stop size, we get error 130 again (stop levelling conditions have changed while sending the request), then we can adjust the stop size and send the request (with an acceptable size of newly calculated stop). The number of such requests should be limited, otherwise it will be another stupid chattering.

Now I see why you are not allowed in the market.

 

it's a slightly different situation here,

I don't mean to chisel all the time.

Naturally, after the error there is an error check - Slip. but it doesn't work in the tester.

It's about the floating spread.

as I wrote above - before sending a request - stop levels are corrected and sent to the server, - the server returns an error 130 - Expert Advisor again corrects the level and sends to the server again.

and so on.

Slip does not work in the tester, that is why there is no delay.

At the moment, I solved the problem this way: stop should not be lower than the stop level on the server + spread + 1.

What should I do if server returns the stop level as 0 ? i.e. floating ?

Option - adjust by error 130 - not an option - moderator will not let this way.

As suggested before = Error 130 - increase by 1 and so on, until the server does not miss a deal. - not an option.

Friends, Thanks for the help in solving the problem. But will be looking for a rational solution to this problem.

Thank you all for your participation.

 
Vladislav Andruschenko:

it's a slightly different situation here,

I don't mean to chisel all the time.

Naturally, after the error there is an error check - Slip. but it doesn't work in the tester.

It's about the floating spread.

as I wrote above - before sending a request - stop levels are corrected and sent to the server, - the server returns an error 130 - Expert Advisor again corrects the level and sends to the server again.

and so on.

Slip does not work in the tester, that is why there is no delay.

At the moment, I solved the problem this way: stop should not be lower than the stop level on the server + spread + 1.

What should I do if server returns the stop level as 0 ? i.e. floating ?

Option - adjust by error 130 - not an option - moderator will not allow this method.

As suggested before = Error 130 - increase by 1 and so on, until the server does not miss a deal. - not an option.

Friends, Thanks for the help in solving the problem. But will be looking for a rational solution to this problem.

Thank you all for your participation.

In principle, it is possible to force the user to manually enter the spread multiplication factor when stoplevel==0. I.e., when initializing (not switching timeframes) check the stoplevel and, if it is zero, display a request to enter the coefficient. If the user refuses to enter, then use the coefficient. 2 (spread*2) and then increase either the coefficient or the stop size in case of error 130. If a user knows how the Stop Level is calculated (ask the Technical Support department, for example), then use the coefficient entered by him/her, but do not forget to respond to a 130th error by increasing the stop size (in case it still appears). But usually (I've encountered it several times and learned it empirically), if you use stop=stopplavel*coefficient+1, no error will occur. If you don't add 1 point, errors appear.

Accordingly, check on the MC server how they calculate the stoplevel and enter the required coefficient into the EA. Even if the moderator refuses to enter the coefficient manually, it will be entered automatically.

 

Thank you, that's the default setting of 2 +1 points.

It's a good idea to ask. I'll create a form and let him enter it himself.

 

Sometimes the broker bans autotrading for a couple of minutes if about 20 commands are sent without pauses.
In other words, you should modify/close a bunch of orders with a pause of at least 300-500 ms between orders. (But the error is no longer 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:

Hi all, friends!

There's a feature of Marketplace: we need to check all values for min stop.

If the value of the variable is less than the min-stop, then assign a min-stop, so that there is no error 130.

Currently 90% of brokers have floating spread and min STOP and yield 0.

There is a code construct that assigns all variables to the min stop.

But it doesn't work in the marketplace anymore, because minstop = 0 everywhere now,

Who is dealing with this problem?

Hi Vladislav, read the problem I also encountered and decided if the floating stop level returns a value of 0 or close to zero, then use reverse signals to close.

Do you think this solution is ok ?

 
hi, is the closing signal reversed, in the sense of virtual stops?
 
Yes, but I've got a better idea, so I'll do that. For example, if automatic calculation of stop levels by ATR has returned zero or close to zero, which is less than the value of the average spread, then we use the previous data until the new data appears with the opening of the next order. This is better than reverse signals.
 
If you do the system - then it's OK, but the question was about checking in the marketplace, unfortunately error 130 prevents the product from going further
Reason: