Sometimes Exit Orders don't work reatime

[NinjaTrader_JoshP]

If you aren't receiving any events you need to take it a step back and figure out what is happening with your IOrders. Print the IOrders directly.

[brownfox777]

Print the IOrders directly.

Sorry I dont understand how can I do it.
Are these lines wrong?

Print("STOP --------------- " + stopShortOrderN.OrderState);
Print("TARGET ---------------- " + targetShortOrderN.OrderState);
Print("STOP --------------- " + stopLongOrderN.OrderState);
Print("TARGET ---------------- " + targetLongOrderN.OrderState);


Print("ENTER LONG ++++++++++++++ " + entryLongOrderN.OrderState);
Print("ENTER SHORT ++++++++++++++ " + entryShortOrderN.OrderState);

Ñould you give an example of another Print the IOrders directly?

[NinjaTrader_JoshP]

If you aren't getting any prints it suggests you never even entered that code block. The only way it would not enter that code block is if your IOrder is still null or if the .Token != order.Token. You need to try and figure out what is going on with that IOrder. You may even want to just print every single OnOrderUpdate() event regardless of where it originates from and just do order.Name to get the signal name it came from for correlation purposes.

[darckeen]

As i'm sure you've figured out by now orders are processed differently when live versus backtest. In a backtest orders get filled immediately on a single thread. When live, orders get processed overtime in multiple threads. This is probably whats causing the problem. I'd guess that somewhere an order is getting canceled or changed or added by the internal order handling rules. The easiest way to figure out whats happening is to print every event from OnExecution, OnOrderUpdate and OnPositionUpdate and see how the order threading works.

[darckeen]

Since i'm bored i'll explain a little further. As i said orders are multi-threaded when running live. Additionally the system maintains an internal order queue. When orders are submitted to the internal order queue they are immediately subject to the internal order handling rules based on your current position state.

This can cause problems because orders in the queue are in different states. For example: if an update of OnBarUpdate i have a long position and i ExitLong() and EnterShortLimit(). What will happen is that my the EnterShortLimit() will enter the internal queue when the internal order handlng believes i'm long because the ExitLong() hasn't executed yet. As a result the system will add another limit order to close the position. The end result is that you'll be double short when all the orders are executed.

In your case your probably trying to enter your new stop/target before the ones associated with your old position have been cancelled. In order to avoid this you need to maintain your own external order queue and submit orders in OnOrderUpdate() after conflicting orders have been canceled/executed.

[brownfox777]

Thanks, darckeen.
Explanation was detailed and clear. Now it is clear that this situation may occur with any, even the simplest strategy. Maybe you have links to examples of advanced order-tracking algorithm, described by you. Thanks in advance.

[darckeen]

I'll look and see if i have something that does what i'm talking about but the basic point is that when using limit orders live you need to be aware of the effect of threading and the NT order handling rules will have. Ultimately you need to either construct your strategy around them avoid their effect by maintaining your own order queue. Personally I find the internal order rules to hinder and complicate strategy development 9 times out of 10. I really wish there were someway to turn them off.

[NinjaTrader_Bertrand]

brownfox777, the 'Internal Order Handling Rules' can be found on the bottom section of this link - http://www.ninjatrader-support.com/H...verview36.html

Allowing users to program around those rules is already on our future consideration list.