ExitLongStop(int barsInProgressIndex, bool liveUntilCancelled, int quantity, double s

[adamus]

I get the error "A Sell stop order placed at '08/10/2002 23:00:00' has been ignored since the stop price is greater than or equal to close price of the current bar. This is an invalid order and subsequent orders may also be ignored. Please fix your strategy."


I am running 2 timeframes in the strategy in question - 60mins (primary) and 1min.

I enter the ExitLongStop with the barsInProgressIndex for the 1min time frame and I see from the logging that the stop price is valid for that 1 min bar in relation to the Close.

The 60mins bar though is completely different and this stop order would be invalid, so the above error would be expected if I submitted the order with barsInProgress=0.

The strategy sets up the order to be placed during onBarUpdate() for 1 min, however since there is an existing open order that requires cancelling, the strategy puts the new order into 'pending' state.

When the order that was cancelled fires the onOrderUpdate() event, the event's barsInProgress is set to 60mins. The pending order is submitted during this onOrderUpdate() event - as a 1min order using that parameter, not a 60min order, however NT still complains.

This only happened once in the course of 20,000 trades with this strategy during backtesting so I assume that something quite unique occurs, but it occurs consistently.

To work around this problem I changed the strategy so that the pending order is submitted on the next 1min onBarUpdate() event, and at that point it is accepted.

However the downside to the workaround is that the position is unprotected in the market for the duration of the 1 min bar when it was originally set up, but before it could be submitted.

[NinjaTrader_Bertrand]

Hi adamus, is this order just used to update your stop value? Couldn't you then just resubmit again on the 1 min bar update to trigger the adjustment? Is there any way I could reproduce this on my end to check into?

[adamus]

Sorry Bertrand I don't understand. What do you mean "just resubmit"?

[EDIT: this is wrong: (This is not a direct update. The previous stop that it is replacing is a single stop order,)] but this order is part of a bracketed limit and stop exit strategy, and it's twinned with a limit order that is given the same associated entry signal.

[EDIT: the limit and the stop are updated.]

I assume you can reproduce the order by setting up the same sort of situation with a strategy:

- you have a long position in the market.
- you have a stop loss below the market
- due to the strategy logic in the 60min onBarUpdate, the strategy cancels the stop loss and places a bracketed limit & stop combination
- the market is very quiet and hardly moves and neither the limit nor the stop are hit and the next 60mins onBarUpdate occurs. The logic sees the position should be exited and sets a flag for the 1min onBarUpdate (for the second time, which rarely ever occurs).
- the 1 min onBarUpdate sets up a new bracketed pair of limit & stop but they are not submitted because the existing orders are cancelled first
- then the onOrderUpdate from the cancellation occurs, and the orders are submitted and the error occurs.

I can send you the historical data for the situation if you don't have it - it's from $AUDUSD 2002.


Doesn't your company have a testing team with this sort of capacity?

[NinjaTrader_Bertrand]

adamus, I was referring to just resubmitting at a new price and qty, this would then update the already working order.

I believe we would have data for this point back in time, however to be most efficient in reproducing this we would greatly appreciate if you could perhaps share your code via email (I suspect you would not like to post it) to support at ninjatrader dot com - I'll then give this a test run here and check into.

[adamus]

I believe we would have data for this point back in time, however to be most efficient in reproducing this we would greatly appreciate if you could perhaps share your code via email (I suspect you would not like to post it) to support at ninjatrader dot com - I'll then give this a test run here and check into.

If I send you my strategy, how likely is it that you use it to trade with? And I guess if you do trade it, would it impact my trading profits?

On the other hand, if I don't send it, you won't be sure there's a bug and you won't fix it.

That's an interesting conundrum.

I guess I'll try to reduce the logic to the bare minimum without losing the issue and I'll forward it to you. Hopefully I can just buy when datetime = 2002-10-08 23:00:00 and enter the stop orders similarly. I can't do that now, I'm in the middle of trying to get this whole show on the road, however maybe at some point next week.

Regarding your phrase "just resubmitting at a new price and qty, this would then update the already working order.":

I am using managed orders and every time I want to move a stop, I cancel and use ExitLongStop(). Are you saying that not cancelling the previous order will actually only change the existing order? Will that work when I'm adding an entry label to it to bracket it with a limit order?

Thanks

[NinjaTrader_JoshP]

adamus,

If you are trying to amend an order you do not need to cancel the order. Simply call the order again with the new quantity and price and it will amend the preexisting order. This will work when you have preexisting orders that match the one you are trying to amend. You can see an example of this here: http://www.ninjatrader.com/support/f...ead.php?t=7499
It amends the order to break even.

[adamus]

Thanks for the info. I was unaware of that functionality.

[adamus]

Hi Josh,

more regarding this replacement order entry: obviously I can't modify a cancelled, filled or rejected order, but are there any other states which I need to check before calling the ExitLongStop method?

[adamus]

Just going over the logging with "modify order" in place, rather than "cxl & replace", and it all works nicely in backtesting.

NT even accepts the "fromEntrySignal" label on the updated stop and makes it OCO with the limit order when that's got the fromEntrySignal too.

It's slowly coming together. I read somewhere that modifying an order is quicker than cancelling and replacing it too, so that's another plus.

Thanks

[NinjaTrader_JoshP]

In regards to your older question, you would also want to check for PartFilled states too and ensure that you handle any positions that may/may not exist based on partial fills.