An Enter method to submit an entry order has been ignored...

[Pete S]

I'm working on a breakout long/short strategy. It is using EnterLongStop and EnterShortStop to submit the entry orders. Obviously, only one of those can be active at a time. I am seeing the above error in the log. I have read the help section it refers to.

The pseudocode for my strategy would be like this:

if (flat and Close[0] above mean)
EnterLongStop()
else if (flat and Close[0] below mean)
EnterShortStop()
else
do other stuff

This means that the orders will be submitted every bar, which is my understanding of what I have to do to keep them alive. It also means I may switch directions: submit an EnterShortStop the bar after an EnterLongStop as long as I am still flat. Per the help, which states:

Methods that generate orders to enter a position will be ignored if:

• A position is open and an order submitted by an exit method (ExitLongLimit() for example) is active
• A position is open and an order submitted by a set method (SetStopLoss() for example) is active
• The strategy position is flat and an order submitted by an enter method (EnterLongLimit() for example) is active
• The entry signal name is not unique

I can only guess that it's one of those two things that is causing the issue. Do I have to specifically cancel or modify the existing order?

[NinjaTrader_Ray]

The problem I suspect is...

Bar1 - Buy stop condition is true and submitted
Bar2 - Buy stop condition is true and submitted
Bar3 - Sell stop condition is true, order method called but ignored since buy stop likely has not yet been removed from internal queing etc...

I will check if this is expected behaviour or if something could be done. I suspect its expecte since we really would want to see the 1st order cancelled prior to a new one submitted to protect from unwanted fills etc...

[NinjaTrader_Ray]

After further investigation, here is what is happening using the same example as my prior post.

On OnBarUpdate() processing for Bar3, its not until after the user code contained in the OnBarUpdate() method is processed that we cancel the original BuyStop. This is because we need to process the code to see if the original BuyStop has been resubmitted. Therefore, in this processing of OnBarUpdate() the sell stop is then ignored since of course the buy stop does not expire until after your user code is processed.

So what can you do?

I can think of two potential workarounds.

- Use unique signal names for your long and short entries. Then Set EntryHandling property to UniqueEntries intstead of AllEntries.

- In 6.5 we have introduced order overloads that have a parameter named "liveUntilCancelled". Use this overload and set this parameter to a value of true. On Bar3, call the CancelOrder() method first on the buy stop and then issue the sell stop. I believe this order cancellation will internally clear some signal queing/tracking that will clear the path for the sell stop order to go through

[Pete S]

Thanks for following up on this Ray.

After further investigation, here is what is happening using the same example as my prior post.
- Use unique signal names for your long and short entries. Then Set EntryHandling property to UniqueEntries intstead of AllEntries.

- In 6.5 we have introduced order overloads that have a parameter named "liveUntilCancelled". Use this overload and set this parameter to a value of true. On Bar3, call the CancelOrder() method first on the buy stop and then issue the sell stop. I believe this order cancellation will internally clear some signal queing/tracking that will clear the path for the sell stop order to go through

I think the first option will cause some other side effects with IB...I will try the second one first and see how it goes.

[Pete S]

I've tried both of these out, with the same behavior (the order is ignored when I try to switch sides).

In my opinion, this should work the way I have coded it. If I was long, and wanted to go short, all I have to do is call EnterShort(). (I understand the technical details of why it is different wrt the outstanding order.) This seems like something the order management layer should handle (figuring out the orders which need to be cancelled based on the position, etc.)

The net result of this right now for me is this strategy will be 1 bar (5 minutes) late catching a breakout if the market quickly changes direction.

[NinjaTrader_Ray]

As you have found out, my first potential workaround fails. I see now why that is and is expected. I will double check again on expected behaviour of my second workaround. I really thought that should work and need to check if I was wrong or if there is a bug here.

A third workaround would be to self monitor the stop prices and issue a market on breach of this price. I do understand the down side of this approach...just throwing more ideas out.

[NinjaTrader_Dierk]

Pete,

Could you PM me a simple as possible sample strategy to "dierk AT ninjatrader DOT com" which demonstrates that Ray's workaround fails?

Additional info like strategy settings, data set etc. would help as well

Thanks

>> - In 6.5 we have introduced order overloads that have a parameter named "liveUntilCancelled". Use this overload and set this parameter to a value of true. On Bar3, call the CancelOrder() method first on the buy stop and then issue the sell stop. I believe this order cancellation will internally clear some signal queing/tracking that will clear the path for the sell stop order to go through

[Pete S]

I will put that together at some point today and send it over.

[NinjaTrader_Dierk]

Next NT6.5 will hold a fix covering this issue in backtest mode. It should not have happened in live mode though. Thanks for providing the info to track down this one.