Announcement
Collapse
No announcement yet.
Partner 728x90
Collapse
NinjaTrader
Stop Orders being cancelled at close of the bar
Collapse
X
-
Hello WalterSkinner,
This is demonstrated in the ProfitChaseStopTrailExitOrdersExample_NT8 linked in post# 7.
- Likes 1
-
Ok great. Because my strategy exclusively uses stops to exit I should be fine then.Originally posted by NinjaTrader_ChelseaB View PostIf you do not want to cancel the order at some point, you do not have to cancel the order.
If that was not the case, like if I exited using a target (sell limit for a long), in this case since I don't want the stop to exist anymore I would need to use CancelOrder()?
Leave a comment:
-
Hello WalterSkinner,
CancelOrder() is used to cancel an order if you don't want the order to be working any more.
If you do not want to cancel the order at some point, you do not have to cancel the order.
Leave a comment:
-
Also, I am more than happy to make the change you suggested and switch over to using isLiveUntilCancelled.
In doing this am I able to just include this:
Wherever I currently use ExitLongStopMarket?Code:ExitLongStopMarket(0, true, Position.Quantity, longTrailPrice, "Stop loss", "Long entry");
While looking at the documentation it mentions using CancelOrder. Is this really necessary? I swapped out the code for what I put in here and replay looks good without using CancelOrder. Will this get me into trouble?
Thanks again for your help and patience.
Leave a comment:
-
Hello WalterSkinner,
I only mentioned an error in response to your mention there was an error in post #10.
The Print() would be the time of the bar and all values used in the conditions that submit the order and would let you know when the conditions are evaluating as true or false.
TraceOrders would let you know when NinjaTrader is seeing the order submission and will let you know if the order is submitted, ignored, rejected, or automatically cancelled.
These you would add. They would not be related to an error message that would appear on the Log tab of the Control Center.
Leave a comment:
-
I wish I had an error for you.
I tried to recreate this situation in market replay so I could debug with print statements but there was no issue in market replay so there is no error to print. The stop was placed normally and was not cancelled.
Leave a comment:
-
Hello WalterSkinner,
I would need to see the output from prints and trace orders to provide any direction.
If you have an error, I would need the full error message.
It would not be necessary to resubmit the order on every tick unless the order is being submitted to the 1 tick series (for example for intra-bar granularity to improve historical fill accuracy).
If you want to keep an order alive and this is an unlocked script, use isLiveUntilCancelled as true.
EnterLongStopMarket(int barsInProgressIndex, bool isLiveUntilCancelled, int quantity, double stopPrice, string signalName)
Last edited by NinjaTrader_ChelseaB; 03-22-2022, 03:04 PM.
Leave a comment:
-
I know I was saying that the execution took place five seconds after the close rather than immediately like it normally does. Generally five seconds do not need to pass before the entry order is submitted following the close of a bar. I pointed this out just to include more info in case it was helpful in identifying the origin of the canceled stop.Originally posted by NinjaTrader_ChelseaB View Post
If Calculate is OnBarClose, the order would be submitted after the trigger bar closes.
I did not get an error.I am not seeing any error message in your post.
What is the full error message you have received?
Closest I can do to providing an error message is a screenshot of the log.
Just to make sure were on the same page here's a quick summary of what happened:
- Went long, stop was placed upon execution
- First bar after trigger bar closes, and on the close of that bar (8:31:57) the stop was cancelled
- Second bar after trigger bar closes, and on the close of that bar (8:32:04) the resubmission put the stop back out there so I was protected again
- Unable to replicate this in market replay has me thinking the issue may be related to Rithmic/connectivity or something else that I'm too ignorant to imagine
Leave a comment:
-
Hello WalterSkinner,
If Calculate is OnBarClose, the order would be submitted after the trigger bar closes.
Below is a link to a forum post that discusses.
I am not seeing any error message in your post.
What is the full error message you have received?
Leave a comment:
-
Hi Chelsea,
Thank you so much for your help!
I just ran the trade through market replay and there was no issue.
One thing that is worth noting is that the execution was five seconds after the close of the trigger bar (set to enter on bar close).
Perhaps there is some sort of connectivity issue with Rithmic?
Any ideas what might lead to this since there was no error in market replay?
Also, does it make sense for me to move the re-submission of the stop to BIP 1 (tick data series)? Or would that bog it down real time?
Leave a comment:
-
Hello WalterSkinner,
To understand the behavior you would need to debug with Print() and TraceOrders.
Printing the time of the bar and all values used in the conditions that submit the order would let you know when the conditions are evaluating as true or false.
TraceOrders would let you know when NinjaTrader is seeing the order submission and will let you know if the order is submitted, ignored, rejected, or automatically cancelled.
Below is a link to a forum post that demonstrates using Print() and TraceOrders to understand behavior.
I am happy to assist with analyzing the output from print and trace orders if you would like to save this to a text file and attach this with your next post.
Leave a comment:
-
Hi Chelsea,
That's the thing, it has been resubmitting stops on every bar with no problems for all other trades. My other trades today were fine aside from the first trade. The first trade did resubmit on each bar after that first post-entry bar saw the stop get cancelled. It was promptly resubmitted on next following bar that canceled the stop (on its close). It has successfully placed hundreds of trades and handled the bar-by-bar replacement on those so the logic has been working fine.
I do start trailing the stop in different ways which is why it feels like it would be simpler to try to figure out why the stop was cancelled on this one trade. I could be wrong, but it seems like due to the trailing if I used isLiveUntilCancelled I'd need to cancel and then replace on each bar.
In the situation today where the initial stop was cancelled, this was before any trail logic kicked in.
A: Trigger bar, stop is placed correctly on execution update.
B: Stop cancelled at the end of this bar, which does not normally happen on other trades either live or in replay
C: Stop re-submitted like you would normally expect (in OnBarUpdate)
I can definitely try to use isLiveUntilCancelled but was also hoping to figure out what is going on here since this base code has served me so well over the past few months without giving me this issue. I have recently changed from volume bars to range bars that's the only change I can think of that might be related to this.
Leave a comment:
-
Hello WalterSkinner,
If an order that is not using isLiveUntilCancelled as true is not re-submitted on every bar it will automatically be cancelled.
If the script is unlocked using isLiveUntilCancelled as true and submitting the order once, is more simple that having to re-submit the order.
Below is a link to an example.
Leave a comment:
-
Hi guys me again.
I have a strategy that uses ExitLongStopMarket and it has been doing fine resubmitting orders on each bar and everything has been going well.
Today I noticed that, after entry and after the stop was placed, the stop was cancelled on the close of the first bar following entry. At the close of the next bar the stop was resubmitted.
The log shows that the stop was cancelled (I emailed the log and trace files today).
I cannot find any reason for this and was curious if this was a common thing you guys see?
Since the strategy already has a tick data series in BIP 1, I was thinking about moving the resubmission from BIP 0 to BIP 1.
Alternatively I was considering using IsLiveUntilCancelled, but I want to avoid making this simple situation more complex than it needs to be. If I do go that route it looks like I'll need to capture the order object in OnOrderUpdate and then use CancelOrder somewhere (possibly where I reset variables when flat).
Thoughts?Last edited by WalterSkinner; 03-22-2022, 10:47 AM.
Leave a comment:
Latest Posts
Collapse
| Topics | Statistics | Last Post | ||
|---|---|---|---|---|
|
Started by kinfxhk, 07-14-2026, 09:39 AM
|
0 responses
19 views
0 likes
|
Last Post
by kinfxhk
07-14-2026, 09:39 AM
|
||
|
Started by kinfxhk, 07-13-2026, 10:18 AM
|
0 responses
60 views
0 likes
|
Last Post
by kinfxhk
07-13-2026, 10:18 AM
|
||
|
Started by kinfxhk, 07-13-2026, 09:50 AM
|
0 responses
43 views
0 likes
|
Last Post
by kinfxhk
07-13-2026, 09:50 AM
|
||
|
Started by kinfxhk, 07-13-2026, 07:21 AM
|
0 responses
47 views
0 likes
|
Last Post
by kinfxhk
07-13-2026, 07:21 AM
|
||
|
Started by kinfxhk, 07-11-2026, 02:11 AM
|
0 responses
38 views
0 likes
|
Last Post
by kinfxhk
07-11-2026, 02:11 AM
|

Leave a comment: