Is anybody running automated trading strategies successfully with IB using TWS?

[Operandi]

Hi Dierk

That is actually the first explanation of the problem that I've seen.

Why are IB not co-operating in either explaining to you about the significance of these redundant order status events, or correcting the problem, if there is one, with TWS?

IB API support staff have told me that there is frequent communication with your staff, so it seems very strange that this damaging failure has not been resolved.

Chris

[NinjaTrader_Dierk]

Unfortunately I have no feedback on that issue from IB.

[heech]

Guys, let's not get confused here: the IB issue we are aware of results from TWS throwing "redundant" order status events. This causes issues as you would code a strategy using the OnOrderUpdate method, since NT needs to map partial fills with related order status events which would fail as there are "redundant" order status events reported by TWS.

We held off filtering this "redundant" order status event from TWS since we have no sufficient info form IB to fully understand understand the nature of this "superfluous" order status event.

However, coding against the OnPositionUpdate and OnExecution method is safe and would not yield such problem.

Well, I just have to say it's very refreshing to get this type of detail from NT. Even if a fix isn't immediately available, at least it lets us know the scope of the problem and design our own workarounds. A regularly updated, detailed knowledge-base for problems you've come across would be incredibly helpful, and the hallmark of a professional development company.

For those who're struggling with this bug, as far as it breaking your pre-programmed limit/stop orders... I guess the only solution I'd suggest is getting away from using NT's support for those box orders. I did very early in the process, because of issues I was having with multi-day executions.

For a work around... you can try catching actual fills coming in OnExecution, and then adjust (or establish) stop/limit orders based on the quantity of the execution. To replace a stop/limit order, I store the new quantity I want in a global variable... and then cancel the existing order. In OnOrderUpdate (for catching the canceled order), I'll re-establish the stop/limit order with the new quantity.

[Thalamus]

Programming or IB to blame?

Thanks for the info Heech. I admit even partial automation is so much nicer than doing it manually, but it would be nice to get this little bug fixed. Dierk, are you thinking my programming is off or this is an IB issue (from my previous comments)? I can submit logs or whatever if that will help. Thanks, Dave

[NinjaTrader_Dierk]

You would need to post the exact error message (screen shot?) for a proper analysis.

[heech]

Thanks for the info Heech. I admit even partial automation is so much nicer than doing it manually, but it would be nice to get this little bug fixed. Dierk, are you thinking my programming is off or this is an IB issue (from my previous comments)? I can submit logs or whatever if that will help. Thanks, Dave

Thalamus,

Just to be clear, what I suggested above would still be "full automation", from the user point of view. Your code would still be setting the stop/limit orders. I just wouldn't trust NinjaTrader's code to create those orders on the basis of a fill... instead, it's not too difficult to use IOrder and OnOrderExecution to have your own code create those orders.

[NinjaTrader_Dierk]

To clarify: there is no OnOrderExecution method. There is a OnExecution method which would not exhibit this IB issue whereas OnOrderUpdate would. The latter has a IOrder parameter the former not.

[heech]

To clarify: there is no OnOrderExecution method. There is a OnExecution method which would not exhibit this IB issue whereas OnOrderUpdate would. The latter has a IOrder parameter the former not.

You're right of course. OnExecution, and IExecution. The strategy remains valid.

[BillCh]

Well, people are very polite here. NT is selling us a software and clearly states IB as one of the supported brokerages. But if the software is not capable of sending/receivning/managing orders with this brokerage the product information is missleading. We are talking real money which can be lost.

And we dont care wheter it is caused by IB, by NT, or by whatever other reason. If there is serious bug or problem, inform and warn people! I am a subscriber to NT and an IB customers, this is clearly stated when purchasing the license. So it would be the least to get an email and/or call from an NT rep to warn about that issue, and to provide clear and complete code examples of which entry and/or exit orders not to use and which and how to use!

I just by accident run into this thread, and I am pretty sure not every NT + IB user did. And if, maybe they face the same problem as I do - not understanding what is wrong and what needs to be done!

I spent the last three weeks to recode my trading script from a different trading platform to NT just to realize now how unsecure it is or can be to use NT according its description provide in the help files etc.

[NinjaTrader_Dierk]

@BillCh: let's not get confused here.
- NT by no means is "not capable" to manage IB orders. In fact several hundreds of users trade on IB through NT every day since years no problem.
- there are clear samples e.g. on this forum on how to use the NinjaScript methods OnBarUpdate, OnExecution etc. However, over time we will add more educational material
- on this very scenario I described in my post #45 below you would get a clear warning which is part of many NT internal consistency checks
- on automatic trading you always needed to be prepared to face the "unexpected". Thus at best you monitor your strategy and never leave it unattended: that's what we always recommend

Hope this helps

[heech]

I spent the last three weeks to recode my trading script from a different trading platform to NT just to realize now how unsecure it is or can be to use NT according its description provide in the help files etc.

Frankly, I've been very tempted to be angry at NT (and have given in to that temptation on a few occasions). I'm a developer, I absolutely understand bugs happen... but I'm less understanding about the slow rate at which these (critical) issues are being addressed in many cases, and I'm very disturbed at the lack of information we're usually given on a lot of these issues.

But that being said.. I'm still sticking with NT because I think it's still probably the best product I've come across. It's reliable 99.99% of the time, and is allowing me to implement a far more complicated strategy than I was originally planning (on other platforms). And in the 0.01% of the time when it's not reliable, I can mostly find work-arounds.

I would easily pay $10k, maybe even more for a better product... but since I don't see one, well, I'll just have to put up with this. (I would pay $10k and sign a NDA for continued access to NinjaTrader's source code too, by the way... just so that I can track down/propose fixes for some of the problems I see.)

Let me end up this discussion by saying I've now been running automated on IB for 2-3 days, with about 30 trades crossing in that timeframe. I did have some problems yesterday, because I didn't realize "exchange" had to be set correctly in the instrument manager when using IB. But other than that, it hasn't been a problem. I do get the warning messages about mismatched execution on partial fills, but that hasn't affected my execution at all. So far so good.

[NinjaTrader_Dierk]

Thanks for your feedback.

[Thalamus]

Partial fills not working correctly

I'm still having problems getting my target limit and stop loss quantities to agree to my purchase of stock or futures. One contract or 100 shares works flawlessly. I'm assuming maybe it is a simple coding error and I've included the code here: Any suggestions appreciated .

protectedoverridevoid OnExecution(IExecution execution)
{
/* We advise monitoring OnExecution to trigger submission of stop/target orders instead of OnOrderUpdate() since OnExecution() is called after OnOrderUpdate()
which ensures your strategy has received the execution which is used for internal signal tracking. */
if (entryOrder != null && entryOrder.Token == execution.Order.Token)
{
if (execution.Order.OrderState == OrderState.Filled || execution.Order.OrderState == OrderState.PartFilled || (execution.Order.OrderState == OrderState.Cancelled && execution.Order.Filled > 0))
{
if (Position.MarketPosition == MarketPosition.Long)
{//If Long order filled, enter stoporder and target limit order
stopOrder = ExitLongStop(0, true, execution.Order.Filled, execution.Order.AvgFillPrice - .60, "MyStop", "MyEntry");
targetOrder = ExitLongLimit(0, true, execution.Order.Filled, execution.Order.AvgFillPrice + .60, "MyTarget", "MyEntry");
}

// //If Short order filled, enter stoporder and target limit order
stopOrder = ExitShortStop(0, true, execution.Order.Filled, execution.Order.AvgFillPrice + .60, "MyStop", "MyEntry");
targetOrder = ExitShortLimit(0, true, execution.Order.Filled, execution.Order.AvgFillPrice - .60, "MyTarget", "MyEntry");
// Resets the entryOrder object to null after the order has been filled or partially filled
if (execution.Order.OrderState != OrderState.PartFilled)

entryOrder = null;

}
}

// Reset our stop order and target orders' IOrder objects after our position is closed.
if ((stopOrder != null && stopOrder.Token == execution.Order.Token) || (targetOrder != null && targetOrder.Token == execution.Order.Token))
{
if (execution.Order.OrderState == OrderState.Filled || execution.Order.OrderState == OrderState.PartFilled)
{
stopOrder = null;
targetOrder = null;
}
}
}

[NinjaTrader_JoshP]

Don't check the IOrder. Just use execution.Quantity.

[Thalamus]

Give your suggestion a try

Thanks Josh, I'll give that a try this evening. Trading single contracts of futures today and it works very well--I can daytrade 3 different futures (YM, ES, CL) and do a full-time job at the same time. Doing multiple contracts would be nice in the future after proving my system works however.