Hello,
While it seems unlikely, it has actually happened to me many times that I have a signal from a strategy to, for example, buy a contract, that is then triggered in the one second it takes for the strategy to load on the next bar. In this case the strategy will buy at 08:30:01, and then it will buy again at 08:30:02 when it finishes processing and puts in the buy order again. I say it sounds unlikely but it has actually happened to me at least once a week for the last few weeks, especially since I created a 5 minute strategy.
Would using live positions avoid this problem? I have not used live positions to this point because it was not working right for me. It would issue incorrect orders and I gave up on it because it was doing fine without it.
Thanks,
Dandude
While it seems unlikely, it has actually happened to me many times that I have a signal from a strategy to, for example, buy a contract, that is then triggered in the one second it takes for the strategy to load on the next bar. In this case the strategy will buy at 08:30:01, and then it will buy again at 08:30:02 when it finishes processing and puts in the buy order again. I say it sounds unlikely but it has actually happened to me at least once a week for the last few weeks, especially since I created a 5 minute strategy.
Would using live positions avoid this problem? I have not used live positions to this point because it was not working right for me. It would issue incorrect orders and I gave up on it because it was doing fine without it.
Thanks,
Dandude
Rename
Hmmm we’ll have to pinpoint why this is happening to know if using Live Positions would help or not. Is this in a Streaming Chart or the Strategy Monitor? And if the latter what mode is it running in?
I have been using the strategy monitor, and this morning it happened using streaming bars on the 5 minute timeframe. It was previously happening with streaming data as well. Cone advised me to switch to streaming bars when using IB. He also just advised me to switch to polling because of some other data issues I was having, but I have not tried that yet.
And IB is the provider? I’ll ask Cone to scrutinize the IB Streaming Bars code.
Also, I want to be clear. The strategy is not generating an extra signal erroneously, it is having a stop/limit order hit at the precise moment that it is calculating the next bar's signals. So I believe what is happening is that WL is looking at the next bar and in that one second, the previous bar's order is getting hit. That is why I ask about the live position feature because perhaps then WL would check to be sure that the previous order was not triggered before placing the next order.
Yes I am using IB
Ok I misunderstood.
These kinds of disconnects are always possible in algo trading.
Live Positions was developed to help mitigate this, but it would only be useful if your strategy only trades a single position per symbol, and you don’t trade the same symbol among different strategies. The broker only return one position, even though your strategies might be holding several positions in symbol.
These kinds of disconnects are always possible in algo trading.
Live Positions was developed to help mitigate this, but it would only be useful if your strategy only trades a single position per symbol, and you don’t trade the same symbol among different strategies. The broker only return one position, even though your strategies might be holding several positions in symbol.
QUOTE:The title says "Duplicate orders". To us, that sounds like duplicate "Signals".
it is having a stop/limit order hit at the precise moment that it is calculating the next bar's signals
But it sounds to me like the scenario is that:
1. you have 2 Active orders - a Stop order and a Limit order
2. at the end of an interval, two things happen nearly simultaneously:
a. first, the strategy, unaware that an order is being filled, generates the stop/limit bracket orders for the next bar, and,
b. one of the Active stop/limit orders fills.
3. The result is that you exited the position, but a bracket order to exit the position is still Active.
Is that it?
Yes that is basically what is happening. Although when it happened on Friday it was actually an entry order. As you described, the order from the previous bar was hit and filled and then WL generated a similar order (or the same order) for the next bar, and it was also filled, causing a double position.
I often get a message in the log that says "Order #123 could not be canceled, reason: it was cancelled" which I found sort of amusing, but maybe it is related?
I often get a message in the log that says "Order #123 could not be canceled, reason: it was cancelled" which I found sort of amusing, but maybe it is related?
IB's API Guide says error #123 was deprecated. Odd that you're seeing it.
Anyway, it's an edge case that can be expected to occur with some probability, inversely proportional to the bar interval. There's no solution without imposing an excessive delay to always cancel an order at the end of interval, wait for the cancel confirmation, and resubmit the same order, which is an unacceptable scenario because it can result in missing a trade completely.
Aside -
Something you could try (and backtest)is to change the price slightly for each bar. Then you should get the wait-for-cancel-then submit behavior.
Anyway, it's an edge case that can be expected to occur with some probability, inversely proportional to the bar interval. There's no solution without imposing an excessive delay to always cancel an order at the end of interval, wait for the cancel confirmation, and resubmit the same order, which is an unacceptable scenario because it can result in missing a trade completely.
Aside -
Something you could try (and backtest)is to change the price slightly for each bar. Then you should get the wait-for-cancel-then submit behavior.
Sorry I should have been more specific. In my example #123 was just a placeholder for the actual order number which is much longer. I am not seeing any error #123.
I was just mentioning that the log says it needs to cancel an order that was already canceled.
I was just mentioning that the log says it needs to cancel an order that was already canceled.
Your Response
Post
Edit Post
Login is required