trailing stop not working as expected

Forums ProRealTime English forum ProOrder support trailing stop not working as expected

Viewing 15 posts - 1 through 15 (of 18 total)
  • #173848

    The attached shows a position I have open at the moment on a 1 hour TF.

    Opened at 8:00 15209 with the trail to start after a high of 0.56% (15294.8)

    In the first bar it hits a high of 15301 and at the start of the 9:00 bar it should have moved to breakeven … but it didn’t.

    This is the trail that I’m using (courtesy of Paul):

    Any thoughts on this?

    #173853

    Because in lines 13, 48 and 51 (the same for the Short direction) you are using a reference to a price (trailingstartlong), but in lines 48 and 51 you added *PIPSIZE, which is not correct, both are prices so no conversion is needed.

    Simply remove it.

     

     

    #173857

    Thanks Roberto, i’ll try that 👍👍👍

    #173858

    Just to clarify, I should remove *pipsize from this entire section (8 occurrences) ?

     

    #173859

    Yes, since at the beginning all started with a PRICE, not PIPS.

     

    #173860

    You can use GRAPH to monitor newsl, trailingstartlong, etc…

    Actually NEWSL can be better monitored with GRAPHONPRICE.

    1 user thanked author for this post.
    #173861

    Ok, what about this one, should i remove *pointsize at lines 78, 80, 82 and 88, 90, 92 ?

    #173862

    Yes, because tsatr is a price (range) as well as all the other variables.

    The code is based on PRICE, not on PIPS, so all that refers to pips is incorrect.

    Lines 13 and 14 are a bit subtle, they are set as prices (as from their comments), but that is fine for indices where the price-to-pips ratio is 1:1 (Dax, SP, ….) but when used with FX pirs it wouldn’t be correct. In This case you should multiply 6 by PIPSIZE to make sure the numeric constant is converted to a price (divide by PIPSIZE, or POINTSIZE, the other way round that is when converting a price to pips, instead).

     

     

    1 user thanked author for this post.
    #173863

    Thanks loads Roberto, I think that explains a lot of odd behaviour. I never trade Forex so I’ll leave lines 13, 14 as they are.

    😎

    #173870

    Actually if you’re using it with Dax, PIPSIZE should make no difference.

    I need to test it more, to monitor HIGH and LOW more in depth.

     

     

    #173882

    I think it’s because it takes one candle for any system status constant to be updated, so the HIGH at 08:00 could not be detected, while the high at 09:00 was.

    From your pic I cannot see any detail and I could not replicate your trades, but I think this can be the sole reason.

    I suggest that you add these lines to your code, to better debug it:

    #173888

    The high of 15301.5 was hit at 08:14 (having opened at 08:00).

    Running a backtest (having removed *pipsize) shows a loss for that trade, but it has the entry at 15215.7

    The graph shows “trailingstartlong + positionprice = 15300.9” which would be correct (15215.7 + .56%) and allowing for spread, the high of 15301.5 doesn’t clear it.

    But that doesn’t explain why my live trade (actually 15209.6) failed to breakeven after a high of 15294.7

    With or without *pipsize seems to make no difference to backtests.

    #173906

    I could only guess, as I could not replicate your trades without the code.

     

    #173918

    Non fa niente, I’ve decided not to continue with that algo anyway. The other places I’m using it seem to work fine – all shorter TFs, 2m, 5m etc, so may be just a blip with the 1 hour TF.

    Maybe by the time it got to the next candle it had ‘forgotten’ that the high had been reached 😁

    #173920

    Actually this happend to me with the same trail code. I got the same algo on different accounts and the trailing did move on one account but not the other. The price went the profitable way and it still did not move. Then the position got held over the weekend and when markets  reopened on monday the algo updated its stop on both accounts. I dont think there was a visual bug (never happend before atleast?). It was with the *pointsize trailing.

    This has happend 2 times before (this time explained here and one more time). So if I remove *pointsize the issue should be solved?

Viewing 15 posts - 1 through 15 (of 18 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login