EnterLongLimit

[staycool3_a]

Hello,

I am entering based on a limit order. The below behavior I am seeing is in Strategy Analyzer. The below behavior is consistent whether if I have "fill limit orders on touch" checked on or off.

			EnterLongLimit(17,true,Convert.ToInt32(fxToBuy), ( Lows[17][0]+ Highs[17][0])/2, @"Long1_aud");

Question 1)

Say in my backtest, there were 100 trades. It seems 50 of them end up having multiple entries. In other words, say fxtobuy in the above code is 300,000 - the NT execution engine is splitting the quantity for many of my trades in 100k lots and then entering these in the market. Please note, I am not doing anything where I am directly telling NT to split my order. Also please note, this does not happen for all of my trades, many of my trades are filling the entire 300k in one instance. My exact entry code is above. Is this expected behavior so to "emulate" real market environment?

Fx market is a fairly liquid market so I'm a bit confused why the orders would be split up to emulate market liquidity.

Question 2)

If above is expected behavior: Say I am trading in the live markets and I have a limit order to buy 300k EURUSD with a entry name "EURUSD_BUY." Further say, 100k worth of my order is filled at 1PM , remaining 200k is filled at 3PM. Do both of those separate fills become part of "EURUSD_BUY" entry? The reason why I am asking this is because my exit orders are based off entry orders names.

Question 3)

Your guide for this type of order states:

The order will NOT expire at the end of a bar, but instead remain live until the CancelOrder() method is called or its time in force is reached.

Continuing the above example and if only half of my order is filled, but after some time, my exit condition becomes true && my position is exited, does the order for the other half of my position that was not filled get cancelled? Also, what is the "time in force" is reached?

******************
UPDATE
******************

I tried with EnterLong instead of EnterLongLimit; the results are the same... for some reason my positions are being entered in increments.... at random times. Attached are the exact entries and exits.

[NinjaTrader_Jim]

Hello staycool3_a,

Thanks for your message.

Question 1)

It sounds like you are hitting partial fills which would be expected to see occasionally with simulated order fills. This can also occur in live markets. There are simulator options to enforce immediate fills and to enforce partial fills in the Options menu of the Control Center. You may also use TraceOrders and the order feedback from OnOrderUpdate to verify the partial fill.

protected override void OnOrderUpdate(Order order, double limitPrice, double stopPrice, int quantity, int filled, double averageFillPrice, OrderState orderState, DateTime time, ErrorCode error, string nativeError)
{
	if (orderState == OrderState.PartFilled)
		Print("Partial Fill occured!");
}

EDIT: Simulated partial fills are only relevant for realtime simulated fills, they would not be relevant in this case as these order fills are from historical simulated fills from the Strategy Analyzer.

Question 2)

Signal names are still paired when partial fills are encountered. Separate exit executions will be tied to the entry by signal names and the partially filled order will reach a terminal state (no longer active) once it is completely filled, or if it is cancelled.

Question 3)

If you receive a partial fill and then your position gets closed from another order, the previous running order that is tied to that entry signal name will be cancelled. This is also the case for LiveUntilCancel orders which do not require you to resubmit the order with each OnBarUpdate() iteration to keep active. LiveUntilCancel does not change an order's Time In Force which will cause a cancellation if reached.

Further reading on monitoring order states can be found in the documentation pages below.

OnOrderUpdate - https://ninjatrader.com/support/help...rderupdate.htm

Order.IsTerminalState() - https://ninjatrader.com/support/help...minalstate.htm

Please let us know if we can be of further assistance.

[staycool3_a]

***************
QUESTION 1
***************

Hello staycool3_a,

It sounds like you are hitting partial fills which would be expected to see occasionally with simulated order fills. This can also occur in live markets. There are simulator options to enforce immediate fills and to enforce partial fills in the Options menu of the Control Center. You may also use TraceOrders and the order feedback from OnOrderUpdate to verify the partial fill.

See attached. I have "enforce immediate fills" and I've selected "fill limit orders on touch." There is absolutely no reason for partial fills. I understand partial fills can happen in real market. But there is absolutely no reason for a 30k (small size) order to be split up in 10k lots in the fx market. If I have a resting 30k limit buy order and GetCurrentAsk comes at or below my limit order.. the entire 30k will be filled 99.9999999999% of the time. NT is partial filling such orders 50% of the time. I'm seeing scenarios where a 10k lot is being split up in 3k, 3k and 4k.

