Please explain what could be wrong with this function? - page 4

 
Alexey Viktorov:

Vladimir, the problem doesn't occur in the tester... How come there is such a problem? Or because there is only one Expert Advisor in the tester?

I also suggested in the SD that the only change was putting the second EA on a different pair...

The entire trading environment in the tester is prepared in advance. Everything is on a plate. No worries. The real trading environment is different, in case of non-standard behavior (working on someone else's timeframe and/or someone else's symbol) we have to worry about the relevancy of the trading environment.
 
Karputov Vladimir:
In one terminal (on M15 timeframe there were EAs) it didn't work on one symbol - I'm 99% sure that the problem is that when using someone else's timeframe you need to "jerk" the history all the time. I think it's better to do it via CopyTime().
And CopyRates() jerks the history. There is time in the structure...
 
Karputov Vladimir:

This is not a mistake. You are working on someone else's timeframe. In such a case, you have to take care of the data on someone else's timeframe yourself to ensure that it is up to date.

I personally do not see any alternatives.

It is not a fact that we do not know howSERIES_LASTBAR_DATE works. It may be that there is no need to update anything because the time of the last bar can be calculated using TimeCurrent() of the specified symbol. We need to ask the developers.

But so far a clear indisputable fact is that if two variables are set true, then together (when checking &&) these variables will also give true.

 

The problem with the other tools/TF cache dropping off does exist.

Checking for errors and waiting in loop to load does not always help. We have been talking to Service Desk, but MQ has not made any progress, only one hint:

Support Team 2016.02.29 11:45

The suspicion is that the historical data is unloaded by timeout.

There are 2 solutions:

1. access the data more often than once every 3 minutes

2. Put some very simple indicator on data. Volume, for example. There is no calculation, only one buffer is busy. Availability of indicator will keep historical cache in memory regardless of access frequency

The 2nd tip does not work, indicators are called all the time, but at some point the cache fails and it becomes impossible to get data.

Andrey Khatimlianskii2016.03.18 13:41

I solved the problem with this crutch - I call this code every 150 seconds for all involved instruments/FTs:

bool CheckTimeSeries( string symbol, ENUM_TIMEFRAMES period )
{
   double array[];
   if ( CopyClose( symbol, period, 1, 1, array ) <= 0 )
   {
                int err = GetLastError();
                Print( " * Can't refresh timeseries (", symbol, ", ", period, ")! ERROR #", err, "!!!" );
                return(false);
   }
   return(true);
}

Works fast enough, error 4806 seems to disappear after this update.

 

Please comment on another misunderstanding.

Bars

Returns the number of bars in the history by the corresponding period symbol. There are 2 variants of the function.


Only the second option is of interest.

Request the number of bars on a given interval
int  Bars(
   string           symbol_name,     // имя символа
   ENUM_TIMEFRAMES  timeframe,       // период
   datetime         start_time,      // с какой даты
   datetime         stop_time        // по какую дату
   );

Expert Advisor text

/*******************Expert initialization function*******************/
int OnInit()
{
   return(INIT_SUCCEEDED);
}/*******************************************************************/

/************************Expert tick function************************/
void OnTick()
{
  datetime dtarr[], date = D'2016.06.22';
  ArraySetAsSeries(dtarr, true);
  CopyTime(_Symbol, PERIOD_D1, 0, 5, dtarr);
  Print(dtarr[0]);
  Print(" ", Bars(_Symbol, PERIOD_D1, date, dtarr[0]));
  Print(" ", Bars(_Symbol, PERIOD_D1, date+1, dtarr[0]));
   
}/*******************************************************************/

/******************Expert deinitialization function******************/
void OnDeinit(const int reason)
{
}/*******************************************************************/

I understand that the time 00:00:00 belongs to the day, just like the time 00:00:01

But ... the proposed prints do not agree with that.

2016.06.24 22:18:56.450 TestTime (EURUSD,M15)    2
2016.06.24 22:18:56.450 TestTime (EURUSD,M15)    3
2016.06.24 22:18:56.450 TestTime (EURUSD,M15)   2016.06.24 00:00:00

It turns out that between 2016.06.22 00:00:00 and 2016.06.24 00:00:00 there are three daily bars and between 2016.06.22 00:01 and 2016.06.24 00:00:00 there are only two...

Or am I misunderstanding something???

Files:
TestTime.mq5  2 kb
 

And if you add a second to the time of the current bar

  Print(" ", Bars(_Symbol, PERIOD_D1, date, dtarr[0]+1));
  Print(" ", Bars(_Symbol, PERIOD_D1, date+1, dtarr[0]+1));

you get the following

2016.06.24 22:26:48.602 TestTime (EURUSD,M15)    3
2016.06.24 22:26:48.602 TestTime (EURUSD,M15)    4
2016.06.24 22:26:48.602 TestTime (EURUSD,M15)   2016.06.24 00:00:00

The time 2016.06.24 00:00:01 seems to belong to the next bar or what?

 
The upper time limit is not included in the interval in which the number of bars is determined.
 
Dmitry Fedoseev:
The upper time limit is not included into the interval in which the number of bars is determined.

Dimitri, isn't that strange? A new bar has appeared, but we will not count it yet.

Listen, isn't it the reason for such behavior of the SeriesInfoInteger(_Symbol, PERIOD_D1, SERIES_LASTBAR_DATE); ? New bar appeared, tick available code is executed, but time is not yet taken into account???

 

Well, the drummer's deflated... And he's gone completely ignored...?

Vladimir, can you at least answer this question???

Alexey Viktorov:
Does CopyRates() pull the story? There is time in the structure...?
 
Alexey Viktorov:

Well, the bogeyman has deflated... And he's been totally ignored...

Vladimir, can you at least answer this question???

You'd better tell us what you were advised to do at the Service Desk - didn't you continue to talk to them there?