using ExitLongLimit in multiple timeframes for same symbol

[jdfagan]

I use ExitLongLimit for my profit stops within the OnExecution method to bracket my trades to the upside on entries being fulfilled. This works great but I'd like to now have a bit more fine grained control of how it executes in historical backtest.

My situation is that my primary timeframe is a non-time based one (like a volume or tick based chart). My secondary timeframe is the 1 min timeframe which I use as a heartbeat timeframe.

Sometimes multiple 1 min bars may come thru before the primary bar comes or vice versa due to nature of the primary bar. What I want to do is have my profit stop exit no matter which bar crosses the profit stop first. I searched the forum but didn't find any threads asking about submitting multiple ExitLongLimit orders in 2 different timeframe simultaneously (using same symbol). I was considering something like this where I invoke the same profit limit order but with the 2 timeframes:

profitStopOrderPrimary = ExitLongLimit(0, true, execution.Order.Filled, profitTargetPrice, "Profit Stop", "");
profitStopOrderSecondary = ExitLongLimit(1, true, execution.Order.Filled, profitTargetPrice, "Profit Stop", "");

If I do the above, will execution of one of these orders automatically cancel out the other to prevent double profit stop executions from occuring?

Are there any negatives with doing the above or any gotchas I should be wary about? Currently writing this on NT 6.5 but will moving this over to beta NT 7 within a month.

JD

[NinjaTrader_Austin]

If I do the above, will execution of one of these orders automatically cancel out the other to prevent double profit stop executions from occuring?

Are there any negatives with doing the above or any gotchas I should be wary about? Currently writing this on NT 6.5 but will moving this over to beta NT 7 within a month.

JD

Execution of one of those orders will do nothing for the other order. You will most likely end up with a double fill.

Another possibility is the second order will just be ignored because it is exactly the same as the first order.

You could always add a 1-tick time frame and submit orders to that time frame for the quickest fills.

If you'd like you can review the sample titled adding intrabar granularity to backtests.

[jdfagan]

You could always add a 1-tick time frame and submit orders to that time frame for the quickest fills.

If you'd like you can review the sample titled adding intrabar granularity to backtests.

Thanks for the reply Austin. Yes, I have used multi-timeframes before and did look at that code from Josh before my original post when searching about this subject but was unsure how my scenario would work.

Thanks for the 1-tick timeframe suggestion - that may be something to try but am concerned in two areas if I use that approach: memory and CPU consumption.

I believe CPU could be mitigated via the following approach:

Short-circuit the logic in OnBarUpdate for that timeframe so it doesn't consume too much CPU cycles for executing logic in a timeframe I basically don't care about (except for crossing my stop thresholds). I presume using ExitLongLimit(1, ...) from within the OnExecution method where 1 equals 1-tick timeframe will allow it to exit my profit target even if I short circuit this timeframe from doing much of anythin in OnBarUpdate. Is that accurate statement? Then I'd make the best use of my CPU resources while still achieving finest grain stop executions..

OnExecution {
    ...
    profitStopOrder = ExitLongLimit(oneTickTimeframe, true, execution.Order.Filled, profitTargetPrice, "Profit Stop", "");
    ...
}

OnBarUpdate() {
    if (BarsInProgress == oneTickTimeframe)
        return;

    //Proceed with normal logic for timeframes I care about
}

Memory is my bigger concern though. Adding in the 1-tick timeframe as requirement to my strategy may greatly impact the memory footprint of my charts with strategies loaded in them. I like to load in several months for my charts. And 1-tick timeframe may be too heavy for memory impact (at least with 6.5 - perhaps better in 7).

What are your thoughts on the above?

How about if I go back to my original plan of submitting 2 at same level but when one executes in one timeframe, I cancel the order to the other timeframe? Or do you think this could be a sync issue at times where they happen so close to one another that the code can't react fast enough to cancel the other timeframe order before it gets executed anyways - especially if the limit orders are sitting on the exchange with these limit methods?

JD

[NinjaTrader_JoshP]

The optimization for CPU efficiency will work.

Your concern about memory consumption is valid on a 1 tick series as that will use a lot of RAM. In 7 you will be able to run much longer series due to memory optimizations in 7 so you should be able to do more.

Whenever you have two working orders and you are expecting one to fill before the other there is always a sync risk. It is very possible to have one get filled by your brokerage and before your brokerage can report that to you to have the other get filled as well. By the time you get information back for the first fill it is too late to cancel the second order and you are stuck filled twice.