You may also use TraceOrders and the order feedback from OnOrderUpdate to verify the partial fill.

I just did that using both methods. I'm actually having zero partial fills according to TradeOrders and OnOrderUpdate. What else can be causing these mysterious partial fills that are not being labeled as partial fills? I've posted my entries and exits code in my original post. I have about 24 data series loaded. 16 of the 24 data series are daily and 8 are 120 minute.

***************
QUESTION 2
***************
Thanks.

**************
QUESTON 3
*************
Thanks

***************
QUESTION 4
***************
I have another question, I am getting some orders that are being ignored/cancelled b/c my limit to buy is above current ask. Or if my limit to sell is below bid price. This makes sense.

='' Reason='Exceeded entry signals limit based on EntryHandling and EntriesPerDirection properties'

In order to fix this, I've done the below:

			if (XYZ HAPPENS)
			{			
				aud_long_px=(Lows[9][0]+Highs[9][0])/2;
				if(aud_long_px>GetCurrentAsk(9))
				{EnterLong(9,Convert.ToInt32(fxToBuy), @"Long1_aud");}
				else if(aud_long_px<GetCurrentAsk(9))
				{EnterLongLimit(9,true,Convert.ToInt32(fxToBuy), aud_long_px, @"Long1_aud");}				
			}

Is this the most appropriate way to deal with such situations or is there a built in function/order type for limit orders that may be a better solution for me?

[NinjaTrader_Jim]

Hello staycool3_a,

I'll answer Question 4 first and then Question 1 as further steps will need to be taken to understand what is happening exactly.

If a limit order is placed to the other side of the market it will be triggered and will fill "at the limit price or better" so the order will be filled at current market price as that would be the "better" price.

The error your received: "Exceeded entry signals limit based on EntryHandling and EntriesPerDirection properties" means that the the strategy has attempted to place an additional entry order which has been refused because of the EntryHandling/EntriesPerDirection properties configured with the strategy.

EntryHandling - https://ninjatrader.com/support/help...ryhandling.htm

EntriesPerDirection - https://ninjatrader.com/support/help...rdirection.htm

To address Question 1, if the fills are not partial fills, the logic must tell the tale. This kind of occurrence could come up if you are using multiple exits with the same signal name. For example, if the code is not exiting with the line of code ExitLong(20, Position.Quantity, @"AccountProfit", @"Long1_audjpy"); but is exiting with another order method with the same Signal Name ("AccountProfit") then we could see multiple exits being tied to a single entry.

This could be tested further by looking for other exits in your strategy that use "AccountProfit" as the Signal Name or by commenting out ExitLong(20, Position.Quantity, @"AccountProfit", @"Long1_audjpy"); to observe if other exits are influencing this behavior. Our recommendation is to use separate Exit Signal Names to ensure that each exit is easily identifiable.

Finally, I should further clarify with my previous response that partial fills would be relevant for realtime simulated order fills and would not be applicable for historical order fills (backtesting.) I've corrected my first reply so that this is more clear.

Please let us know if we can be of further assistance.

[staycool3_a]

Thanks Jim.

Hello staycool3_a,

If a limit order is placed to the other side of the market it will be triggered and will fill "at the limit price or better" so the order will be filled at current market price as that would be the "better" price.

The error your received: "Exceeded entry signals limit based on EntryHandling and EntriesPerDirection properties" means that the the strategy has attempted to place an additional entry order which has been refused because of the EntryHandling/EntriesPerDirection properties configured with the strategy.

In my last post, I accidentally pasted the wrong error that I was seeing. Your explanation makes sense. NT8/broker should be filling the price at the "better" price if the order is placed on the other side of the market.

However, that is not the case that I am experiencing. My limit orders that are placed on the wrong side of the trade, are being rejected and then the strategy is shutting down b/c the limit order is offmarket. To solve this, I explicitly created a logic to solve the issue (i shared that logic with you in my previous post). After I placed this logic, my entries seem to not get rejected and my fills are being made at the appropriate price.

The error that I am getting is:

Default Disabling NinjaScript strategy 'FeaturePortfolio3Excel/147593214'

Order Playback101, Limit price can't be smaller than current bid. affected Order: SellShort 9000 Limit @ 0.71836

Default Strategy 'FeaturePortfolio3Excel/147593214' submitted an order that generated the following error 'Order rejected'. Strategy has sent cancel requests, attempted to close the position and terminated itself.

Order Order='372dcb6151ec46c28d591b701609b2e1/Playback101' Name='Short1_nzd' New state='Rejected' Instrument='NZDUSD' Action='Sell short' Limit price=0.71836 Stop price=0 Quantity=9,000 Type='Limit' Time in force=GTC Oco='' Filled=0 Fill price=0 Error='Order rejected' Native error='Limit price can't be smaller than current bid.'

NinjaScript NinjaScript strategy 'FeaturePortfolio3Excel/147593214' submitting order

Order Order='372dcb6151ec46c28d591b701609b2e1/Playback101' Name='Short1_nzd' New state='Submitted' Instrument='NZDUSD' Action='Sell short' Limit price=0.71836 Stop price=0 Quantity=9,000 Type='Limit' Time in force=GTC Oco='' Filled=0 Fill price=0 Error='No error' Native error=''

As you stated, NT automatically fills limits at the "best" price. Why am I seeing the above?

To address Question 1, if the fills are not partial fills, the logic must tell the tale. This kind of occurrence could come up if you are using multiple exits with the same signal name. For example, if the code is not exiting with the line of code ExitLong(20, Position.Quantity, @"AccountProfit", @"Long1_audjpy"); but is exiting with another order method with the same Signal Name ("AccountProfit") then we could see multiple exits being tied to a single entry.

I do have multiple entries with different entries on different data series. And then, I do have multiple exits with same exit name on different series. Let me change the exits names and see what happens. Will get back to you asap.

Example of what I have right now:

Entries:

If XYZ
{
EnterLongLimit(1,........"nzdbuy")
}

if ABC
{
EnterLongLimit(2,........"audbuy")
}

If 123
{
EnterLongLimit(3,........"jpybuy")
}

Exits:

If 321
{
ExitLong(1,"exit","nzdbuy")
}

if 858
{
ExitLong(2,"exit","audbuy")
}

if 402
{
ExitLong(3,"exit","jpybuy")
}

***************************
UPDATE
***************************

See attached. I'm showing you all of my entries and exits logic and the outcome.

I did what you suggested. Changed my exit names so that are unique. Strategy entered a 9k buy. System broke the 9k order in 3k's. Entered all 3k's at the same exact time. And then exited.

The reason why this is an issue for me is b/c I am not telling the strategy to break up my orders but it's doing it. The exits are not done at the same time and b/c of this, it concerns me b/c small differences can add up to the upside or the downside.

[NinjaTrader_Jim]

Hello staycool3_a,

Apologies for any confusion. To elaborate more on having limit orders filled at that price order better, this is the case when using limit orders with futures contracts, but in your case you are trading on a forex market and the limit order would be rejected with that error.

This can be tested on a chart using Chart Trader to submit a buy limit order beneath the market price, and then to move that limit order above the market price. This should be done for both a futures contract and for a forex pair. The buy limit order on the futures contract will fill, while the limit order on the forex pair would cancel.

As for creating unique exit Signal Names, I would suggest creating signal names that specifically identify the instrument traded on as well as some further context that describes why the strategy would submit that particular exit method. This way you have unique signal names where each exit cannot be confused with another.

If there is anything else we can do to help, please let us know.

[staycool3_a]

Hello staycool3_a,

Apologies for any confusion. To elaborate more on having limit orders filled at that price order better, this is the case when using limit orders with futures contracts, but in your case you are trading on a forex market and the limit order would be rejected with that error.

This can be tested on a chart using Chart Trader to submit a buy limit order beneath the market price, and then to move that limit order above the market price. This should be done for both a futures contract and for a forex pair. The buy limit order on the futures contract will fill, while the limit order on the forex pair would cancel.

As for creating unique exit Signal Names, I would suggest creating signal names that specifically identify the instrument traded on as well as some further context that describes why the strategy would submit that particular exit method. This way you have unique signal names where each exit cannot be confused with another.

If there is anything else we can do to help, please let us know.

Thanks.

I just figured out the reason behind multiple entries/exits.

Fixed code:

				
ExitShort(20,[B]Positions[20].Quantity[/B],  @"exit",@"Short1_audjpy");

vs

Old code:

ExitShort(20,[B]Position.Quantity[/B],  @"exit",@"Short1_audjpy");

For some reason I was under the impression that Position.Quantity output is based on entry signal name. I vaguely remember reading this either through one of your colleague post or some random forum post.

By definition, Position.Quantity (without the index) returns position for the strategy. How does this change under

1) single instrument with multiple entries. How does one access a specific entry's quantity?
2) multiple instrument strategy. What is expected to return without the [X] index?

Would be great if you can tell me the difference between the below for a multi instrument strategy with multiple positions at the same time

1)

				
ExitShort(20,Positions[20].Quantity,  @"exit",@"Short1_audjpy");

2)

				
ExitShort(20,Positions.Quantity,  @"exit",@"Short1_audjpy");

3) Print(Positions[20].Quantity);
4) Print(Positions.Quantity);

*pls note I have printed 3 and 4 and the values are identical. This doesn't make sense to me b/c I have many other positions in my strategy. Therefore, #4 I was expecting a different output. But at the same time I am confused why adding index to my positions caused my issue to be fixed..

[NinjaTrader_Jim]

Hello staycool3_a,

Objects that are not "plural" I.E Position vs. Positions[BarsInProgress] will represent the data series that is being iterated.

If you place the code within a BarsInProgress check, it would be guaranteed to be called for that data series, and "Position" would represent the Position on the instrument that is currently iterating.

If you do not have the appropriate BarsInProgress checks, then you may be calling your exit on another data series iteration (BarsInProgress iteration.) Position would then represent the position for the iterating data series and not the data series your are trying to exit with.

In short, Position is tied to the iterating data series, and not with the Signal Names used with the Managed Approach order methods.

Further reading on using BarsInProgress checks and the difference between these "plural" multi-series objects can be referenced in the Multi Time Frame and Instruments section of the help guide. I will also provide links to Position and Positions specifically.

Multi Time Frame and Instruments (Important read!) - https://ninjatrader.com/support/help...nstruments.htm

Position - https://ninjatrader.com/support/help.../?position.htm

Positions - https://ninjatrader.com/support/help.../positions.htm

Please let us know if you have any additional questions.

[staycool3_a]

Hello staycool3_a,

Objects that are not "plural" I.E Position vs. Positions[BarsInProgress] will represent the data series that is being iterated.

If you place the code within a BarsInProgress check, it would be guaranteed to be called for that data series, and "Position" would represent the Position on the instrument that is currently iterating.

If you do not have the appropriate BarsInProgress checks, then you may be calling your exit on another data series iteration (BarsInProgress iteration.) Position would then represent the position for the iterating data series and not the data series your are trying to exit with.

In short, Position is tied to the iterating data series, and not with the Signal Names used with the Managed Approach order methods.

Further reading on using BarsInProgress checks and the difference between these "plural" multi-series objects can be referenced in the Multi Time Frame and Instruments section of the help guide. I will also provide links to Position and Positions specifically.

Multi Time Frame and Instruments (Important read!) - https://ninjatrader.com/support/help...nstruments.htm

Position - https://ninjatrader.com/support/help.../?position.htm

Positions - https://ninjatrader.com/support/help.../positions.htm

Please let us know if you have any additional questions.

Thanks.

So long story short. Assuming my primary dataseries is EURUSD. When I was doing #2 below, i was executing my exit on AUDJPY (index 20) but the quantity was whatever the quantity was in EURUSD b/c that is my primary data series.

But if I change the code to #1, then my exit will be based on AUDJPY (index 20) and the quantity will be whatever the quantity is for dataseries with index 20.

Correct?

1.

ExitShort(20,Positions[20].Quantity,  @"exit",@"Short1_audjpy");

2.

ExitShort(20,Positions.Quantity,  @"exit",@"Short1_audjpy");

