Occasional incorrect return from AccountFreeMarginCheck()

 

Hi all,


I've had a couple of occurrences recently where the following statement triggers when it shouldn't:


if(AccountFreeMarginCheck(Symbol(),OP_SELL,dLots) <= 0)

{

blah...


Notes:

dLots is a double which is set to 0.1 on this occasion.

There is plenty of free margin.

If I create a test EA which only executes this instruction, I cannot recreate the problem. I'd have to scale to about 8 lots to create a funding issue.

I have this particular EA running on multiple accounts/pairs, one of which is on the same pair as this one and similarly the account has plenty of funds; none of the other instances have had this problem yet.

It has only happened twice now over a few months, both times on the same account.

Last time it happened, it performed correctly on the same account (which was in the same financial situation) next time it executed.


My own considered opinion is that it is either a platform bug, or a corrupt response from the broker's server, however, I'd appreciate your views.


Ta.

CB

 
cloudbreaker:

I've had a couple of occurrences recently where the following statement triggers when it shouldn't:

if(AccountFreeMarginCheck(Symbol(),OP_SELL,dLots) <= 0)

I've never had occasion to use AccountFreeMarginCheck(), but since you're desperate for a reply...


If it's only happening about once a month then my money would also be on a corrupt response from the broker's server. You've doubtless already examined this, but does the timing of the problem coincide with anything in MT4's logs suggesting a bouncy connection?


Is the return value from AccountFreeMarginCheck() zero, or is it actually negative? Can you work round the problem by doing a "sanity check" such as a guesstimate of what the value should be based on AccountFreeMargin(), or by calling AccountFreeMarginCheck() with something very small like 0.01 and making sure that the return value for that is positive?

 
jjc:

I've never had occasion to use AccountFreeMarginCheck(), but since you're desperate for a reply...


If it's only happening about once a month then my money would also be on a corrupt response from the broker's server. You've doubtless already examined this, but does the timing of the problem coincide with anything in MT4's logs suggesting a bouncy connection?


Is the return value from AccountFreeMarginCheck() zero, or is it actually negative? Can you work round the problem by doing a "sanity check" such as a guesstimate of what the value should be based on AccountFreeMargin(), or by calling AccountFreeMarginCheck() with something very small like 0.01 and making sure that the return value for that is positive?

Ta for response.

Yes, its an odd one to say the least.

It does seem to coincide with occasions when I remove the EAs from the charts, re-initialize the platform instances and add the EAs again.

However, its all on the same OS instance, all the ex4s are identical,none of the charts are unique, and it only ever seems to happen on the one account.

That account is not unique either, being of same type, same currency, similar balance and same broker as some of the others.

I haven't been able to tell yet whether the return is zero or negative (hadn't happened enough to add a debug statement).

But when I visited the computer room directly after it first happened, I ran a test EA which cycled through differing lot values on that very account and the AccountFreeMarginCheck() call worked totally correctly.

Strange indeed.


CB

 

Hi CB

Watch out for those cosmic rays. I know it sounds crazy but if you have ever watched a diffusion chamber you would know a cosmic ray occurs more than one or two every 10 minutes and if it hits memory bits they get knocked out even inside the CPU. That's why CPUs have error checking and correcting on their caches and the big boys use it main memory too. I am not suggesting that cosmic rays or any other external influences are at play other than bugs in the system code. The point I am making is that when you code it should be defensive by thinking what happens if the result is true but it comes out false. I am sure you know this but for those that don't one should not use point checks like x==y without deciding what happens if x>y or x<y. Often I have seen code where a point check has failed due to bad data and the code hos fowed through and caused all sorts of havok.

In your case I would suggest breaking the line up by assigning the result of the call to a variable then doing the chack afterwards. By doing this it shortens the time MT4 is tied up on the command so it is less likely to get interrupted in the middle of the sequence. We are dealing with an interpreter after all and lengthy statements must be much longer by default.

Just a suggestion.

 

Amplifying Ruptor's ideas, I learned back in .asm days [and Fortran;] the effects of not considering all 3 tri-state boolean conditions: < = >

Much code is single focused eg: if(a==0) giveUp else pushTheRedButton; better is to deal with 2 of the 3 possible states eg: if(a<=0) giveUp else ...;

Of course 'a' could have tri-state meaning eg: <0 means error; ==0 means no status; >0 means status code

But generally is the latter and coders just test for the condition they want. Like Ruptor says "be defensive"

I think coders should feel the hair on back of neck stand up IF they only check for one condition. So simple to do <= or >= instead of < or > for instance. What happens if ==0? That is when alarm bells should sound...

Am tempted to mention "NormalizeDouble(<expr>,Digits)" simply because even tho greatly talked about [and demonstrated] on this forum, one continuously sees non-use. Some even go to lengths saying why not used. Surely speed consideration is less than trivial. Maybe it's due to keypresses? Maybe clutter (it is long length)?

If so just "double normD(double d) {return(NormalizeDouble(d,Digits));}" or shorten to "norm()". I use normD() cuz have normI() for type int + 3,5pricing multiplier if needed...

just my ideas and how i do it...

They still say I believe that coding is a creative process or craft, so guess no time soon will consensus be achieved on any aspect of this stuff.

Anyway, Ruptor's got me thinking even more about how I can put up a sun shield around house or maybe immerse all in a bubble chamber :O)
btw, apparently Intel is chugging away with thoughts of a cosmic ray detector on chips so that any detected 'funnies' provoke re-exe of previous cmd...

instead of waiting maybe some cling-film over my umbrella will be good cosmic rain shield... just kidding!

.

keep it comming Ruptor - all very interesting indeed!

 

Thanks guys.

I am actually handling and reporting the error okay.

What mystifies me is that it always seems to happen on the same account, and it seems to be on a day when we've re-initialized the platform.

But I've moved it to a lead-lined bunker deep underground just in case.


CB

 
cloudbreaker:

What mystifies me is that it always seems to happen on the same account, and it seems to be on a day when we've re-initialized the platform.

It may or may not be a consolation, but I know some people running 8 identical accounts with the same broker. Same hardware, identical MT4 installations, same broker server. Two of the accounts - and it's always the same two - periodically stop receiving ticks, and need the MT4 instance to be restarted before the connection gets re-established. It's spawned some very, er, interesting automated MT4-restart code...

 
jjc:

It may or may not be a consolation, but I know some people running 8 identical accounts with the same broker. Same hardware, identical MT4 installations, same broker server. [...]

Got a new problem which is more similar to CB's. I think that all the following are weirdness by MT4/the broker rather than errors in my code (because it's worked fine for weeks on all accounts except one).


Occasionally, about twice a week, a number of MT4 functions return zero. Only ever happens on one account out of about six identical accounts. Most recently, AccountProfit() returned zero while AccountBalance() and AccountEquity() returned the correct numbers. Similarly, AccountMargin() returned zero while AccountFreeMargin() returned the correct number. And OrdersTotal() returned zero - obviously all of these while there were open orders. Even more weirdly, both TimeCurrent() and TimeLocal() returned zero - which makes me wonder about MT4 rather than the broker. The problem typically resolves itself within a second or two.

 

Hi Cloudbraker,

I can see that your post is almost 3 years old but I was wondering if you could fix this issue ?!? I have exactly the same issue. Every now and the the AccountFreeMarginCheck function return a negative value + an Error 134 although there is plenty of margin available. For me all the other functions AccountBalance, AccountEquity, ... etc return correct values.

Were you able to fix this issue? Did you have to rewrite AccountFreeMarginCheck?

Thx

Wolfgang

Reason: