Help Please!! Exit Order Reversed My Position

[maltin]

Hi NT Developers!

In a nutshell, I'm looking to understand how why this behavior happens only occasionally, and how I can safeguard myself from it happening in the future.


Over the last few months I've been building on my strategy based around the managed trade approach.. It is stable enough to use with my live account and has been working well through June. Today, when it hit take profit it exited the long position and then proceeded to sell an addition 5 MES contracts thus reversing my position. Because the strategy is still new, and I'm an new to coding, I'm babysitting it while it takes trades to make sure it is doing the right thing. Most of the time it does, but today it didn't and I can't understand why it behaved differently. More details below...

Here is a screen shot of the executions:


Under the name column you see the order signal "PrimeMicroProfitLong" for the next to last order which is listed as an entry. The last order was where I had to "Flatten Everything" in order to fully exit the position.

Here is where this signal is executed in the code (I put an ascii arrow to indicate the line in the code, that arrow is NOT present is the script itself):

if(direction == "LONG")
                {
                    // Stop
                    ExitLongStopMarket(MiniQuantityInt, PrimeStp1Price, "PrimeMiniStopLong", "PrimeEntryLong" );
                    ExitLongStopMarket(HMMiniQtyInt, PrimeStp1Price, "HMMiniStopLong", "HMEntryLong" );
                    ExitLongStopMarket(MicroQuantityInt, PrimeStp1Price, "PrimeMicroStopLong", "PrimeMicroEntryLong" );
                    ExitLongStopMarket(HMMicroQtyInt, PrimeStp1Price, "HMMicroStopLong", "HMMicroEntryLong" );



                    // Profit
                    ExitLongLimit(MiniQuantityInt, PrimeTargetPrice, "PrimeProfitLong", "PrimeEntryLong" );
                    ExitLongLimit(HMMiniQtyInt, PrimeTargetPrice, "HMProfitLong", "HMEntryLong" );

        --->>>      ExitLongLimit(MicroQuantityInt, PrimeTargetPrice, "PrimeMicroProfitLong", "PrimeMicroEntryLong" );

                    ExitLongLimit(HMMicroQtyInt, PrimeTargetPrice, "HMMicroProfitLong", "HMMicroEntryLong" );


                }​

"MicroQuantityInt" is a calculated integer that was also used when placing the entry order and isn't changed or updated between when the order is entered and exited. So, I don't believe NT doubled the size of the exit inventory.

Plus, the development guide suggests it managed orders would ignore orders that would reverse direction.


"Methods that generate orders to exit a position will be ignored if:

•A position is open and an order submitted by an enter method (EnterLongLimit() for example) is active and the order is used to open a position in the opposite direction"

As a result, I'm left scratching my head as to why chose to do this today. And if it was just a random glitch, I would love to learn a way to return it to flat automatically if this should happen again.

Thanks for reading all the way through!

[NinjaTrader_ChrisL]

Hello, thanks for writing in. The best way you can debug something like this is to add prints throughout your strategy, especially around the order that is submitting "PrimeMicroEntryLong" since this order is causing the entry orders. You can also see if you are getting partial fills for the multiple orders. This means that it takes more time than normal to fully fill a position. We have a full example here that is capable of accurate order entry with OCO pairs that also handles partial fills:

https://ninjatrader.com/support/help...and_onexec.htm

[maltin]

Thanks for the response. Unfortunately, printing statements don't help me here. Believe me, I've used them to troubleshoot 100s of bugs over the last couple of months.

The reason they can't help me is because I can't reproduce this issue. I just tried the strategy using playback of today market replay and it closed out the trade perfectly. So, any price will show up exactly as I would expect.

My concern is that there is it seems to be random. This strategy performed perfectly on live data all of June, except for today. And even replaying today back doesn't yield the odd behavior.

I'm interested in learning more about how to deal with partial fills, but the link you gave is broken (i think it refers to a page on the old site). If you can provide a modern link or just tell me the page heading if it is in the developer guide, I would be happy to refer to it.

[NinjaTrader_ChrisL]

Hello, thanks for the follow-up. In order for us to explore this as an issue on NinjaTrader, it needs to be consistently reproducible. What I would recommend is using the example that I provided above to see if you can reproduce it using this technique of order management. If you would like to continue testing the strategy that you wrote, adding prints would be the way you would see what is happening when the strategy does take this position unexpectedly. This means you would need to watch for this to happen since it does not happen consistently.

[GerryU]

I have also experienced this behavior... as a result blowing several prop evaluations accounts!

[NinjaTrader_ChelseaB]

Hello GerryU,

Welcome to the NinjaTrader Forums!

To assist we need to see output from TraceOrders and Prints.

Below is a link to a forum post on using prints and TraceOrders to understand behavior.

https://ninjatrader.com/support/forum/forum/ninjatrader-7/strategy-development-aa/99209-date-conditions-not-working?p=791121#post791121

Start by enabling TraceOrders in State.Configure, and print the order object in OnOrderUpdate(). This will let us know what orders have been submitted and what orders have filled.
Print(order.ToString());

Open the NinjaScript Output window and reproduce the behavor.

Save the output window (right-click Save As) to a text file and include this with your reply.

[maltin]

Thanks ChelseaB. I was able to resolve this issue.

[GerryU]

Hi Maltin,

Can you share your findings and fix?

Kind regards,
Gerry.

[maltin]

Hi GerryU,

I'm sorry to hear you are having the same issue. I believe my problem was over-complicated and sloppy coding. I don't recall specifically - I've had so many bugs to track down and fix.. I ended up rewriting the order execution two or three additional times after this post (I'm on version 4 now and it appears to be stable and worked as expected). My best advise is to simplify where possible.

At one point, I was working in the OnOrderExecution area, and it was have issues closing out partial orders. In the end, I found that using the SetProfit and SetStopLoss within OnBarUpdate (my profit and loss are set after a specific bar closes during the day, not when the straties is enabled). And make sure to null out any entry orders that have been canceled in OnOrderUpdate in order to make sure there wasn't anything residually floating around in the system after I expected an order to be canceled.

Such as:

if (order.Name == "MiniEntryLong" || order.Name == "MiniEntryShort" )
                {
                   myEntryOrder = order;

                    if (order.OrderState == OrderState.Cancelled && order.Filled == 0)
                    {
                        myEntryOrder = null;

                    }

                }​