IsFirstTickOfBar and bars that have no ticks...

[pjsmith]

Hi,

This might seem like an odd question, but here goes. I use IsFirstTickOfBar, basically, to detect the formation of a new bar and reset various variables to zero for that bar, etc., I think this is a pretty common practice and as far as I can see and most other codes I've seen, seem to do the same. For a while though, I've noticed, on some products that can get very thin in volatility, on things like range/renko/unirenko bars, you can get bars which essentially have no trades, where liquidity was thin and a new bar formed because price gapped. Ninzarenko is one particular one I find an issue with. It seems that IsFirstTickOfBar does not get set in one of these gap bars, so your code has no idea a new bar has formed. This causes issues with averages etc. Weird thing is, IsFirstTickOfBar DOES fire historically, just not in realtime.

Simple test - I put a draw.diamond call in 'OnFirstTickOfBar'. See image below



no diamond - But, after f5 to reload the chart



It's there. So, this issue only happens in realtime it seems. I'm not 100% sure if this is a problem with the Ninza NinzaRenko bars, or a flaw with my assumption that I should use IsFirstTickOfBar to detect a new bar. The latter does seem like a broken assumption to me, given no ticks (trades) actually occurred in the bar, but on the other hand, it works historically and everyone else seems to do the same, including ninja supplied code.

So, I guess, what is the best way to detect the formation of a new bar. I know most code I see tends to use IsFirstTickOfBar, but it seems in this case, is not a reliable method. What would you suggest? Monitor 'CurrentBar' for changes perhaps? CurrentBar would increment, even with no ticks? If you think this is an issue with the bar type, perhaps you could report it to your vendor ( I think they may be active on this forum and are an active partner with you ).

[edit : as an afterthought, given I experienced this issue, I am wondering, does an indicator get called, even if set to 'OnEachTick', if there are bars with no trades, and no ticks? Because this could result in plot[0] not having any value for that bar?]

Thanks.

[NinjaTrader_Jim]

Hello pjsmith,

Thanks for your post.

Bars like Renko and Range can split into multiple bar formations. We can still expect these multiple bar formations to be processed in our indicator/strategy's OnBarUpdate method.

We can use a script like what is attached to monitor CurrentBar and the timestamps of the bar to ensure continuity and that there are prints for every bar. This would show that IsFirstTickOfBar is becoming true for each bar formation.

Note that when a reversal occurs on a Renko Bar RemoveLastBar is called and the last bar is removed and replaced. We can expect to see output like the following then. (Notice how previous CurrentBar indexes appear when there is a reversal. We see this because the Renko BarsType is calling RemoveLastBar and creates a new bar when there is a reversal.

CurrentBar: 162255 Time[0]: 11/04/2020 07:43:21.521 AM
CurrentBar: 162256 Time[0]: 11/04/2020 07:43:21.562 AM
CurrentBar: 162255 Time[0]: 11/04/2020 07:43:21.521 AM
CurrentBar: 162256 Time[0]: 11/04/2020 07:43:23.084 AM
CurrentBar: 162257 Time[0]: 11/04/2020 07:43:23.118 AM
CurrentBar: 162256 Time[0]: 11/04/2020 07:43:23.084 AM
CurrentBar: 162257 Time[0]: 11/04/2020 07:43:23.205 AM

I cannot comment on the functionality of ninZaRenko bars, but if you have questions involving this test script and NinjaTrader standard Range and Renko bars, I will be happy to answer.

We look forward to assisting.

[pjsmith]

Ah, bars being removed! That's one scenario I had not thought about. CurrentBar going backwards! Hmmm. I will have to have a think about how to deal with that. Thanks for the info. Certainly, I think you pointed me in the right direction. I don't suppose off the top of your head you can recall any of the indicators that might deal with bars being removed in this manner, that I might take a peek at their code and see how they are dealing with it?

Thanks again.

[NinjaTrader_Jim]

Hello pjsmith,

The indicator will have OnBarUpdate called again for the bar that is being replaced and then again for the new bar that forms after it. A plot value will be removed and then recalculated when OnBarUpdate is calculated on the replaced bar.

SMA has some code that checks if (BarsArray[0].BarsType.IsRemoveLastBarSupported) to ensure code gets processed using bar indexes and to avoid using private variables that reflect previous bar values. (The else block of an SMA is optimized code that will not work with RemoveLastBar because priorSum is calculated to be used on the next bar and is not tied to a bar slot like a Series or Plot.)

We look forward to assisting.

[pjsmith]

Thank you. I think I have confirmed this is my issue. A summary, in case it helps anyone else.

I stored the CurrentBar value in CurrentBar last, so I could check it and ran my code until I noticed the anomaly in my averaging. I checked my output log and sure enough, a single message "*CurrentBar went backwards (bar was likely removed)" right at the time the plot went bad. I had already ported some code from the SMA example to my code, so I added a debug check in state 'Configure' that simply does this Print("BarsArray[0].BarsType.IsRemoveLastBarSupported="+BarsArray[0].BarsType.IsRemoveLastBarSupported.ToString());

But I get BarsArray[0].BarsType.IsRemoveLastBarSupported=False, which would seem to indicate that the Primary bar series does not in fact support removing the last bar. My currentbarlast was less than currentBar though, so it surely has.

The bar types I tested were not stock ninja ones. Of the ones I had the source for, compared to stock code, there is no override for IsRemoveLastBarSupported in the barTypes code. I added 'public override bool IsRemoveLastBarSupported { get { return true; } }' to the barsTyep code and verified that is does now report as supported. Hopfully, I now have cracked the problem.

[eDanny]

Also notice that there IS a diamond on the reversal bar but it is behind the bar but covered because the bar closed up. When refreshed it is redrawn above the bar.