Major Differences Between Live and Simulation In Strategy Function

[GLFX005]

Hello staff,

I am running the newest version of Ninjatrader 8, a clean install. I am running the exact same two strategies, one on Sim101 and the other on my Live account.
I have several parts of code such as the following below that should submit TP and SL orders that are associated to other entry orders.

if (BSL2 != null && BSL2 == execution.Order)
{
if (execution.Order.OrderState == OrderState.Filled)
{
TP12 = ExitShortMIT(0, true, Position.Quantity, Open[0] - Trend * TickSize, "TP12", "BSL2");
SL12 = ExitShortStopMarket(0, true, Position.Quantity, KyoriBands2(TwentyFive, Fifty, SeventyFive, Hundred).High3[0], "SL12", "BSL2");
}
}

On Sim101 the TP12/SL12 are submitting as they should, but on my Live account they are simply ignored. And this has been happening multiple times now on my Live account while everything functions properly on the Sim101 account. What is causing this discrepancy? I can send you my entire Ninjascript code through a private mail should that be necessary.

I am looking forward to your reply.

Edit: also, this happens only sometimes, on other occasions the script does function properly on a Live account. Perhaps this could be affected by me making changes to my script and compiling it while the old version is still running?

[NinjaTrader_Jesse]

Hello GLFX005,

When you say that they are ignored, are you getting specifically a warning they were ignored or do you mean your logic was ignored in some way?

For this situation you would likely need to first address what the ignore is, was it ignored for a reason (TraceOrders) or was it ignored because of some difference like the condition did not become true for some reason. Prints can help to further address what is happening or also looking at the output window with traceorders enabled.

If you were to add a print to test this you could add one print in each of the conditions to see if the print happens or not. Depending where the prints stop would let you know where the your conditions the logic stopped happening.

This could relate to the broker being used if you use Rithmic or Interactive Brokers. The order of OnOrderUpdate/OnExecutionUpdate which could affect this type of logic. There is a note about this in the help guide here: https://ninjatrader.com/support/help...ub=onexecution

I look forward to being of further assistance.

[GLFX005]

Hello Jesse,

I am using Ninjatrader Brokerage, Dorman Trading.
I assume that when a Ninjascript is functioning without issues in a Simulation environment it should function the same in a Live environment. The discrepancy is rather unsettling and warrants a thorough investigation as to why this is able to occur. Please allow me to send you my full script in private so that you may examine any potential errors or differences between Simulation and Live.

Edit: An additional question I have is... when does an order not become null? When it is submitted, or when it is filled?

[NinjaTrader_Jesse]

Hello GLFX005,

Our support is not able to debug your script for you but we can assist you in finding the problem in the code to continue.

The items I mentioned would still be the best way forward, first to identify what the ignore is. Was this ignored for a reason or was this ignored based on some logic not happening/other?

If you see some discrepancy you would need to first investigate how that is happening based on the logic used. Adding prints and then running it in the situation where you already see this happening would be the easiest way to troubleshoot the situation. The prints can highlight if there is some difference in how the condition you used evaluated. From the given information I can't see anything specific that looks like it would cause the ignore other than one of the condition were not true.

when does an order not become null?

When you set the order to your variable. The order which is passed in from the override should be not null however it is always good practice to check that objects are not null before using them.



I look forward to being of further assistance.

[GLFX005]

Hello Jesse,

I do believe that my issues could potentially stem from null being misused. I've made some changes to my logic and will provide you with a short example of the life of a single order in my script.

private Order AS1 = null;

protected override void OnBarUpdate()
{
if (AS1 == null
&& Position.MarketPosition == MarketPosition.Flat
&& Other Conditions
&& Some More Conditions)
{
AS1 = EnterShortStopMarket(0, true, Contracts, Indicator(10, 20, 30, 40).Low2[0], "AS1");
}
}

protected override void OnOrderUpdate()

if (order.Name == "AS1")
AS1 = order;

protected override void OnExecutionUpdate()
{
if (AS1 != null && AS1 == execution.Order)
{
if (execution.Order.OrderState == OrderState.Filled)
{
TP12 = ExitShortMIT(0, true, Position.Quantity, Close[1] - Reverse * TickSize, "TP12", "AS1");
AS1 = null;
}
}
}

I am looking forward to your reply.

[NinjaTrader_Jesse]

Hello GLFX005,

Yes this could point to a problem, generally you would want to avoid assigning the order from the order object and instead look for it in the OnOrderUpdate/OnExecutionUpdate override.

AS1 = EnterShortStopMarket(0, true, Contracts, Indicator(10, 20, 30, 40).Low2[0], "AS1");

would be