I'd be all set if you can just confirm the above.

Thank you for your help, Jim.

[NinjaTrader_Jim]

Hello staycool2_a,

So long story short. Assuming my primary dataseries is EURUSD. When I was doing #2 below, i was executing my exit on AUDJPY (index 20) but the quantity was whatever the quantity was in EURUSD b/c that is my primary data series.

Not exactly. Let's assume your primary data series is EURUSD and the first added data series is AUDJPY. EURUSD will iterate on BarsInProgress index 0, while AUDJPY will iterate on BarsInProgress index 1.

If you control your logic so your exit is submitted on BarsInProgress 0, and you also reference Position.Quantity within that same BarsInProgress check, you can expect that Position.Quantity will reflect the quantity on the primary data series. This is because we know that Position is referenced when BarsInProgress 0 is iterating.

If you do not use a BarsInProgress check and use Position, Position will reflect the iterating data series, but the iterating data series may not be the series you expect to be iterating. Specifically, AUDJPY may be iterating so Positon.Quantity would reflect AUDJPY, and not EURUSD.

Using Positions[BarsInProgress].Quantity will be a specific reference to the position of the data series you specify, and not the iterating data series.

Let's also clarify on using BarsInProgress with order submission methods. Please consider the following:

protected override void OnBarUpdate()
{
	if (BarsInProgress == 0) // Make sure the block of code is run on the primary data series.
	{
		ExitShort(20,Position[B]s[20][/B].Quantity,  @"exit",@"Short1_audjpy"); // Submit order to BIP 20 and use the Quantity from BIP 20.
		ExitShort(20,Position.Quantity,  @"exit",@"Short1_audjpy"); // Submit order to BIP 20 use the Quantity from the iterating data series (we do not specify a BIP but we know that this will be iterated on BIP 0 so it will be the primary data series' strategy position.)
	}
}

These behaviors are detailed specifically under the "True Event Driven OnBarUpdate() Method" and "Accessing the Price Data in a Multi-Bars NinjaScript" sections of the Multi Time Frame and Instruments documentation and the documentation for Position and Positions.

If you have any specific questions on the documentation, please don't hesitate to ask.

[staycool3_a]

Hello staycool2_a,


Not exactly. Let's assume your primary data series is EURUSD and the first added data series is AUDJPY. EURUSD will iterate on BarsInProgress index 0, while AUDJPY will iterate on BarsInProgress index 1.

If you control your logic so your exit is submitted on BarsInProgress 0, and you also reference Position.Quantity within that same BarsInProgress check, you can expect that Position.Quantity will reflect the quantity on the primary data series. This is because we know that Position is referenced when BarsInProgress 0 is iterating.

If you do not use a BarsInProgress check and use Position, Position will reflect the iterating data series, but the iterating data series may not be the series you expect to be iterating. Specifically, AUDJPY may be iterating so Positon.Quantity would reflect AUDJPY, and not EURUSD.

Using Positions[BarsInProgress].Quantity will be a specific reference to the position of the data series you specify, and not the iterating data series.

Let's also clarify on using BarsInProgress with order submission methods. Please consider the following:

protected override void OnBarUpdate()
{
	if (BarsInProgress == 0) // Make sure the block of code is run on the primary data series.
	{
		ExitShort(20,Position[B]s[20][/B].Quantity,  @"exit",@"Short1_audjpy"); // Submit order to BIP 20 and use the Quantity from BIP 20.
		ExitShort(20,Position.Quantity,  @"exit",@"Short1_audjpy"); // Submit order to BIP 20 use the Quantity from the iterating data series (we do not specify a BIP but we know that this will be iterated on BIP 0 so it will be the primary data series' strategy position.)
	}
}

These behaviors are detailed specifically under the "True Event Driven OnBarUpdate() Method" and "Accessing the Price Data in a Multi-Bars NinjaScript" sections of the Multi Time Frame and Instruments documentation and the documentation for Position and Positions.

If you have any specific questions on the documentation, please don't hesitate to ask.

Very interesting. Thank you for your help today. Have a good one... until next time... aka tomorrow!

