Get Added Series Information During Configure State

[BarzTrading]

When I look at the BarsArray in the configure state, the element(s) are null. I understand that technically, the data isn't available until the DataLoaded state, but it seems like before today the primary series would already be loaded in the configure state. But maybe that was only for indicators and not strategies... I'm not sure.

At any rate, I'm trying to load a data series programmatically based on the primary instrument in my strategy. For example, if the primary series is "ES ##-## 15 min", I want to load "ES ##-## 1 Day".

But in order to do this programmatically, I need to know the instrument and BarsPeriod during the configure state so I can call AddDataSeries there.

Is there a way to get a list of all the data series that have already been added in the Configure state, or at a minimum the Instrument and BarsPeriod of the primary series?

Thanks for the help.

[NinjaTrader_ChelseaB]

Hello BarzTrading,

The behavior for indicators and strategies is the same when it comes to loading data.

If you are trying to supply any information from the primary series when adding a secondary series, this is specifically and explicitly not allowed.

From the help guide:
"Arguments supplied to AddDataSeries() should be hardcoded and NOT dependent on run-time variables which cannot be reliably obtained during State.Configure (e.g., Instrument, Bars, or user input). Attempting to add a data series dynamically is NOT guaranteed and therefore should be avoided. Trying to load bars dynamically may result in an error similar to: Unable to load bars series. Your NinjaScript may be trying to use an additional data series dynamically in an unsupported manner."

https://ninjatrader.com/support/helpGuides/nt8/en-us/adddataseries.htm

https://ninjatrader.com/support/helpGuides/nt8/en-us/index.html?multi-time_frame__instruments.htm#AddingAdditionalBarsObjectToninjascript

You would need to use the overload with the instrument.
AddDataSeries(BarsPeriodType periodType, int period)


If you want to dynamically add data based on what the primary series is, you would have to use a BarsRequest and pull the data in un-synchronized.

https://ninjatrader.com/support/helpGuides/nt8/en-us/barsrequest.htm

[BarzTrading]

Thanks, Chelsea, for that clarification. I'll have to study those links more carefully and rethink things a bit.

[BarzTrading]

So, I've implemented a simple test indicator that uses BarsRequest (see attachment). This is working pretty well overall, but I have a couple of questions:

1) The MergePolicy parameter to BarsRequest.Request seems to work fine _except_ that MergeBackAdjusted always returns the unadjusted series. The only way I'm able to get backadjusted bars is to use the "##-##" syntax, which, incidentally, does work. My indicator is in the attached zip file. Open any symbol, say "ES ##-##" on the chart, then run the indicator. You can observe that the prices are the same regardless of whether the MergePolicy for BarsRequest is MergeBackAdjusted or MergeNonBackAdjusted.

I'm using Kinetick data.

