I have experienced the same problem. Some details.... 1) I used OCA orders (with a profit and stop order) without issue on the ES. Then I started trading the TF and hit the problem you are having every 3rd or 4th (TF) order. 2) The Profit limit order was being transmitted, but not the stop loss order. If I manually transmitted the stop order (in TWS), it would transmit, but not be in the same OCA group as the limit order, so when the limit order was hit, the stop remained. This obviously created a mess, so I stopped using OCA orders. 3) I never experienced the problem paper-trading (over a 3-4 month period) - only live trading. This could be due to the papertrading system capturing much more data, and therefore submitting the orders a little slower. 4) I thought because it was happening on the TF but not the ES it could be something to do with the ICE exchange...maybe something related to setting outsideRth to true...but was never able to prove it. 5) I submitted a ticket to IB, who suggested it could be corrupted TWS settings, and that I needed to change the settings directory to generate new settings files. I never tried this, since I wasn't prepared to risk the potential loss associated with the problem recurring. The 30ms delay fix sounds like a feasible solution, which I may try....thanks for this suggestion.
Isn't this exposing you to additional risk? What if your program crashes, power goes out, internet drops, TWS doesn't report the fill, etc between placing the original order and placing the OCA orders? By placing the entry order and the profit limit and the stop loss order all together you get all or nothing, so if there is a system failure you are protected.
FWIW, I tried a bunch of different things today, here's what I found: - placing a 100ms Sleep() after all calls to placeOrderEx(), I see that all orders are properly joined to the OCA group but still many orders would remain in the "awaiting transmitting" state. So some improvement. - placing a 200ms Sleep() after all calls got rid of most but some remained - placing a 300ms Sleep() after all calls has so far allowed all orders to be transmitted and joined to the OCA group. I'm troubled by this since that means 1sec or more to just place the order. Not a huge deal in some circumstances but it could be a problem at times. Just something to be aware of. Maybe not a huge shock but IB isn't a platform/broker for very fast scalpers. Thanks to everyone who offered suggestions. I'd been sweating over this for weeks so it's great to get some working fix. You guys are great, giving better answers than the IB tech support!
I can also confirm that adding the 300ms delay between orders fixes the problem. Thanks to everyone for their help.
Hi, Is it possible to send bracket orders with multiple targets? I'm able to send bracket with a single protective stop and a single target, and that works well. But I would like to have two target orders at different price. Such that total entry qty = 2. Stop qty = 2, and target limit qty = 1 for each of the 2 target orders. When I try to submit this, the qty of the target orders get automatically changed to qty=2. Would really appreciate if someone could explain what solution is required here.. ?
For trading ES, I like the new Zen-Fire 64 running on Mirus Live for Ninja 64 7 on Windows 7 64 all in native 64 mode to take advantage of my Intel quad core. It is faster than me, and I have seen nothing faster especially for ES. Note while they may say beta, it works fine, no bugs right now.
Want to bump the old thread. I'm having these problems and would like to know if a better solution was found. Short recap of the prob: submitting a bracket order (main with two children), one of the children (stop loss) is not submitted (stays in the Inactive state), but the main order is submitted and can be filled, leaving unprotected position. Happens on live account. The last order in sequence is submitted with m_transmit=true. Java API. From the API point of view it looks like this: after the last order is submitted, the openOrder() is called with the id of that last order, and then called once again with the id of the main order. It's not called with the id of the second order. In the case when IB processes such a bracket order correctly (which is approximately 4 out of 5 brackets), openOrder() is called properly with ids in reverse sequence: last, middle, main. By the way, this is the way to determine the bracket order was submitted ok. Another observation: the problem manifests if orders are executed from a US location, does not manifest if executed from a European location, that is has something to do with latency.
Check this post here where dst says this will be fixed: http://elitetrader.com/vb/showpost.php?p=3974057&postcount=20 I've had the same issue with the API for a while - child order can't find the parent and doesn't submit. Meanwhile the parent sits in gray inactive status in TWS. For some reason it only seems to happen to me first thing in the morning (at least that's the only time I notice it).
Yes, thanks for the prompt reply. The prob I described is similar to yours, but vice versa: the main is submitted, but a child is not. This way it's more dangerous as the main can easily get filled, without stop loss in place. BTW, I'm familiar with the problem you mentioned too This one is easier in the sense nothing can be filled as the main is not accepted. I reposted this in the execution forum, more appropriate place: http://elitetrader.com/vb/showthread.php?t=284286