Did multi-timeframe processing get broken in NT7.0.1000.9?

[koganam]

One of my multi-timeframe scripts suddenly started throwing an error, and lost its plot, after I updated to NT 7.0.1000.9, on my development NT box. The log showed an index-access error, so I decided to investigate by setting up a new chart with the exact same timeframe parameters on my compilation NT 7.0.1000.8 box (which I had not yet updated). Much to my surprise, the problem does seem version specific.

To illustrate the problem, I have included an indicator file, which loads a secondary SPY BarSeries. (The name of the file is a question, not a statement ).

Here is the replication scenario.

1. Chart: DIA, 5-minutes (or any intraday time-frame), 5 days of data (this is just what I used; it does not really matter how many days of data).
2. Open the "Output Window"
3. Load the indicator.
4. Clear the "Output Window", so that we can be sure we have a clean slate
5. Reload the chart (F5 reload).
6. Scroll to the top and examine the output window..

On a NT7.0.1000.9 box, you will see numerous exceptions in the output window, followed by correct output. This is not just a demo problem. It did break a shipping indicator of mine, as the shipping indicator does not use Try/Catch blocks. The only reason we finally start to get valid output is because the exceptions are caught and thrown; hardly a recipe for good product.

NT 7.0.1000.8 produces absolutely clean output, with no exceptions. I can post the 2 outputs if you wish to see them.

[NinjaTrader_Matthew]

Thanks for reporting Koganam,

I was not able to reproduce immediately. When testing on a R9 setup, I receive the following output:

CurrentBar: 0
BarsArray[0]: --  instrument='DIA' from='2012-02-15' to='2012-02-20' period=5 Min splitAdjusted=False dividendAdjusted=False bars=328
BarsArray[1]: --  instrument='SPY' from='2012-02-15' to='2012-02-20' period=5 Min splitAdjusted=False dividendAdjusted=False bars=541
Current Value of 1st BarsData: 128.57 at 2/15/2012 2:05:00 AM
Current Value of 2nd BarsData: 135.95 at 2/15/2012 2:05:00 AM

This is repeated on each currentbar with out any exceptions written to the output or the log file.

Can you please post the output from the two installations?

[koganam]

Originally Posted by NinjaTrader_Matthew

Thanks for reporting Koganam,

I was not able to reproduce immediately. When testing on a R9 setup, I receive the following output:

CurrentBar: 0
BarsArray[0]: --  instrument='DIA' from='2012-02-15' to='2012-02-20' period=5 Min splitAdjusted=False dividendAdjusted=False bars=328
BarsArray[1]: --  instrument='SPY' from='2012-02-15' to='2012-02-20' period=5 Min splitAdjusted=False dividendAdjusted=False bars=541
Current Value of 1st BarsData: 128.57 at 2/15/2012 2:05:00 AM
Current Value of 2nd BarsData: 135.95 at 2/15/2012 2:05:00 AM

This is repeated on each currentbar with out any exceptions written to the output or the log file.

Can you please post the output from the two installations?

Just to be sure, I rebooted the NT7-9 machine, my development machine, as I presume that most folks use a physical machine, so I thought that it would be best to be on physical hardware, just in case it makes a difference, no matter how small. The outputs are attached. The NT7-8 machine output is pretty much what you have, which is why I was taken aback when I got the errors on the NT7-9 machine.

I have no objection if you want to remote in to look at the machine. It is a bit heavy on applications installed, as it is a development machine, but I run this test with nothing else beyond the startup programs running.

[sledge]

Originally Posted by koganam

Just to be sure, I rebooted the NT7-9 machine, my development machine, as I presume that most folks use a physical machine, so I thought that it would be best to be on physical hardware, just in case it makes a difference, no matter how small. The outputs are attached. The NT7-8 machine output is pretty much what you have, which is why I was taken aback when I got the errors on the NT7-9 machine.

I have no objection if you want to remote in to look at the machine. It is a bit heavy on applications installed, as it is a development machine, but I run this test with nothing else beyond the startup programs running.

NT8, vista, 32 bit, TDA connection with excessive BACKFILL issue problems.

I got it until 9:35 am?

I changed to 10 days and just about the same thing happened in NT 7-8 (the error started earlier, then it cleared up , and was fine by the 5 day data load issues).

[NinjaTrader_Matthew]

Koganam,

I was able to reproduce this today on both R8 and R9. I was also able to resolve by adding a currentbars check:

 if(CurrentBars[0] < 1)
    return;

Please let me know if that does not resolve on your end.

[koganam]

Originally Posted by NinjaTrader_Matthew

Koganam,

I was able to reproduce this today on both R8 and R9. I was also able to resolve by adding a currentbars check:

 if(CurrentBars[0] < 1)
    return;

Please let me know if that does not resolve on your end.

While a bars escape does seem to clear up the situation, as the solution makes no logical sense, I am afraid that it is just masking what may be a deeper issue. As your initial test, (and sledge's test too) demonstrates, the issue does seem to show up in a somewhat inconsistent manner.

There was never an access to a past bar, so there should not ever have been an index error in the first place. The access was always to bar[0], so escaping the first bar seems to be rather a slapshot attempt to see what happens?

[NinjaTrader_Matthew]

Hello,

This can be generated if OnBarUpdate was attempted to run on an added series where there was no data to work from. Using a check of CurrentBars[0] < 0 would prevent this as well and is not necessarily related to accessing a past index value.

[koganam]

Originally Posted by NinjaTrader_Matthew

Hello,

This can be generated if OnBarUpdate was attempted to run on an added series where there was no data to work from. Using a check of CurrentBars[0] < 0 would prevent this as well and is not necessarily related to accessing a past index value.

Which I agree with, except that in this case the exception is being thrown on the primary bar series, BarsArray[0], not the added one.

CurrentBar: 0
BarsArray[0]: -- instrument='DIA' from='2012-02-15' to='2012-02-20' period=5 Min splitAdjusted=True dividendAdjusted=True bars=429
BarsArray[1]: -- instrument='SPY' from='2012-02-15' to='2012-02-20' period=5 Min splitAdjusted=True dividendAdjusted=True bars=715
2/14/2012 04:25:00 barsArray access error! on BarsArray0 System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.Collections.ArrayList.get_Item(Int32 index)
at NinjaTrader.Data.MemBars.GetClose(Int32 index)
at NinjaTrader.Data.Bars.GetClose(Int32 index)
at NinjaTrader.Indicator.DataSeriesHelper.get_Item(In t32 barsAgo)
at NinjaTrader.Indicator.BrokenMultiSeries.OnBarUpdat e()

[NinjaTrader_Matthew]

Right - it wouldn't matter which series was being called, the exception is just saying that that bar didn't exist when OnBarUpdate was running. When the first bar of BarsArray[0] was updating, there was no BarsArray[1]. Added a check for CurrentBars then returning will allow for the BarsArray to complete before the rest of the script is ran.