p.s- some of the greatest things are usually discovered accidentally. i think this particular accident we've discussed today actually added tons of value on my end! will be looking into details to see why the value was added. b/c the executions were correct and there is no glitch but rather incorrect quantities were used to exit.

[staycool3_a]

Apologies for any confusion. To elaborate more on having limit orders filled at that price order better, this is the case when using limit orders with futures contracts, but in your case you are trading on a forex market and the limit order would be rejected with that error.

Jim - I completely missed this. Given that it's different for FX, is the code I am using to logically adapt my entry price OK? Or do you suggest something else? The reason why it's annoying (not to mention 6+ hours of wasted time) for me is b/c I'm running 2.5 years worth of test on market replay. Yesterday, my logic worked for 60% of the data and then boom, there was one entry that caused the above/under price limit. I could just restart the market replay at that point but it causes issues b/c i'm looking at historical performance etc. Would be nice to have a logic that would specifically ignore such order rejection and enter the market at the appropriate price instead of ignoring/rejecting and then shutting the strategy down.

I'm using:

if (XYZ HAPPENS)
			{			
				aud_long_px=(Lows[9][0]+Highs[9][0])/2;
				if(aud_long_px>GetCurrentAsk(9))
				{EnterLong(9,Convert.ToInt32(fxToBuy), @"Long1_aud");}
				else if(aud_long_px<GetCurrentAsk(9))
				{EnterLongLimit(9,true,Convert.ToInt32(fxToBuy), aud_long_px, @"Long1_aud");}				
			}

[NinjaTrader_Jim]

Hello staycool3_a,

What you are doing would be an applicable approach, however there could be circumstances where the the market changes before the order fills. This could be mitigated by increasing the distance from the bid/ask or handling the order rejection in the strategy on your own.

It is possible to prevent the strategy from aborting on rejected orders by setting RealTimeErrorHandling to IgnoreAllErrors. You can also trap those rejections in OnOrderUpdate() to have the strategy take a different action.

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

Please let me know if I can be of further assistance.

[staycool3_a]

is there a write up for enterlonglimit that gives details on how this behaves for fx? i tried both methods in strategy analyzer

1)

if (XYZ HAPPENS)
{
aud_long_px=(Lows[9][0]+Highs[9][0])/2;
if(aud_long_px>GetCurrentAsk(9))
{EnterLong(9,Convert.ToInt32(fxToBuy), @"Long1_aud");}
else if(aud_long_px<GetCurrentAsk(9))
{EnterLongLimit(9,true,Convert.ToInt32(fxToBuy), aud_long_px, @"Long1_aud");}
}

2)

EnterLongLimit(17,true,Convert.ToInt32(fxToBuy), ( Lows[17][0]+ Highs[17][0])/2, @"Long1_aud");

seeing about a 20% difference in results. i understand there can be many other things that can cause the difference (mainly in this case.. if one order was misaligned then all other orders will be misaligned in relative to the results for each method), but i'm curious to understand how does strategy analyzer fill using the second method if price is not favorable/offmarket. does it just buy market or does it skip the order?

[NinjaTrader_Jim]

Hello staycool3_a,

The backtesting engine only uses OHLC values and does not use bid/ask so it would not hit rejections for limit orders placed on the other side of the market. These orders will enter immediately, however the back-fill logic will result in a different fill price since a limit order is used.

You may test code similar to the following in the Strategy Analyzer and observe the first few trades on a chart to see the different fill prices but same signals.

protected override void OnBarUpdate()
{
	if(Position.MarketPosition == MarketPosition.Flat)
		//EnterLong("EntrySignal"); // Switch this with EnterLongLimit below
		EnterLongLimit(Close[0] + 1000, "EntrySignal");
	
	if(BarsSinceEntryExecution("EntrySignal") > 3)
		ExitLong(0, Position.Quantity, "ExitSignal", "EntrySignal");
}

We have documentation on historical fill processing which explains how the OHLC values are used to simulate order fills and we also document our back fill logic which describes simulated order fills in greater detail.

Understanding Historical Processing - https://ninjatrader.com/support/help...ical_fill_.htm

Historical Order Backfill Logic - https://ninjatrader.com/support/help...fill_logic.htm

Please let us know if we can be of further assistance.