BarsArray[1].Count is 3 bars less than BarsArray[0].Count?

[NinjaTrader_ChrisL]

Hi T, thanks for your reply.

I will need you to post a test script, or send it into scriptingsupport at ninjatrader.com so I can run it on my machine. If you email it in, please reference "Attn ChrisL" in the body of the email.

Kind regards.

[NinjaTrader_ChrisL]

Hi,

I tested a script in the playback connection on HA Daily + secondary day series based on HA base period parameters and was not able to reproduce this. Can you reproduce on a shorter time frame like 1 minute so it does not take multiple days to test the issue?

Kind regards,
-ChrisL

[tgn55]

Maybe... but not sure it will exhibit the same behaviour.

My script (indicator) which is running constantly on over 20 charts, only throws this condition occasionally, When I reported it the other day, just one instance demonstrated the error... all the other charts had no issues. Go figure. And it is not always the same chart that bombs...

I have not been able to determine any pattern, tho I have suspicions around trading/session hours being a factor. Maybe that somehow messes with the dataseries counts.

Bottom line, there seems no guaranteed way of invoking the error. We could run it on 1 minutes bars... but, if the issue is triggered by something to do with bars created at the start of a new session, 1 minutes bars won't help speed up the diagnosis.

I tried a while back to use Playback to test... but had issues with getting daily historical data as I recall. I can try again... and run my indicator on it. That would be useful - if I can make it work!

[tgn55]

The bug (?) just bit again... this time on /CC.

Trading hours on CC means I got a new daily bar about 30 minutes ago, start of Monday's session at 4:45 AM EST, and bam... BarsArray[1].Count is now 1 less than BarsArray[0].Count... but had previously been in synch.

The discrepancy is picked up right near the top of OnBarUpdate (as shown previously)... before my indicator really does anything much at all. Difficult to see how my code can be inducing this condition.

I don't know how to predict on what chart this will happen next, or when... but this last occurrence only strengthens my view that it is related to trading hours/session starts etc.
Further, it is biting in real time... I don't know enough about how Ninja manages Playback data to know if that might be not QUITE identical in terms of data series bar creation timing.

I might add in timestamps on my log file records

Most if not all symbol's trading sessions have probably opened by now... might need to wait for another day (or week ?) for the conditions to trigger this. We'll see ;-)

T.

[hedgeplay]

I don't know how to predict on what chart this will happen next, or when... but this last occurrence only strengthens my view that it is related to trading hours/session starts etc.
Further, it is biting in real time... I don't know enough about how Ninja manages Playback data to know if that might be not QUITE identical in terms of data series bar creation timing.


T.

Hi TGN,

This is a quote from my earlier post in this thread.. post #13

While developing custom bar types for intraday use I noticed intermittent dis-synchronization in period bar counts would occur between bar types on the same underlying base type as a result of session iteration, and a few (related) other behaviors ...

Supporting what you wrote above .. as I have followed this thread have always felt the number 1 suspect root cause has to do with Session Iteration.

My recommended path forward is to stop and study exactly (demystify) how session iteration works on your bars.

Example: An as of yet un-validated hypothesis for at least intraday bars:

At least on some bar types session iteration on the second day and forward lands unfinished bars from the previous session spanning both sessions somewhat centering middle of the bar right at the session break.

Example: In "Tick" data series, the first 500 tick bar of the second day of the session might only really have 479 ticks and first 500 tick bar of the third day may only have 492 ticks.

After a while I de-perfected my custom bars to better match NT default Tick bars just to make development and validation processes easier.

HedgePlay

[tgn55]

Thanks hedgeplay ,
I never did test switching the data series around ... sorry for not replying to your previous post about it.

I did actually get two more instances after my last post...on LB and HE. Things with weird trading hours, that had not yet created the next daily bar at the time I wrote Post #34
I have not done much with session iterators... and am really unclear how your comments re intraday and tick charts applies in my case... which is plain old daily bars... albeit with the "oddball" Heiken-Ashi secondary series.

It seems that sometimes at least, OBU is called on the primary, BarsInProgress == 0 series BEFORE the bar is created in the secondary series. Probably only Ninja 2nd level support could give a definitive answer to that theory.. And the instances I have seen where the difference in bar counts was 2 or even 3... maybe happens if you just leave the chart untouched for an extended period ??? so the effect accumulates? Pure guesswork ... I don't have any evidence I can present.

I also have no clue why this only happens on some charts... on my trading system I have over 20 charts running this exact same indicator... so why do I get errors only on a few?? Something indeterminate is at work...it smacks of possibly different threads operating on the different data series... and if that is how it works, then I see a nasty synchronisation issue... which probably requires Ninja Core action to resolve... but, I'm getting a bit too far ahead ;-)

T.

[hedgeplay]

Thanks hedgeplay ,

It seems that sometimes at least, OBU is called on the primary, BarsInProgress == 0 series BEFORE the bar is created in the secondary series. Probably only Ninja 2nd level support could give a definitive answer to that theory..

Hi T,

Your on the right track

According to the documentation and scores of posts in this forum that happens not just sometimes, but every time when multiple BarsArrays exist for the same instrument.
Here the link to the doc. https://ninjatrader.com/support/help...ick_replay.htm

BarArray[0] get serviced first, then BarsArray[1] then ...

I have not done much with session iterators... and am really unclear how your comments re intraday and tick charts applies in my case ...

The point was Session Iterators are tricky and though I expect are meeting design goals set or the development team sometimes behave in ways we might not expect. My intraday example was a just a demonstration of that.

The Session Iterator is everything in terms of what constitutes a day in non-custom bar types. The head waters of the river. Without the Session Iterators work you would zero days, there would no days, hours, minutes or seconds bars, just be one long string of ticks with timestamps but time based structure.

I also have no clue why this only happens on some charts... on my trading system I have over 20 charts running this exact same indicator. ...

So far in working with NT8 I have found there always has been a discernable reason. So what is different about those charts?

All have the same number of days?, time periods configured in the Indi?, same bar types?, same ChartStyle? same trading schedules?, generally all have a good amount of available data?, etc?


.... on a different path of possible root cause

I have seen NT8 struggle to load all data series in a workspace when many different instruments exist in the same workspace.

In extreme cases can be a limitation of the data provider, a limit to how many different symbols you can pull at the same time.

One possible test:

- When one or more charts fail save the WorkSpace under a new name.
- Delete 2/3 of the charts in the workspace and see if the issue has resolved?
- Right click, reload all historical data and see if the issue has resolved?
- Exit and reboot NT8 and see if the issue has resolved? When clean reboots clear issue up then total loading on NT8 might have hit a limit...

HedgePlay

[tgn55]

Thanks hedgeplay
My charts all have mostly identical setup...

Calculate.OnBarClose
Heiken Ashi 1 Day bars.
Custom date range from 1/1/2019 to the present.
Trading Hours: Use instrument settings
No Break at EOD.
Same indicator loaded on all charts... refreshed numerous times recently., eg after I added in logging to a text file.
Some charts have other indicators loaded, eg ADX &/or RSI... this is I think the ONLY variation between my 20 or so charts
My indicator creates NO plots.
Workspace saved frequently.
NT exited/restarted. Also, PC rebooted... all within the last couple of days, just prior to the most recent failures.
Further, I do heaps in VS... which would report if there was any exceptions thrown... there are none, up until this bug bites... and only then do I get an Object ref error, due to the missing bar in BarsArray[1].

But I think this...

According to the documentation and scores of posts in this forum that happens not just sometimes, but every time when multiple BarsArrays exist for the same instrument.

is wrong. My indicator checks if BarsARray[0].Count == BarsArray[1].Count on EVERY single bar, of every chart. And the evidence is there... most of the time, they are in agreement. Occasionally, they are different after a new bar is added... and I log when that happens.

I think the more relevant documentation is on this page... https://ninjatrader.com/support/help...nstruments.htm

I'd be happy to be shown where I am wrong, but I don't believe any of the cautions re multi-series bars, events etc apply in my case. My two dataseries are for the SAME instrument, so by definition, have the same trading hours template, for example. The only difference should be the OHLC values in BarsArray[1] are the real OHLC, rather than the artificially constructed Heiken Ashi values. And my code gets those values when I want them... but, honestly... this kinda misses the point. Way before I do that, the die is cast, the bar counts are different... The exception is thrown when I execute this statement further down in my OBU code:

trade_price = BarsArray[1].GetOpen(BA1_Open_Bar)

and there is NO object for that bar. You can see my OBU code (well, the first few lines) in one of my previous posts... the check and log is right near the beginning, before any of the calls to GetOpen occur.

This bullet point from the above help page seems to hit somewhere near the mark:

An indicator / strategy with multiple DataSeries of the same instrument will only process realtime OnBarUpdate() calls when a tick occurs in session of the trading hour templates of all added series. Any ticks not processed will be queued and processed as a tick comes in for all subsequent DataSeries.

but, like I said... my two dataseries are for the instrument, with identical periodtype, period etc. All a result of the simple call to AddDataSeries.

Well, that's my 2 cents... Maybe you can clarify the comment re things happening "...every time...", and any relevant posts, as that is simply not what I am seeing.

Cheers,
T.

[hedgeplay]

The exception is thrown when I execute this statement further down in my OBU code:

trade_price = BarsArray[1].GetOpen(BA1_Open_Bar)

and there is NO object for that bar. You can see my OBU code (well, the first few lines) in one of my previous posts...

protected override void OnBarUpdate() { if (BarsInProgress == 1) return;

if (CurrentBars[0] < BarsRequiredToPlot) return;

Hi T

1) "and there is NO object for that bar"

I have not studied all the posting in the previous three pages in depth, so maybe this was covered.


https://ninjatrader.com/support/help...urrentbars.htm
"Note: In multi series processing, the CurrentBars starting value will be -1 until all series have processed the first bar."


Based on this comment. "and there is NO object for that bar"

I would have expected the top of your OBU() to also include if (CurrentBars[0] < 0) return;

So rather than "if (CurrentBars[0] < BarsRequiredToPlot) return;"

this "if ( CurrentBars[0] < 0 || CurrentBars[0] < BarsRequiredToPlot ) return;"

If more startup control is needed you can always in OBU() add counters per bar by State or other logic by State until all is stabilized and then flip to less complex code with a "Initialization is complete" DoOnce type bool switch.

If all the disconnects occur after initialization then:

- The above may not help at all.
- If is an NT8 bug will surface with other bar series as well. f other default and other custom bar series go out of sync when yours do then " its not you" Lol.
- If other default and other custom bar series do not become out of sync when yours do then focus turns to a logic issue within your code or just a better understanding what constitutes a day for Session Iterator and why and when Session Iterator declares the start of a new day.

I would start with a deep dive study into exactly what Session Iterator did with each relevant bar series three days before and after the sync disconnect started (seven days) to be able to delta Session Iterator behavior when they stayed in sync vs when they did not.

I would also be looking for changes in timing or the data at times of loss of sync. E.g. Contract transition dates, startup after Weekend, holidays, possibly day endings and starts are occurring within different time zones, etc.

If I was looking and I could not find delta or any cause on how my custom bar code is impacted by the above then I would be circling back to look at rest of my own logic again. If it is really hard to find then as you mention adding stronger logging is a good path.

2) This comment is one of the reasons I keep circling back to recommend focusing on really studying exactly how and when Session Iterator is deciding when you get new daily bars in each of default and custom bar series you are working with.

" but had previously been in synch." >> Somewhat like the Session Iterator driven example I posted above where in sync and then came of out sync.

Trading hours on CC means I got a new daily bar about 30 minutes ago, start of Monday's session at 4:45 AM EST, and bam... BarsArray[1].Count is now 1 less than BarsArray[0].Count... but had previously been in synch.

HedgePlay

[hedgeplay]

is wrong. My indicator checks if BarsARray[0].Count == BarsArray[1].Count on EVERY single bar, of every chart. And the evidence is there... most of the time, they are in agreement. Occasionally, they are different after a new bar is added... and I log when that happens.

Ok. Good.

On the chance that what I posted in the quote below is also true .. then value of this quote is to give focus to the idea that if logic your in your code does not expect that on the same instrument BarsArray[0] will always finish it's OBU() event processing cycle before subsequent BarsArrays' OBU() cycles then this area might be a source of any unexpected behaviors your seeing.

HedgePlay

Thanks hedgeplay ,

It seems that sometimes at least, OBU is called on the primary, BarsInProgress == 0 series BEFORE the bar is created in the secondary series. Probably only Ninja 2nd level support could give a definitive answer to that theory..

Hi T,

Your on the right track

According to the documentation and scores of posts in this forum that happens not just sometimes, but every time when multiple BarsArrays exist for the same instrument.
Here the link to the doc. https://ninjatrader.com/support/help...ick_replay.htm

BarArray[0] get serviced first, then BarsArray[1] then ...

[tgn55]

hedgeplay you are going down a wrong rabbit hole.

This has nothing to do with initialization. I check in State.DataLoaded, and see the same bar counts in both series. the chart is displayed with like 600 or so bars, my indicator does everything it should. I leave it running 24x6... the problem bites in realtime when a new bar is created at the start of a new session... but only on some charts, it is not consistent which chart.

So when it occurs, all the stuff about CurrentBar starting value, and being > BarsRequiredtoPlot is very much in the past... like 650 bars/days in the past! What matters is what happens on creating a new bar on a live chart.

Maybe you should look at the code snippets I posted already... plus the log extract in Post#30... it shows the bug occurring on bar 670

Cheers,
T.

[hedgeplay]

Hi T,


"This has nothing to do with initialization. ... "

What I read in the thread had not ruled out initialization being a contributor.

That theme was only one of three or four above. Hopefully you will find something helpful in the collection.


A read again of post #30 points to the the timing, logic or Session Iterator issues I mention above or sometimes similar topics David wrote in posts 9 - 11.

Had to wait a bit... I restarted Ninja on Sunday 5th September, all my charts with my indicator created text log files with the initial (ie State.DataLoaded) line... and on 7th Sept at 9:30 AM local time (which is when a new bar is created)... I caught this in my ZC text file.

This quote from post #30 points again at Session Iteration as a one key suspect area. What I wrote above about studying seven days of Session Iteration behaviors on both sides of the disconnect and how vs your bars the Session Iterator is handling normal days vs weekends, holidays, contract changes etc. Or the same logic or timing mentioned in the thread.



Good Luck!

HedgePlay

[tgn55]

OK, I've been pulled away to other matters for the last 2 weeks, but on the upside, have gathered more data since my last post.

There have been several instances of this critter biting again, and a pattern is emerging. It happens on Mondays, at the start of a new trading week.

I have seen it bite on the following charts: /ZC, /SB, /KC, /CC, /HE, /LB. And NOT on my other 14 or so charts. So... what do these have in common? Well... most have trading hours different to the majors like ES, GC etc... but, /HE runs on the CME Commodities ETH schedule... and still triggered the condition. Go figure.

hedgeplay ... be assured I have read and reread the previous posts, plus the posts you have linked to. I agree that the phenomena seems likely related to session iterators, trading commencement etc... that much is now very clear, before it was more a suspicion, but now confirmed.

What remains a mystery:

• Why it impacts some charts and not others... but I still suspect trading hour start time, possibly also my local timezone (GMT+930)
• Why would the session iterator do something different on the secondary series, given it is the SAME symbol. I mean, if the session iterator gets the primary series, eg /CC Daily Heiken Ashi "right", by which I mean it starts a new bar at the correct time... why would it fail to start a new bar on /CC Daily vanilla candlestick?

It is also clear that it is not related to contract rollover or holidays as you hinted might be possible causes... it is day of week, but only on some charts. I still think my second bullet above is relevant. I might just hack up some logging that dumps actualsession times etc for both Bar series... but might need to wait until next Monday for anything interesting to happen.

If you have any suggestions as to what you had in mind with your ref to studying 7 days of session iteration behaviour... let me know.

Thanks,
T.

[tgn55]

Shoot... well, scrap that theory. Just had another instance... on /SB , new bar created at 5:00 PM local time... on Wednesday... which is about 3:30 AM Wednesday US time... definitely NOT Monday.

Back to the drawing board...