Stop Order not cancelled ?

[zark.be]

I think it still is the original issue, it's just that it has many repercussions.

Basically our issue is that :

We have a strat running on NT on FDAX .
We have the normal FDAX Session set in our chart

but before a certain time we stop sending our stop order (30minutes before session end)
and we only send our targets 30minutes after session begin; and stop order 45minutes after session begin.

What is happening is that even after session end the stop order is still there.
And then the next day, the session starts , 30minutes after the session start, target orders should be sent, but they are not, and 45minutes later the targets should be sent, but they are not.



So i made a very basic strategy to try to determine the issue, and for some reason NT doesn't cancel the order when it should, and then later rejects the new one thinking there's still an old one in there ...
So I think it's all linked to the fact that ninja didn't really cancel the order.


I'm very surprised you can't reproduce the problem, as I've been doing it on every machine i can put my hands on, with different configurations and all give that same problem.

What is even more strange, is that re-starting the strategy (F5 in the chart), makes it send the targets & stops without problem.
But having it run, and then at a certain time send targets&stops, ... don't work.

So right now we're running a "semi-automated" strategy, since at certain times of day we have to manually restart it to have our targets & stops sent .... this is just plain strange.


Right now office hours are ending here in Belgium, so i'll send you a mail tmrw morning with my phones, so you can contact me when you start work.

[NinjaTrader_RyanM1]

I've not been able to see anything unexpected so far. Are you looking at actual orders placed or simulated strategy orders? Your strategy is setup so that it enters in a position at the start of the strategy run, and then you are unlikely to exit this strategy position because of how your exit rules are defined. This leads me to think there's a misunderstanding of strategy position versus account position, but a phone call may help clear this up.

http://www.ninjatrader-support.com/HelpGuideV6/StrategyPositionVsAccountPosition.html

[zark.be]

I've recorded a screencast : http://www.youtube.com/watch?v=NmyMt9z0RVM

MAke sure you leave the youtube annotations on, as i didn't have a microphone at hand.

edit: re-uploaded it in 720p so now text is smooth and readable.

[NinjaTrader_RyanM1]

Thank you for the excellent video. It helped a lot to understand how you have set this up. As indicated in our email - please test this on version 7 and let us know how it goes. I believe you are running into version 6.5 bug in this area.

[zark.be]

So you do admit this is not normal behavior.

What I don't understand is that this is pretty much a very basic strategy behavior (Sending an order only at a certain time). Has in all those years nobody used this with ninjaTrader ?

[NinjaTrader_RyanM1]

This is not expected behavior and has been resolved in NinjaTrader 7. The issue is not related to time - it's the stop order that is not associated with an actual account position.

[zark.be]

As mentionned a couple of times...

We first noticed the problem on our LIVE machine, running ninja with full licence and ib in real mode.
After losing money, I investigated the problem, and reproduced it easily on my dev machine with the same strategy.
I then made a very basic strat wich demonstrated the issue that you can view in the video.

Our live machine was pretty much in real life position with real contracts and the bug was exactly the same.

Besides saying its a position mismatch is just weird, as we have established that sending the stop with a CurrentBar == 1234 works, but sending it with a ToTime(Time[0]) > 141000 doesn't.

Also as i included in the mail, everytime to Time[0] intervenes, we get that same error.
Even if we just set a boolean value in that condition and later in the code check that boolean to send the stop of not.

We are right now investigating a solution, where we will send the stop order without condition to a hard to reach value, and update it to its real value only between the Hours we specified.
That seems to work at first, but we are testing thoroughly , but is truely a dirty solution.

[NinjaTrader_RyanM1]

Thank you for bringing this to our attention. I used your video to reproduce an issue that was seen on 6.5. It has been fixed in NinjaTrader 7, which will soon be our production release. Please evaluate this scenario there and if you run into the same issue, let us know and if possible include a video demonstrating what you are seeing.

[zark.be]

Okay

it seemed I jumped the gun with the Time[0] explanation.

Further investigation in trying to find a hack to circumvent the problem has raised other things to light.


Your solution of CurrentBar == 1234 works .. but only because it doesn't send any stop orders in the historical part of the chart !!!

The problem only happens when the orders are sent in the historical bars and also in the live bars.
When we get in the live bars it says the order was ignored because it already exists, but it doesn't appear in the CC .. normal, as orders sent in the historical are processed by the internal engine and not sent out. IT seems that once in non-historical bars, orders received are checked in a database of pending orders, and for some reason it still has cancelled orders in it.
Somehow orders sent on the first live bar override this. maybe some sort of quickfix to a bigger problem ?


Proof :

1/ Changing my if(Time[0] > 123400) to if(CurrentBar % 10 == 0) causes the same issue. => Time[0] is not the issue
2/ Changing the condition to not send any historical orders, then live orders work.
3/ Sending orders only in one bar that is non-historical works (CurrentBar ==1234)

[NinjaTrader_RyanM1]

The reason I used CurrentBar was because it can be used to identify a specific bar in the future. It works to make this test a little easier to reproduce. The specific functions used to generate exit signals are not what's contributing to the issue.

To reproduce the issue I saw after watching your video:

• Immediately submit orders is on.
• There is a strategy position but not an actual account position. This doesn't mean the issue can't be seen on live accounts - it just means that the particular strategy instance did not submit an actual opening order to the account.
• The conditions for your exit order should evaluate true at some point after the strategy is started. You used Time to set this up. I used CurrentBar. Either should work provided it's setup this way.

Result with these steps is that the exit order is not canceled, even if a bar has elapsed and even if conditions no longer evaluate true. This is an issue with 6.5 that I did not see with version 7.

These are the factors I'm seeing here. Let us know if we're talking about a different issue.