Detecting if Stops are successfully setting

[MarketAlly]

There should be a method to determine if a stop set by a strategy is successful. We write fully autonomous strategies but it is still disconcerning that this platform does not provide a method for querying if a stop has been successful set. Instead it fails quietly.

Does anyone know how we may go about determining if a stop is indeed set apart from setting excessively deep entries? I am ok with an event like OnOrderUpdate for orders like the one I use to monitor orders but this will not return targets/stops that fail in the same iteration.

Any assistance is greatly appreciated.

[koganam]

There should be a method to determine if a stop set by a strategy is successful. We write fully autonomous strategies but it is still disconcerning that this platform does not provide a method for querying if a stop has been successful set. Instead it fails quietly.

Does anyone know how we may go about determining if a stop is indeed set apart from setting excessively deep entries? I am ok with an event like OnOrderUpdate for orders like the one I use to monitor orders but this will not return targets/stops that fail in the same iteration.

Any assistance is greatly appreciated.

How is the Stop being set? Using Set...() methods or Exit...() order methods?

[NinjaTrader_Jim]

Hello MarketAlly,

Thanks for your post.

The Set methods for profit target and stop loss are intended to be used to prep NinjaTrader to submit orders for profit target and stop loss once an Entry order has come back as filled. It is recommended to use the Set methods in OnStateChange if you are using a profit and stop with a static price level that does not change. If you are using a profit target or stop loss that would change or you wish to update in OnBarUpdate, it is advised to reset the stop loss to the next intended level when the strategy's position is flat. This way the stop loss and profit target will not be submitted with a previous level.

Note from the help guide:

Should you call this method to dynamically change the stop loss price in the strategy OnBarUpdate() method, you should always reset the stop loss price / offset value when your strategy is flat otherwise, the last price/offset value set will be used to generate your stop loss order on your next open position

For troubleshooting, you could enable TraceOrders and use prints to quickly determine if the method was reached and if the target and stop were sent.

Notes and tips when using the Set methods can be referenced here - https://ninjatrader.com/support/help...etstoploss.htm

Documentation on using TraceOrders can be found here - https://ninjatrader.com/support/help...aceorders2.htm

Please let us know if we can be of additional help.

[MarketAlly]

Hello MarketAlly,

The Set methods for profit target and stop loss are intended to be used to prep NinjaTrader to submit orders for profit target and stop loss once an Entry order has come back as filled. It is recommended to use the Set methods in OnStateChange if you are using a profit and stop with a static price level that does not change. If you are using a profit target or stop loss that would change or you wish to update in OnBarUpdate, it is advised to reset the stop loss to the next intended level when the strategy's position is flat. This way the stop loss and profit target will not be submitted with a previous level.

Please let us know if we can be of additional help.

I am following the instructions but if you call a SetStopLoss or SetProfitTarget and the market is moving very fast, it can move past your preset values and it will ignore the command. This will leave an intended OCO with one of the legs empty if it fails. Since the platform doesn't fire a message in this event, there is no way for our strategy to detect and resubmit it at a different calculated level.

[NinjaTrader_Jim]

Hello MarketAlly,

I will need an example to see how your stops and targets are being placed to provide further input. I'll run through an example of what we should expect to see.

Using the code below, we can see an example of a stop and target being updated dynamically and being reset when the strategy is flat and before the next entry gets submitted.

protected override void OnBarUpdate()
{
	if(State == State.Historical)
		return;
	
	if(Position.MarketPosition == MarketPosition.Flat)
	{
		SetProfitTarget(CalculationMode.Price, Close[0] + 10 * TickSize);
		SetStopLoss(CalculationMode.Price, Close[0] - 10 * TickSize);
		
		EnterLong();
	}
	
	if(Position.MarketPosition == MarketPosition.Long)
	{
		SetProfitTarget(CalculationMode.Price, Close[0] + 10 * TickSize);
		SetStopLoss(CalculationMode.Price, Close[0] - 10 * TickSize);
	}
}

If we test again having the profit target and stop loss changed to a level on the other side of the market, we will get an immediate fill for the Profit Target's limit order and a rejection for the Stop Loss' stop order. The method should not be ignored and the orders will be submitted at the price set by the method. If the price level is in the opposite side of the market, we will get a rejection for the stop and the limit order will fill.

if(Position.MarketPosition == MarketPosition.Flat)
{
	SetProfitTarget(CalculationMode.Price, Close[0] - 10 * TickSize);
	SetStopLoss(CalculationMode.Price, Close[0] + 10 * TickSize);
	
	EnterLong();
}

Now if we remove our return statement for historical data, the rejections would not be seen throughout historical processing and we would see them filled. We could submit a request to have this behavior changed if you would like.

Could you provide an example similar to what is provided above and elaborate on how you are seeing this method getting ignored?

[MarketAlly]

Hello MarketAlly,
If we test again having the profit target and stop loss changed to a level on the other side of the market, we will get an immediate fill for the Profit Target's limit order and a rejection for the Stop Loss' stop order. The method should not be ignored and the orders will be submitted at the price set by the method. If the price level is in the opposite side of the market, we will get a rejection for the stop and the limit order will fill.

It is the rejection of the Stop Loss which if markets are moving fast, it could occur. It is rare but it does happen. How do I capture the rejection of the stop? I did not see this under my "OnOrderUpdate" Are you saying this will fire a message? I didn't see the message while running the strategy in Playback101; should I see this here? Are these messages universally returned by all brokers with live data?

I get the fill for the original order placed, I am ok with the ProfitTarget filling immediately but the Stop is where I am struggling. I need to know it is set. Can I query the strategy like I can for open orders? To get a list of pending orders aka stops and profittargets open?

While I have added logic to cancel orders that go against my directional logic but the stop ensures if runaway elevator drops occur (as they do from time to time) - it will not take more than my calculated risk.

[NinjaTrader_Jim]

Hello MarketAlly,

The Set methods prep NinjaTrader so the next entry that is bound to the set method will submit a limit order and/or stop order for profit target and stop loss. If this happens to be on the other side of the market, the order gets rejected by the simulator or the exchange. NinjaTrader should not silently ignore or modify the submission as long as the stop has been set appropriately and we have not hit an internal rule that may prevent this. We can expect this behavior with all exchanges to reject an order that is invalid at that time.

When you get the rejection, the strategy will abort if it does not set the RealtimeErrorHandling property to ignore errors. If this property is set, the strategy will stay running, and the rejection can be seen in OnOrderUpdate().

RealtimeErrorHandling - https://ninjatrader.com/support/help...orhandling.htm

If you are not seeing the stop loss submit, I would suspect that an internal order handling rule is preventing the order submission, or the stop loss is not being set before the new entry is submitted.

In addition to using TraceOrders, you may wish to reference the Internal Order Handling Rules that Reduce Unwanted Positions - https://ninjatrader.com/support/help...antedPositions

If you are seeing something that is contrary to this behavior, we should look into this further with a reduced example and a set of Market Replay data we can use to see the same behavior on our end.

I look forward to being of any further assistance.