MULTIPLE EXPERTS IN SAME CURRENCIES

New comment
 

I HAVE BEEN TESTING 3 DIFFERENT EXPERTS IN 7 DIFFERENT CURRIENCIES IN MY DEMO ACCOUNT. I IMPLEMENTED MAGIC NUMBERS TO DIFFERIENTIATE THE EXPERTS (3) AND THE INSTRUMENTS (7), OBTAINING A TOTAL OF 21 DIFFERENT MAGIC NUMBERS. THE EXPERTS WORK WELL INDEPENDENTLY. BUT, WHEN WORKING IN A MULTI EXPERT, MULTICURRENCY SCENARIO THEY DON' EXECUTE THE ENTRIES. THEY SHOW THE SIGNAL THAT IDENTIFIES THE ENTRY BUT DON'T EXECUTE THE ORDERS.

I HAVE NOT BEEN ABLE TO DETERMINE IF HTE PROBLEM IS A CODE PROBLEM ( COMPILES OK, BACKTEST OK, RUNS INDIVIDUALLY OK), OR IF IT IS A BROKER ISSUE.

ANY HELP IS GREATLY APPRECIATED. THANK YOU.

 

i've delt with that also if EA's are sending order requests at the same time when previous ones haven't finished.

the code has to keep trying until it succeeds

  
int MAGICMA=1;

 

int CountLongs()
{
   int buys=0;
   for(int i=0;i<OrdersTotal();i++)    {
      if(OrderSelect(i,SELECT_BY_POS,MODE_TRADES)==false) 
         break;
      if(OrderSymbol()==Symbol() && (OrderMagicNumber()==MAGICMA) )      
         if(OrderType()==OP_BUY  )  // counting open longs for Symbol() placed by EA with magic number MAGICMA
            buys++;
   }
   return(buys);   
}

Too many magic numbers are redundant information. This redundancy in turn causes a lot of other problems.

I usually define a single magic for each EA, and use Symbol() and OrderSymbol() to know which currency.

In your case, if the EA was a real person, then for trading eurusd his name would be Bob, and for usdjpy would be Bill... which does not make sense.

Given the example above, CountLongs, you can extrapolate the approach for trades opening and management.

 
spacechimp wrote >>

i've delt with that also if EA's are sending order requests at the same time when previous ones haven't finished.

the code has to keep trying until it succeeds

yes, terminal is single threaded for trade operations to server = only ONE will be allowed/accepted at any time. It will only accept another when their is no active trade operation.

If you have the EA code you must inspect it to determine if the EA is 'asking' terminal if it is ok to make trade operation call. Please remember there are five trade operations so is not just OrderSend() code area you should inspect. The other four are: OrderModify(), OrderDelete(), OrderCloseBy(), OrderClose().

Multi EA workings on one Client Terminal means that each EA program must know is correct time to issue one of these five trade operations.

Determine if is correct time means the calls the EA can make are: IsTradeAllowed() and IsTradeContextBusy(). One of these MUST be used.

Agreed with spacechimp also that the EA code must detect from these two calls that it is not correct time to issue trade operation and therefore must have a Sleep() period followed by a retry in calling one of these two functions. This generally takes place within context of a maximum retries while/for loop code block/function...

You may also like to inspect EA code to see that it is resiliant to trade operations not completing due to some error. IE, does the code retry for certain errors?, does it RefreshRates()?, does it have a Sleep() period before retrying because the error code documentation may state that EA should wait?

On and on it goes...

Agree with abstractMind says one Magic# for each EA is sufficient and is good enough, unless an EA issues many orders whereby two or more are in trade pool/at market and the EA wishes to manage each trade order independantly. That is when unique per order Magic# can be highly advantageous. Please remember the Magic# is a 32bit integer. This is a big number with plenty of room to hold an unique EA ID# and a separate subfield which holds the unique 'per order' Magic#. iow, somehow [and easily too] the EA must be able to identify each of it's potentially many market orders]

Many ways for many requirements are available...

 
fbj wrote >>

yes, terminal is single threaded for trade operations to server = only ONE will be allowed/accepted at any time. It will only accept another when their is no active trade operation.

If you have the EA code you must inspect it to determine if the EA is 'asking' terminal if it is ok to make trade operation call. Please remember there are five trade operations so is not just OrderSend() code area you should inspect. The other four are: OrderModify(), OrderDelete(), OrderCloseBy(), OrderClose().

Multi EA workings on one Client Terminal means that each EA program must know is correct time to issue one of these five trade operations.

Determine if is correct time means the calls the EA can make are: IsTradeAllowed() and IsTradeContextBusy(). One of these MUST be used.

Agreed with spacechimp also that the EA code must detect from these two calls that it is not correct time to issue trade operation and therefore must have a Sleep() period followed by a retry in calling one of these two functions. This generally takes place within context of a maximum retries while/for loop code block/function...

You may also like to inspect EA code to see that it is resiliant to trade operations not completing due to some error. IE, does the code retry for certain errors?, does it RefreshRates()?, does it have a Sleep() period before retrying because the error code documentation may state that EA should wait?

On and on it goes...

Agree with abstractMind says one Magic# for each EA is sufficient and is good enough, unless an EA issues many orders whereby two or more are in trade pool/at market and the EA wishes to manage each trade order independantly. That is when unique per order Magic# can be highly advantageous. Please remember the Magic# is a 32bit integer. This is a big number with plenty of room to hold an unique EA ID# and a separate subfield which holds the unique 'per order' Magic#. iow, somehow [and easily too] the EA must be able to identify each of it's potentially many market orders]

Many ways for many requirements are available...

I've been trying to crack this problem for awhile now..although i'm not an expert mql programmer.

FBJ gave the best advice i've seen Yet on this subject.

I'd LOVE to see a block of code written that addresses this 'multiple ea sending order commands issue' either by FBJ or anybody else.

I'm gunna try and use the tips above, see if I can get it to work.

 

You will probably find this article useful.

'Error 146 ("Trade context busy") and How to Deal with It'


CB

 

That's a very good article. Gives many ideas. Also, the section on semaphore mechanism and how to implement using ClientTerminal Global Variables and the builtin management functions is good introduction for using in design where not just single threading Trade Operations is concerned but any resource needing atomic access to eg, files, global variables, indicators, other EAs. Any resource which may be accessed by many requestors which not only have read access but write access. Of paramount importance to ensure who does what and when and should this all be done ad hoc or must it be channeled, like the single threading of trade operations within one instance of ClientTerminal for many requestors for this one resource.

Yes, one of the better articles kicking about, imho.

.

??

"'multiple ea sending order commands issue' "

unclear on actual message here, but probably CB's link will suffice for now.

.

I would only add that some on site publish snippets that show retry loops = great!

Trouble is, bulk of code on this site does not. Nor, does much of any code deal with the very real possibility of dealing with functions that have potential for returning errors.

I may be picky here but IF a function's interface document shows possible error code returns, would you not think it wise to trap them and... handle them?

Just really amazes me how all this code just assumes that all is A-OK in cyber world 100% of time.

For me, I find error detection and handling very challenging and rewarding too. That sense of having covered 'all my bases' is satisfying although code size can mushroom, I, at least know that the traps are set and waiting... ;)

.

MetaQuotes went to great lengths to provide error mechanisms but imho, most simply ignore the subject of Error Handling. To each their own, but...

.

Oh well... is only money :)

.

Am offa me soapbox now - :O)

Happy 03Aug ... trading

New comment