Trend Trading EA with Automated Loss Recovery

[Dewey McG]

Hi Dewey,

Just had a look at the 3 pictures you posted.
This is my response.

1. Yes. This is strange. The same question can be asked...why is it the tp for the first trade was not hit , when the sl for the second is triggered ?
Could it due to spread issue ? , i.e Ask hit the sl, but bid did not touch the tp...or something of that sort.
You might have to zoom into the chart to scrutinize this.

2. Could it be due to a gap ?
Yes...it would be a crazy gap.
An additional note, once a buystop,sellstop, tp, sl is set...it is beyond the control of the EA.
if a buystop, sellstop, tp, sl is not correctly triggered...either the price was set wrong, or there was an error in the execution.
We have to distinguish between those two.

3. This could either be due to
1. wrong lot size or
2. one of the orders in the chain did not get filled correctly due to a gap in prices.
Could you check if it is (2) first ?

Cheers

Good points-I will try to look at this tomorrow to see

[SpiderX]

Good points-I will try to look at this tomorrow to see

Hi Dewey,

Attached is a slightly updated v2.2 of ALR Calculator with lot step.
As a result, the calculations should match exactly the same of that which is calculated in the EA, with the same settings.
Have yet to verify this....maybe you can check this out first.
For future bug issues...first step will be to counter check with the excel sheet and make sure the lot sizes are correct.

Cheers

[SpiderX]

After some thoughts, the next version will keep track of the number of ALR orders, and close all the orders once there is a discrepancy between the number of orders and the number previously counted. (i.e one of the orders was closed for some unknown reason)
Guess this would be a solution to the issues we are seeing.
Watch out for this space. Coming soon.

Cheers

[Gordon]

This is exciting stuff. There's so many different ideas to try. I may be wrong, but what I think I'm seeing is that when you're in a series of ALR trades and the bPriceCrossMAUp or bPriceCrossMADown exits the last order with profit, or if a trailing stop is used and exits with a profit >0, then what happens next is that the ALR sequence begins again with the firstorderlotsize, even though the series of trades ended in a net loss. So I'm thinking what would be better is if the EA insisted on a minimum profit of breakeven or zero profit for the series of trades and not end the ALR progression until the profit is reached. What would this look like in trading? Say your on the 3rd trade of the ALR sequence and you are short and your trailing stop gets hit for a small take profit. The net profit for the series is still <0 , so when that trailing stop is hit, the EA immediately places a buy order of the next lot size and a pending sellstop order at the ALRzone distance below it and so on until the net profit for the series is >= 0. Only then would it begin a new series with the firstorderlotsize. In summary we need to not only follow the number of trades but count the total profit before begining the new sequence.

[SpiderX]

Hi,

v1.03b is in post 1, but still not confident about this version as it was coded in a jiffy.

v1.03b
-Add tracking of number of positions in code
-If there is a discrepancy in positions, EA will close all positions for safety.

Dewey,

This version should fix some of the issues with the rogue positions.
However, we should find out what causes the rogue positions in the first place.
As mentioned in my previous post, it does not make sense that a sl and tp at the same price does not close together unless it is due to spread.
Hope you are able to find out the mystery behind the 3 errors in v1.03a before trying the new one.

cheers

[Dewey McG]

I have to run, but here is one of the errors. Trades are going straight to stop loss and ALR trades firing afterwards then also hitting SL. This happened on a Wednesday, so not caused by gaps.

[SpiderX]

I have to run, but here is one of the errors. Trades are going straight to stop loss and ALR trades firing afterwards then also hitting SL. This happened on a Wednesday, so not caused by gaps.

Hi Dewey,

This looked like explaination no 1.
Spread issue.
Quite certain that tester takes spreads into account.
We happened to have a super lucky break whereby sl and tp cannot execute at the same price due to the spread.
i.e Sl hit the ask price, but tp could not hit the bid as it was a few pips behind.
The new version should fix this.
However, to my understanding, the forced closure would mean possible baskets in loss because the tp and sl cannot be the same price.
You would have to look out for this in the backtest of the new version.

Cheers

[Dewey McG]

Ok the new version looks much better. It still shows a small loss on some of the series, as much as 100--but nothing major and no rogue trades. I attached a PIC to show how it handled a weekend gap hitting SL. is this what you wanted?

[SpiderX]

Ok the new version looks much better. It still shows a small loss on some of the series, as much as 100--but nothing major and no rogue trades. I attached a PIC to show how it handled a weekend gap hitting SL. is this what you wanted?

Hi Dewey,

As long as the whole series closes with the closing of one trade, it should be fine.
For the small losses, could you pick one set and check if all the trades were filled at the correct price ? ..i.e all buy entry, sell entry correct, tp,sl correct

Cheers

[Dewey McG]

Hi Dewey,

As long as the whole series closes with the closing of one trade, it should be fine.
For the small losses, could you pick one set and check if all the trades were filled at the correct price ? ..i.e all buy entry, sell entry correct, tp,sl correct

Cheers

Sorry to take so long--schedule has been crazy. The trade logic seems fine--it's the lot sizes. The calculations are a tad off, so the additional ALR trades are slightly smaller than they should be

Edit--the chart should say .25, .35, .23