2) In my implementation of BarsRequest, patterned after the help documentation here (https://ninjatrader.com/support/help...ub=barsrequest), the bar request seems to be asynchronous. So I've had to add a flag and wait on the callback to complete. I've not seen anything like this in your examples. If you don't wait on the flag, you'll see that the requested Bars are empty. My code seems to work just fine, but given that the examples don't do this, I'm wondering if I'm doing something wrong.

          
bool completed = false;
_Request1.Request(new Action<BarsRequest, ErrorCode, string>((br, errCode, errMessage) =>
{
   if (errCode != ErrorCode.NoError)
   {
      NinjaTrader.Code.Output.Process(String.Format("Error on requesting bars: {0}, {1}", errCode, errMessage), PrintTo.OutputTab1);
   }
   else
   {
      string name = br.Bars.Instrument.FullName;
      NinjaTrader.Code.Output.Process(String.Format("BarRequest1: {0}, {1}, {2}", name, br.Bars.BarsPeriod.ToString(), br.Bars.Count), PrintTo.OutputTab1);
   }
   completed = true;
}));

while (!completed) { System.Threading.Thread.Sleep(20); }

Bars bars = _Request1.Bars;
Print(String.Format("BarRequest1 Post: {0}", (bars != null ? bars.Count.ToString() : "NULL")));
Print("BR END: " + GetBarsRequestText(_Request1));

Thanks,

[NinjaTrader_ChelseaB]

Hello BarzTrading,

I will test the merge policy and let you know what I find.


Which example of mine are you referring to?

Are you referring to the addon example I posted to the forums linked below?

https://ninjatrader.com/support/forum/showthread.php?p=503872#post503872

[BarzTrading]

Regarding examples of BarsRequest, I'm mainly referring to examples like in the help docs (https://ninjatrader.com/support/helpGuides/nt8/en-us/). These examples are all for use in AddOns so given the interaction with the UI, maybe a wait in code isn't strictly necessary.

In the indicator I just found that I needed to wait on the request because otherwise the Bars might not be available when needed.

It works great, but would you say this a reasonable approach? Do you have a different recommended way of managing BarsRequests in an Indicator?

[NinjaTrader_ChelseaB]

Hello,

I've tested the merge policy with a BarsRequest and I finding the supplied merge policy does apply correctly for a BarsRequest

https://drive.google.com/file/d/1rqBY9btGYxk4w415nM5K5daNdOWRID7W/view?usp=drivesdk

Since a BarsRequest is an Addon method that is not synchronous with the script, a BarsRequest can be done any time in any method in any state. There is no need to wait for anything. If you are connected for data, the bars will always be available.

[BarzTrading]

Thanks, Chelsea, for putting together that video. I still have some things to test on my end, but would you mind sharing the indicator code from your video so I can validate that I'm doing things the same way?

I don't understand your last paragraph. You say BarRequest is not synchronous, but then that there's no need to wait for anything. Usually, asynchronous calls imply that you may need to do some kind of waiting or checking in your code to make sure the asynchronous call has completed. But before I get ahead of myself, I want to make sure I'm doing things like you are. So, if you are OK posting your indicator code, that would be very helpful.

UPDATE: OK. Different uses of the word synchronous. By synchronous you're talking about a data series being synchronized with the primary bars and OnBarUpdate cycle of a ninjascript. When I say synchronous I'm talking about C#. An asynchronous method is one that does not block your code execution.

[NinjaTrader_ChelseaB]

Hello BarzTrading,

My meaning was about the data.
'A BarsRequest provides underlying market data for an instrument, but is not synchronized with an indicator or strategies primary data series. You will need to implement your own BarsUpdateEvent logic.'

https://ninjatrader.com/support/helpGuides/nt8/en-us/barsrequest.htm

However, its also asynchronous in threading terms as well. The callback method that uses the data is called after the bars request is performed. This is asynchronous with any code that may be outside of the callback. (Which is why that code must be in a callback instead of just writing code below the method call.)

I'm calling BarsRequest on the last bar of historical data... mostly because thats where I thought you might want to use it. But really I could call it anywhere. For example I could put that code in OnStateChange(), or in a timer, etc.

[BarzTrading]

OK. So I used your indicator and was able to exactly replicate your video with exactly the same outcomes.

However, the problem I'm observing with MergePolicy becomes apparent when you put the indicator on the same chart window rather than a separate chart.

Try the following:

• Load ES 12-18 on a chart.
• Add your BarsRequestMergeTest indicator (which also requests ES 12-18 bars.)
• Adjust date range as in the video
• Step through the following scenarios in order

#1:
Global Merge Policy: Backadjusted
BarsRequest Merge Policy: Backadjusted
Observe: Prices from the BarsRequest (in the output window) match those on the chart.

#2:
Global Merge Policy: Backadjusted
BarsRequest Merge Policy: Non-Backadjusted
Observe: Prices still match even though they shouldn't. Output window (BarsRequest) shows the backadjusted prices rather than unadjusted.

#3:
Global Merge Policy: Non-Backadjusted
BarsRequest Merge Policy: Non-Backadjusted
Observe: Prices match.

#4
Global Merge Policy: Non-Backadjusted
BarsRequest Merge Policy: Backadjusted
Observe: Prices still match even though they shouldn't. Output window (BarsRequest) shows the unadjusted prices rather than the adjusted ones.

[NinjaTrader_ChelseaB]

Hello BarzTrading,

I did more testing and was able to find some odd behavior when the Global Merge Policy is set to 'Do not merge' or 'Merge non back adjusted'. It looks like either of these settings set globally is forcing the BarsRequest to specifically use MergeNonBackAdjusted.

However, I wasn't finding adding this to the same chart or a different chart changes the values from the BarsRequest in any way.

I've reported the behavior with the global merge policy affecting the BarsRequest. Once I have a tracking ID for this I will post in this thread.

[NinjaTrader_ChelseaB]

Hello BarzTrading,

I've received tracking ID #NTEIGHT-13418 for this behavior where changing the Global Merge Policy is affecting BarsRequests.

As new versions of NinjaTrader 8 become available please check the release notes for this ID.

https://ninjatrader.com/support/helpGuides/nt8/en-us/release_notes.htm

Once the ID is listed, please update and test for the behavior.

[BarzTrading]

FYI: It appears the fix for this issue has been released with version 8.0.17.2. I haven't tested it myself yet.

Tracking ID: 13418

https://ninjatrader.com/support/helpGuides/nt8/en-us/8_0_17_2.htm