NT checking my stop order price against the wrong timeframe Bar

[adamus]

Austin, did you actually see the errors?

[NinjaTrader_Austin]

adamus, yes, I did see the errors. I will be out of the office until next Monday though, but I will have a coworker try to help you out.

[adamus]

OK, how about looking at this from another perspective and perhaps you can tell me whether i should be seeing this or not.

Set up any old quick strategy and add the 1min timeframe of the same instrument in your initialization.

Set TraceOrders to true.

Set a print statement in the OnOrderUpdate and OnExecution to show what BarsInProgress is.

Place an order from the onBarUpdate using the method to stipulate that it is on the 1 min time frame.

Check the Output window.

The TraceOrders says it is handling the order on the 1 min BarInProgress, but the OnOrderUpdate and OnExecution say that it is the slower time frame BarInProgress.

Let me know what you think.
[

[adamus]

When you do the Print() statements, include the time in the print-out as well and you'll see time of the wrong bars is output by print statements in the OrderUpdate and Execution events.

[NinjaTrader_Bertrand]

adamus, I'll setup your test scenario provided here in a strategy and check, however please keep in mind the trades would be executed on the next bar in backtesting, as this is the first possible trade location after your entry was triggered.

[adamus]

Go for it. You'll see what I mean. I can't imagine how this would be an artifact of the trade placement as you say.

I see the bars tick by in logging on the minute scale,

05:01
05:02
05:03
05:04
05:05
05:06

then the order I placed with the 1min timeframe BarsInProgress index gets executed on the correct bar on the correct timeframe but it's logged with the BarsInProgress index from the primary timeframe like this:

05:01
05:02
05:03
05:04
05:05
05:06
05:00 OnExecution ....
05:07
05:08
05:09

Of course my issue is not the logging output. My issue is that the order price is checked against the wrong timeframe too and so it causes an **NT** error which is seriously hampering some of my strategies, even with the work-around.

Notice that the time of the execution bar is previous to the 1 min bars, not post-.

I haven't tested this in real time trading yet since I'm only running strategies with the work-around, but from the logging I suspect the issue is the same.

[NinjaTrader_Bertrand]

adamus, I checked into here - it would return a BIP, but it could be either one as it's irrelevant in those methods, as they do not run off a bars object as the OnBarUpdate().

[adamus]

And the time? Why is the time wrong? Maybe you can get your simulation to show the time as well and you'll see that's wrong too.

[NinjaTrader_JoshP]

Printing Time[0] is also irrelevant from OnExecution() method as it is linked to bars. The only relevant timestamp would be the execution's timestamp accessible through execution.Time.

[adamus]

Basically what you have then is something providing the wrong time. Should I have to come to your support forum to find this out? I don't think so. If somebody wants robust, reliable software that he/she can stake their money on, they won't want to see that kind of stuff. It raises questions about what is going on on the other side of that event code.

Anyway, I'll change the printed time to show the time stamp on the execution and I'll get back to you.

[NinjaTrader_JoshP]

It is not the "wrong" time. It is just the time of whatever the pointer was pointing to at the moment in time the OnExecution() event triggered. Whether that is BIP0 or BIP1 depends on whichever bar update happened last. Since the OnExecution() event is not a bars tied event and as such going Time[] is just not useful in this context. Time[] is a bars tied concept and using it in a non-bars tied context would simply yield the results you saw.

[adamus]

I don't suppose there's much point discussing what's right or wrong here since I have zero influence over it. However in my logging it is a secondary concern to log the correct time especially during real time trading. I can live with out-of-sync time stamps in the backtesting logs but it would be frustrating to have to deal with them live.

The primary concern though is still that I can't test against the close of the actual 1 min timeframe bar that I am using to submit the orders.

[NinjaTrader_JoshP]

You cannot backtest trade on the close of a signal bar because the bar has already closed. There is no more tradeable locations on that bar. A closed bar is terminal and is impossible to trade on. Next tradeable location is the open of the next bar and that is where you will see the trade show up. Unfortunately allowing the trade to go on a historical point in time in a backtest is "cheating".

[adamus]

When I submit a stop order I have to check that I am not submitting it on the wrong side of the market so I check the stop price against the close of the bar [0].

I don't' know how you would cheat in the way you describe. I submit orders relating to the bar at [0] which has just completed. I am used to the paradigm but I don't know how to cheat. Perhaps you should explain it further and give a line of code to show how it's done, and if I'm doing the same, then I'll realise.

Thanks

[NinjaTrader_Bertrand]

adamus, you could check on FirstTickOfBar (the 1min) before submitting while running the strategy with CalculateOnBarClose = false.