Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Coding Multi Time Frame (MTF) Indicators with NinjaTrader
Yes, I had the same problem with the GetNextBeginEnd() signature for the multi timeframe version of the Opening Range indicator. I have corrected it now and made a number of smaller improvements as well.
X3 means that it is the third eXperimental version of the indicator. When it is ripe, I will put it into the download section of this forum. I think it is close.
The chart show the opening range calculated from 1 minute data. The red highlighted range is the range of the first minute of trading. The night session high and low is shown as well.
The indicator should not throw any exceptions as was the case with the V32MTFX2 version.
Can you help answer these questions from other members on NexusFi?
This is the enhanced version of the multi-timeframe EMA. As before you can select between the step mode, which reflects the values generated by the secondary bars and the interpolated visual mode, which smoothes out the step. This version now also allows to select the Input series, meaning that you can calculate the multi-timeframe EMA from the Close, High, Low, Median, Typical or Weighted series.
Thanks for all this work, FT. This is great thinking! MTF Visual EMA indicator is excellent!
Because of rampant risk asset correlation it can be beneficial to track instruments other than the one you are trading. This suggests the idea of secondary indicators that would be based not only on a different time frame, but on a different instrument.
For example, on a 200 tick chart of the CL, display in an added panel the 20 period EMA of the 3 rangeES... etc. while maintaining the equidistant bar spacing of the 200 tick CL in the Price Panel.
I wrote some indicators that display a secondary data series. What I found is that when BarsInProgress =1, there is always a new value of Closes[1][0] and any variables associated with it DO update. However, the new values are NOT shown on the chart until the next tick comes in for the primary series, where BarsInProgress = 0.
For example, I was showing a plot of ^TICK on a 250 tick chart (with equal bar spacing) of YM. During the customary YM super slow periods, could see that the ^TICK plot did not respond when the time and sales showed new values of ^TICK coming in. The ^TICK plot only updated when a new value of YM printed, although diagnostic statements printing to the output window showedthat new values of Closes[1][0] were indeed all coming in when they were supposed to.
In other words, the chart display only updated when BarsInProgress was equal to 0.
The solution that worked for my indicators : FORCE the chart display to update every time a new price tick comes in for the secondary series.
If I refresh the chart with each incoming tick, when Barsarray[1] is processed , do you know whether that will override the chart display update interval?
I do not want to cause a NinjaTrader freeze by refreshing the chart for each incoming tick, if the market is moving fast.
I am not sure whether the forced Refresh overrides the chart display interval. This could be checked by printing diagnostic messages with the Refresh times down to the millisecond to the Output Window. You could keep track of the time of the last Refresh and not allow the forced refresh to occur unless a certain number of milliseconds has elapsed since the last refresh.
However I have NOT done this. The forced Refreshes on every update of the secondary series have not caused any problems with my indicators as long as the command is a separate statement near the end of OnBarUpdate. Have not seen any problems at all during fast markets.
Another condition you can subject it to is to only trigger if the value of what you are plotting has changed from its most recent previous value.
I really appreciate your input here. May main concern is CPU load. Let us assume - for the worse - that I have 15 indicators on my chart, out of which 3 are multi-timeframe indicators and 5 have custom plots (for example the pivots do have custom plots that can create a bit of CPU load)
How does NinjaTrader process the indicators internally?
Process A
1. new incoming tick
2. triggers OnBarUpdate for primary bars for indicators 1 to 15
3. plots (if time elapsed smaller display update interval)
4. trigger OnBarUpdate for secondary bars of first multiseries indicator
5. plots (if time elapsed smaller display update interval)
6. trigger OnBarUpdate for secondary bars of second multiseries indicator
7. plots (if time elapsed smaller display update interval)
8. trigger OnBarUpdate for secondary bars of third multiseries indicator
9. plots (if time elapsed smaller display update interval)
Process B
same as above, but additional 14 plots within the step 2.
The code snippet meant to assure that the refresh is not executed, if the last refresh was less than n milliseconds ago. Now I cannot know the last refresh time, unless I have an indicator with an override Plot() to collect it.So I am thinking about two options here
First Option: measure the difference between the last two incoming ticks and compared it to the display update interval (this assumes that the tick speed remains constant, and may at worst trigger one additional refresh, but not 100).
Second Option: Code a separate indicator that will automatically refresh, by using a user-selectable display update interval.
The OnBarUpdate event is only called ONCE per incoming tick. Refresh without fear!
Definition of BarsInProgress from Ninjatrader help:
An index value of the current Bars object that has called the OnBarUpdate() method. In a multi-bars script, the OnBarUpdate() method is called for each Bars object of a script. This flexibility allows you to separate trading logic from different bar events. In a single Bars script this property will always return an index value of 0 representing the primary Bars and instrument the script is running on.
(note: For primary instrument price series n=1, for second series n=2, third series n=3....nth series n=N)
(BIP=BarsInProgress, an integer returned for each OnBarUpdate event)
The OnBarUpdate event is always fired ONCE when a tick arrives. It's the same event no matter which bar series the tick comes from. The only difference is what value BIP is set to. For some reason, only when BIP=0 will OBU cause the chart to refresh. I consider this to be a Ninjatrader bug.
1. data feed sends a new incoming tick of primary instrument price series(n=1)
2. triggers OnBarUpdate in which the value of BIP is 0. All the code in OnBarUpdate executes... ONCE only.
3. BECAUSE the value of BarsInProgress is 0 the chart will refresh.
3. data feed sends a new incoming tick for instrument N
4. triggers OnBarUpdate in which the value of BIP is N-1. All the code in OnBarUpdate executes... ONCE only.
5. BECAUSE the value of BarsInProgress is NOT 0 the chart will NOT refresh. NINJA BUG
6. So we force the chart to refresh. if(!Historical && BarsInProgress >0...&& whatever)
OnBarUpdate is called ONCE each time there is a tick from ANY of the instruments, no matter how many instruments there are.
All the BarUpdate events DO occur exactly when they are supposed to. Whenever ANY of the series updates, OnBarUpdate DOES occur. OnBarUpdate events are driven directly by the different series in real time and are not dependent on each other in any way. However the APPEARANCE OF THE CHART only updates when BIP=0!
You can see this in the output window. OnBarUpdate events will fire with different values of BIP whenever any of the series generates a tick, but the chart will only refresh when BIP=0.
So far I do not see any indication that the forced refreshes cause any noticeable increase in CPU load.
Bonus! Did you know that you can index the CurrentBar expression to find where you are in each data series! Instead of CurrentBar write CurrenBars[N]. If you want to be sure you are looking at the CurrentBar of the primary series, you will have lots of "interesting' problems if you say CurrentBar instead of CurrentBars[0], because CurrentBar will keep returning values for different instruments!
The VisualEMAX with a period of 1 can be used as a proxy for the price of a series with any time frame including or other than that of the chart. But when I try to take advantage of this by runnng an indicator that calls the VisualEMAX3 I get the error:
Error on calling OnStartUp method for indicator VisualEMAX3, Object reference not set to instance of an object.
My indicator then displays nothing.
The same thing happens when I try to apply another indicator to the VisualEMAX3 using the NT7 indicator-of-an -indicator feature of the indicators dialog box.
Because the code is in a DLL I can't do anything about the error. FT, could you please consider adding try{ }catch error handlers to all of the methods of the indicator to make sure that all exceptions are handled to prevent crashing of indicator from unhandled exceptions. Thanks.
I understand that OnBarUpdate() is triggered for each bars array. So if datafeed produces a tick containing price data, this will be first processed for BarsArray[0], then for the other BarsArrays. What is confusing is the order of the other bars being processed. Let us assume that I apply a multi-timeframe indicatoro to a multi-dataseries chart. If the secondary bars objects of the MTF indicators matches the secondary bars objects of the underlying multi-series chart, NinjaTrader will not recreate the bars. So there will not be two 5 min bar series for ES 06-11, but only one, as the MTF indicator will use the already existing bars array of the multiseries chart. Could this inverse the order in which the BarsInProgress are selected?
Also I have observed some rare cases, where BarsInProgress=0 have been updated twice in a row (real-time), without any update of BarsInProgress=1 (double BIP), but I was not able to reproduce it.
Guess, I just will try out some code snippets and then see how it plays out in real-time.
All my multi timeframe indicators use CurrentBars[N] for clarity. Just had a problem in a custom plot, where CurrentBar returned false values. But CurrentBars[0] also did return false values, still have no idea why.
