Tick charts and distribution tables hate each other

[Chris001]

I hope I can explain this well enough. My strategy is being developed on tick data, this poses a problem with strategy analyzer and the Distribution Table. It seems that the time is not the close of the bar that triggered that order but the time for the next bar where the order is placed. This poses a large problem as sometimes the gap in time between ticks can be quite large.

This can be deceptive, for example, lets say I have a signal to buy at 7:59:00 when that bar closes, and an order is placed, but strategy analyzer seems to not register the entry time until the completion of the next bar where the order is placed and lets say this is 9:00:00 or 10:00:00. This will make my analysis of the Distribution Graph not go over well as really this order was placed at 7:59:00 but on the graph it is being masked by actual orders at 9:00:00 or 10:00:00.

What I would like is for my buy signals to still be based off my tick chart, but all, order entries, exits, position reversals to be placed on a non visible one minute chart. What will need to be done?

Thanks

[NinjaTrader_Bertrand]

Hi Chris, yes I would expect that the trade execution / entry time would matter here and not the order placement time (your signal).

You can definitely send the signal from the tick series to a minute series for execution, here's a sample how this concept would work - http://www.ninjatrader.com/support/f...ead.php?t=6652

You will need to keep in mind though if there's no tick / trade happening > then the event based approach to bars creation would also be seen on minute bars meaning you don't have to get a bar even if the time would be due for it, a trade still has to happen as it would then close the prior bar and open the new one.

[Chris001]

Ok, I did that, and it sort of worked but some things are bizarre. As you can see entry times of trades occur more recently than exit times. This did not occur before changing the code. Also the code below used to work, I commented it out for the examples in the screen caps as the exit for my third contract per direction goes unrecognized. Here is the example for the long trade



{if (Position.Quantity == 1
&& Close[0] > Position.AvgPrice + 8 * TickSize
&& Position.MarketPosition == MarketPosition.Long
&& BarsSinceExit("Long B") < 2)
{SetStopLoss("Long C", CalculationMode.Price, Position.AvgPrice + 6 * TickSize, false);}

else if((Position.Quantity == 1
&& Close[0] < Position.AvgPrice + 8 * TickSize
&& Position.MarketPosition == MarketPosition.Long))
{SetStopLoss("Long C", CalculationMode.Price, Position.AvgPrice + 1 * TickSize, false);}

[Chris001]

I switched the second data series from one minute to one second and this seems to have corrected the problem. Still I do not understand why this is happening and find this a little concerning

[Chris001]

One more thing it did not correct the updated stop loss, it only corrected the trade entries occurring after the exits for whatever reason.

[NinjaTrader_Bertrand]

Hi Chris, I would expect that outcome unfortunately for your scenario, since you work with the Set() methods for your exits > those would always execute against the primary series. What you can do to workaround is reconstructing the exits in your script using the more advanced Exit() methods, they would offer a BarsInProgress parameter to submit again and thus would allow a finer handling in MultiSeries environments.

[Chris001]

Thanks,

If that is the case why does my initial stop loss and the first adjusted stop loss (stop loss B) get treated the same when there is a second data series? It is the second adjusted stop loss (C) that acts differently from when one data series is used.

[NinjaTrader_Bertrand]

There could be couple of reasons, which would need to be closer investigated then by debugging. Generally the Set()'s will only work their executions in regards to the primary series, however if you introduce additional series, the BarsInProgress will change as will the event timing when you actually act via your code (i.e. BarsInProgress == 1 is not an absolute but rather relative to what other series added).