BarRequest does not return up to date, data

[pjsmith]

Hello,

I have implemented BarsRequest to load a day of data (it seems it always returns a full day rather than using the specific time stamps, which is explained in doc and OK), and filter out the data I do not need.

I am using barsRequest = new BarsRequest(Instrument, s, e)

and

barsRequest.BarsPeriod = new BarsPeriod { BarsPeriodType = BarsPeriodType.Tick, Value = 1 };

However, I find that is does not return all the days data. For example, I am requesting a 1 tick series from a start datetime to an end datetime. I get the full day. Reported as 57760 bars (from bars.Bars.Count). I wait a few minutes and try the same request again (the mkt is open and 100's if not thousands of ticks have come in during that time), and I still get 57760 bars of data. I wait a bit more, try again, and still get 57760 bars of data... Endtime (e) of each request is set to DateTime.Now, so I'm confused as to why I get the same data returned each time.

I don;t see anything in the docs related to this. Any explanation? Thanks.

[NinjaTrader_Jesse]

Hello pjsmith,

I just wanted to provide a quick note to let you know I am looking into this. Once I have more details on if this is expected or not I will reply back here.


I Look forward to being of further assistance.

[pjsmith]

Thank you

[NinjaTrader_Jesse]

Hello pjsmith,

After further review I believe this is expected depending on how you are forming the BarsRequest. There is a note which likely relates here:

When using the DateTime fromLocal and toLocal parameters, the dates are converted to local daily timestamps (12:00 AM) and return a BarsRequest representing full trading days. If you need to request less than one full trading day, please use the barsBack parameter

If you are not using BarsBack we should see a different data set than you were expecting due to the change of times. I will need to look further into this specifically as the time I see is not specifically 12:00 am but does seem to relate to the difference you observed.

If you instead use the BarsBack overload I see up to date data populated each time I request. Perhaps a solution is to estimate the number of bars needed based on the overall goal/chart values and then supply that as the BarsBack to gather 1+ day of data.


I look forward to being of further assistance.

[pjsmith]

Hi - Thanks for looking into it. I'll be interested to know what you find.

I am not using barsback. I did see this comment in the docs. Was not 100 percent sure what to make of it to be honest, but I did experience that I was getting the full day of data, regardless of my selection of data, so I assumed that was related. I'm requesting non time based data (tick series), so a bit hard to use barsback. Could be incredibly different numbers of ticks between instruments. I've just been testing a bit more, and it does seem that, on first request, I get the full data set. On subsequent requests, I never get the new data, despite the end date changing. It's almost as if the request gets cached somewhere. Future requests stop at the stage the first request ended, if you get what I mean.

[pjsmith]

As an experiment, I tried changing the end date from datetime.now, to datetime.now+1 day, i.e. , in the future, the next day. So, even if the time was being changed internally, we should still get data to the end of the current session ( as far as I can tell from docs), but we do not. It never serves me data past the end of that first request, which is to the end of the session, at the time that first request is made.

[pjsmith]

Hi,

Just a follow up. Did you find out why this happens? I revisited it again as I was using no-tick based charts, and confirmed the same problem. I see it as an issue. Once the data is requested (and you are not using bars back method), if you request again at a later date, you never get new data. I can;t see this makes sense if by design. If it is by design, please let me know so I can code accordingly. If a bug, I will leave until fixed.

Thanks.

[NinjaTrader_Jesse]

Hello pjsmith,

Thank you for the reply.

At this time I am waiting for further details about the internal workings of this overload, once I hear back on this and have more detals I will reply back.

I look forward to being of further assistance.

[NinjaTrader_Jesse]

Hello pjsmith,

I wanted to provide an update here.

The reason this is showing the results as you see them is that the BarsRequest is being used improperly. It is not expected to recreate a new bars request for each request like this. It is expected to get a same result in this use case based on how the barsrequest works. It would only be suggested to call this once to initially do the request and then use the Update event going forward.

Is there a specific reason you are trying to re do the request each time you call this logic rather than doing it once and using the Update method?


I look forward to being of further assistance.

[pjsmith]

Hi,

The idea is to grab a specific potion of data from history, i.e bars 30-80 of a 200 bar set. No more, no less. No realtime data is needed, hence subscribing to update etc. would not be good. The user might request different bars a few minutes later, or any time, so the request is re-made with different parameters (which will not work). I could not see another way to pull, on demand, a portion of historical tick data. If there is another way to do this, please let me know. (I am NOT wanting to create a tick series in the indicator as this is _very_ wasteful on NT's already very limited resources). Pulling just the data required seems like the better way to do it, but perhaps I have gone about it the wrong way?

[NinjaTrader_Jesse]

Hello pjsmith,

Thank you for the reply.

Based on the requirements this would not likely be a feasible goal with the current means to load data.

I believe part of the problem is this part of the task:

I could not see another way to pull, on demand, a portion of historical tick data.

There is not currently a specific method that would be suggested for that purpose. A BarsRequest will return bars but is generally not intended to be used as a historical data repository, this is mainly intended for subscribing to realtime data for an instrument. This is commonly used in combination with a few other addon concepts to build realtime order entry tools.

Because it is expected that the overload you used will return this type of result, the other overload could potentially be used however that is not the suggested use case for BarsRequest. You can experiment with that overload in addition to adding logic to calculate a BarsBack.

The alternative would be to use AddDataSeries with the BarsBack overload and use the secondary series data however in that case you would need to know ahead of time the number of bars you might need.


I look forward to being of further assistance.