Reject – Another Order same Position

Forums ProRealTime English forum ProRealTime platform support Reject – Another Order same Position

Viewing 13 posts - 16 through 28 (of 28 total)
  • #82016

    Sorry I might be missing something/misinterpreting apologies if I am – I know you keep referring to the screenshots but all I see is a snippet of the Order List window with the arrows pointing to the orders so not much to go on in terms of what is in the code so am not sure if you are saying I am not looking at the screenshots properly/what am I missing or that you have now checked the strategies in question and they are not using the IF NOT ONMARKET approach…? I guess if it is the latter then yes there would I guess (depending on the code of course) be the possibility opposing orders could be triggered ie. you are in a LONG position when conditions are met to enter a SHORT position so in order to enter the SHORT the LONG needs to be closed and SHORT opened – but why should this matter it’s perfectly fine to do that is it not? Works fine in the IG web platform have done it by mistake many a time when I didn’t have FORCE OPEN set to ON so why should it be a problem in PRT? (or have I missed the point here…?)

    #82017

    they are not using the IF NOT ONMARKET approach

    Correct … they are not.

    or have I missed the point here…?

    No you haven’t missed the point.

    What you say … is what is happening and it appears that PRT cannot cope with 2 Orders executed at same time so it rejects the SellShort while it executes the Sell (Long) and then 1 second later executes the SellShort (which is why posted the screen shots of the Orders List).

    In actual fact PRT probably executes the SellShort < 3 milliseconds later (but rounded this shows as 1 second on the Orders List).

    I should have included the screen shot below for clarity.

     

    #82031

    I have found another example that gives the Another Order Reject … 2 Orders same time, same direction, same Market on 2 separate Systems … 1 (of the 2) Order gets rejected and then the (rejected) Order gets executed some millseconds later!

    Note the times on the Orders List screen shots.

    So it seems the words in the Another Order Reject message are correct! 🙂

    And also PRT cannot execute 2 Orders same time, same direction, same Market, SAME PLATFORM??

    #82050

    And also PRT cannot execute 2 Orders same time, same direction, same Market, SAME PLATFORM??

    Same behavior with your broker with other platforms, so it doesn’t surprise me.. Keep in mind that this message is sent by your broker and the platform just receive it and fire the alert, that’s all.

    #82058

    Keep in mind that this message is sent by your broker and the platform just receive it and fire the alert, that’s all.

    So my mind now asks … does IG reject > 1 Order same time, same direction, same Market… across all Platforms on same IP address or are Another Order Rejects (for reasons stated ) bounded to a 1 Platform restriction?

    Hope that makes sense?

    #82071

    I’ll admit I’m lost but just to throw something else into the mix I’ve finally found the thread I was talking about earlier – https://www.prorealcode.com/topic/5-strategies-stopped-this-morning/page/2/

    Nicolas I get what you’re saying but as I point out in that (unreplied by ITF moderators) thread surely it is PRT that is submitting these orders and IG (any broker) is rightly rejecting them as for want of a better description ‘confusing’ – ie the issue is with PRT executing the code/sending the orders ummm incorrectly? I have to admit it is hard to dredge up all my reasoning from way back then but think it may be to do with when there is occasionally no bar for a second or two that seems to mess things up – is this when PRT receives no response from IG so resubmits the same order and when the ‘lights come back on’ with a new second TF bar IG then receives 2 orders and says ‘you can’t have both sorry’ which is when the PRT strategy bombs out?

    Is that a problem with IG, PRT or an insurmountable problem that is impossible to ever resolve (understandably)

    #82075

    PRT mods on the forums are not from ITF company which is the developer and “level 2” for technical issues support (to be more precise).

    I don’t know if it is related or not, but what I know is that some of my past customers were having issue to send more than 1 order at the same time with other trading platform with IG, that’s the reason why I talked about it. It is not more about (I think) the server not able (wanted) to receive a lot of orders at the same time, than order badly ‘described’.

     

    #82082

    Oh right ok – so ITF is separate from PRT/they are different organisations? I thought PRT was the product of ITF but that is interesting and I think goes a long way towards explaining why the support chain is so infuriating but alas I digress…

    So Ulrike (and Jakub and I think it is Illaria and maybe others) who is marked as a ProRealTime Moderator in this thread https://www.prorealcode.com/topic/5-strategies-stopped-this-morning/ is not from ITF – OK got it

    As you can see from Ulrikes reply in that thread the issue described (yes I know it is that different error message but still…) was a known issue which was due to PRT not getting a reply from IG’s server or an ‘Invalid Order Status” and so triggers an inbuilt security to stop the strategy which is apparently fixed in the Demo and was due to be released on the Live platform but no further confirmation this has actually been done (?)

    My money (no pun intended 😉 is still on the fact that orders no matter what TF they are coded in are executed at the smallest allowable TF of 1 second so when there is a candle ‘missing’ on the 1 second TF at the same time PRT tries to submit an order no response is received – PRT then tries to resubmit the order yet there is another candle missing and by now the response is too long and so the strategy bombs out OR there is a candle generated and IG then receives multiple orders and rejects them as I guess would happen with any broker as you say Nicolas – if this were the case then surely it is up to PRT to ‘deal’ with this as IG is acting as any broker would – or is it just impossible and this is one of the (very high) risks of automated trading that cannot be overcome?

    (GraHal – don’t know if it is even possible/too far back or if you have the will to do it but you could try and take a look at the examples you sent on the 1 second TF and see if candles are missing at the time of the issue? or of course I could be barking up the wrong tree…)

    #146469

    Hi GraHal,  if running 2 similar strategies and both executed a buy order at the same time, one get’s likely rejected with the message in the pic of your first post.

    I suppose if you add that the order is executed in one strategy xx milliseconds later but in the same bar, the problem would be solved. (unless maybe that there no data on that specific bar)

    Have you experimented with this?

     

     

    #146470

    No I haven’t experimented.

    I often Forward Test several forks of the same strategy and so I’ve had this duplicate error loads.

    Mostly my 2nd Order (duplicate of the 1st, but in a separate strategy) does get filled and shows a time of 1st Order + 1 second. Order fill could be milliseconds after 1st Order got filled but I guess the clock reads to nearest next second?

    Yes Paul I reckon if a delay of x milliseconds were coded to (an otherwise) duplicate Order then that might be a work around?

    You could do a trial on a 1 min TF with a 1 second delay and if it works, keep reducing the delay by 100 milliseconds then by 10 msec until it stops working?

    Let us know how you get on please?

    #146471

    unless maybe that there no data on that specific bar)

    If there were no data on the trigger bar then neither Order would get triggered by that no data bar?

    If there were no data on the bar following the trigger bar then both Orders would attempt to fill on the next bar with data?

    #146478

    About the next bar, the solution would be as in the manual, to repeat the order xx bars till it’s done. But it’s not so good to implement in my code.

    But the time delay in milliseconds should be easier. I’ve found before a code of Nicolas where he used it, but I can’t find it anymore.

    I will run some tests.

    1 user thanked author for this post.
    #146482

    @random45689

    >> Please update your country flag in your profile. Thank you 🙂 <<

     

    edit: wrong post

Viewing 13 posts - 16 through 28 (of 28 total)

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