EA Code Failure?

New comment
 

Does anyone know what caused this problem and how I can prevent it again.


After approximately 6 hours after the start of the new week, my code:


gdWeekPivot = (iHigh(NULL, PERIOD_W1, 1) + iLow(NULL, PERIOD_W1, 1) +

iClose(NULL, PERIOD_W1, 1) + iOpen(NULL, PERIOD_W1, 0)) / 4;

returned the value of zero from this pivot calculation. I know because I print out the value. There were no errors or disconnections shown in the journal or log. The data on the chart looked fine.


I restarted the EA a few minutes after and it did the calculation ok.


I find this a bit worrying as it's running on a live account. What caused this and how can I safeguard against this in future. If this calculation can fail, so potentially can similar ones in different timeframes?


Thanks

Mark

 

This is what I use

double h = iHigh(NULL,10080,0);
double l = iLow(NULL,10080,0);
double c = iClose(NULL,10080,0);
double o = iOpen(NULL,10080,0);
double p = (h+l+c+o)/4;

Cheers Kiwi

 
kiwi06:

This is what I use

double h = iHigh(NULL,10080,0);
double l = iLow(NULL,10080,0);
double c = iClose(NULL,10080,0);
double o = iOpen(NULL,10080,0);
double p = (h+l+c+o)/4;

Cheers Kiwi

Thanks Kiwi. I take it you've never had your calculation coming out at zero?


Essentially I'm doing the same (NULL for symbol and 10080 is the same as PERIOD_W1) except for breaking the statement down into individual elements. Is there a known bug which affects doing it all in one statement?

 

extern string workPeriod ="H4";

Place in deinit

int Txt2Period(string text)
{
if (text=="M1" || text=="m1")int Prd =1 ;
else if (text=="M5" || text=="m5") Prd =5 ;
else if (text=="M15" || text=="m15") Prd =15 ;
else if (text=="M30" || text=="m30") Prd =30 ;
else if (text=="H1" || text=="h1") Prd =60 ;
else if (text=="H4" || text=="h4") Prd =240 ;
else if (text=="D1" || text=="d1") Prd =1440 ;
else if (text=="W1" || text=="w1") Prd =10080 ;
else if (text=="MN" || text=="mn") Prd =43200 ;
else /*text==**/ Prd = 0;
return(Prd);
}

//+------------------------------------------------------------------+
//| expert start function |
//+------------------------------------------------------------------+
int start()
{
//----

//---- Defind up-down PART
int wrkPeriod =Txt2Period(workPeriod);

double h = iHigh(NULL,wrkPeriod,0);
double l = iLow(NULL,wrkPeriod,0);
double c = iClose(NULL,wrkPeriod,0);
double o = iOpen(NULL,wrkPeriod,0);

I hope this helps out

What sort of EA are you building

 

Thanks. The way I do it normally works. It was just this one time it failed. You just expect statements like this to work 100% else things would be very messy.


The EA is built, I've been running it for a while. Most trades last from a few hours to a couple of days. It's works purely from basics like pivots, atr etc. No misleading indicators.

 

I run two ea's that are pivot only based one is based on the monthly and the other the previous bars pivot point.

I don't do indicators any more.

i would like to talk more about our systems if you don't mind. we both might be able to learn from each other.

 
sparkz wrote >>

Does anyone know what caused this problem and how I can prevent it again.

After approximately 6 hours after the start of the new week, my code:


gdWeekPivot = (iHigh(NULL, PERIOD_W1, 1) + iLow(NULL, PERIOD_W1, 1) +

iClose(NULL, PERIOD_W1, 1) + iOpen(NULL, PERIOD_W1, 0)) / 4;

returned the value of zero from this pivot calculation. I know because I print out the value. There were no errors or disconnections shown in the journal or log. The data on the chart looked fine.

I restarted the EA a few minutes after and it did the calculation ok.

I find this a bit worrying as it's running on a live account. What caused this and how can I safeguard against this in future. If this calculation can fail, so potentially can similar ones in different timeframes?

Thanks

Mark

hello Mark

.

Not bug - is no data to complete your request without going to server to download.

W1 data for the ccy you used - not in W1 Series Arrays.

Please take looksee at "Timeseries access".

.

Amongst other things many builtins return status, by typed return and/or last_error [viz: GetLastError()]

Is responsibility of coder to check else what you experienced is bound to happen, yes?

No warranty at all, that first time, every time, a builtin is called, will it be successful.

Had you checked GetLastError() it would most likely have returned ERR_HISTORY_WILL_UPDATED (4066)

.

Your remedy is to Sleep() and retry [which could entail >1 retry IF not wait long enough]. 'Long Enough' is subjective. I have done many tests, but no point, you must decide for self.

Time is needed to fetch data from server. So is not bug, just CT telling you that it must request it etc.

.

If interested, you can force this error again - at any time and for any ccy/period. Simple way is to remove history file for let's say a ccy/period that you not really going to use.

Run test script to do your code and be sure to print out GetLastError() for all calls. You'll be able in this way to 'catch out' CT etc...

Is just way to demonstrate to self what's up doc... :)

.

Much code see, no sts checks done. Well... ok, all is cool but the random glitch enevitably will happen and that is when much time can be spent chasing for buglet and/or in the end blaming CT.

.

HTH

New comment