EnterShortStopMarket(0, true, Contracts, Indicator(10, 20, 30, 40).Low2[0], "AS1");

I would suggest trying that modification first because you also have the OnOrderUpdate code setting the order object so this should not be needed.

To make sure that null is the problem you could add some prints in here:

Print("step 1");
if (AS1 != null && AS1 == execution.Order)
{
   Print("step 2");
if (execution.Order.OrderState == OrderState.Filled)
{
   Print("step 3");
TP12 = ExitShortMIT(0, true, Position.Quantity, Close[1] - Reverse * TickSize, "TP12", "AS1");
AS1 = null;
}
}

This will tell you where the logic stopped or if it got to the order method. If it stopped somewhere we won't see step 3 printed or also step 2 if its the outer condition.

[GLFX005]

Hello Jesse,

Does Cancelling an order automatically reset the order to null, or should I do that myself on Execution update?
What I am experiencing is that an order, let's say AS1 from before, is submitted once, then when the order is cancelled I am using this code to reset it to null.

if (AS1 != null && AS1 == execution.Order)
{
Print("Step 1");
if (execution.Order.OrderState == OrderState.Filled)
{
Print("Step 2");
ExitShortMIT(0, true, Position.Quantity, Close[1] - Reverse * TickSize, "TP12", "AS1");
AS1 = null;
}

else if (execution.Order.OrderState == OrderState.Cancelled)
{
AS1 = null;
}
}

But it's not working anymore once it has been Cancelled once.

[NinjaTrader_Jesse]

Hello GLFX005,

No you would need to observe the order events, if you are expecting to cancel the order you would want to observe for the cancelled event and then reset your variables.

https://ninjatrader.com/support/helpGuides/nt8/managed_cancelorder.htm?zoom_highlightsub=cancel

I look forward to being of further assistance.

[GLFX005]

Hello Jesse,

So to be clear about what you're saying...

When checking for .Filled status, and attaching Stop/Target orders, I should use OnExecutionUpdate.
And to check for .Cancelled status, and nullify an order, I should use OnOrderUpdate.
Is that correct?

[NinjaTrader_Jesse]

Hello GLFX005,

That would be correct. OnExecution is used for order fills or executions where the other override is used for order states.

I look forward to being of further assistance.

[GLFX005]

Hello Jesse,

I have this line of code that should enter a trade with twice the amount of contracts of my current position size. But what it does instead is submit the trade with an equal amount of contract as what is in my position size.

ExitShortStopMarket(0, true, Position.Quantity * 2, KyoriBands2(TwentyFive, Fifty, SeventyFive, Hundred).Low1[0], "ASL1", "");

Any ideas on why the calculation is not working?

I'm looking forward to your reply.

[NinjaTrader_Jesse]

Hello GLFX005 ,

From the given example no, you could try using a Print with the calculation to see what number is generated as a starting point.

I look forward to being of further assistance.

[GLFX005]

Hello Jesse,

So I used Print statements to measure the Position.Quantity size and it does return the correct value. I enter the market with 2 contracts, and the following code down below does submit 2 contracts (including Position.Quantity being 2) but seems to ignore the part where it has to multiply the Position.Quantity by a factor of 2.

ExitShortStopMarket(0, true, (Position.Quantity * 2), KyoriBands2(TwentyFive, Fifty, SeventyFive, Hundred).Low1[0], "ASL1", "");

Edit: Does entries per direction imply the amount of contracts or the amount of uniquely named entries irrelevant of how big their contract sizes are?

[GLFX005]

Hello again,

The thing that seems to be occurring here is that the "ASL1" order is supposed to be submitting a total of 4 contracts, but does so in batches of 2 contracts twice, meaning that the order is no longer null after the first 2 contracts are submitted and therefor ignores the last 2 contracts that have to be submitted in order to reach a total of 4 contracts. I do not understand why the strategy is unable to submit 4 contracts at once?

I'm looking forward to your reply.

[NinjaTrader_Jesse]

Hello GLFX005,

The entries per direction would only apply toward the Entries and would be for separate entries not a single entry with multiple quantity. The exit should not apply to that.

It sounds like the entry logic is partly at fault here if the total quantity is not being hit. If you intend to submit two entries to reach a total position you will likely need to modify the overall logic to accommodate that before moving to working with stops. The order being not null sounds like its part of the normal logic you have for the orders life cycle in this script so if you now need a second entry to do the same type of logic you may need to duplicate those parts and use a second variable so the logic knows that extra position should exist.

From what I can gather the exit is trying to scale out is that correct? If so the suggestion for scaling out is to use two separate entries with different signal names. Then each target could apply toward that amount of the position.

I look forward to being of further assistance.