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)
We are not aware of any limitation regarding plots updating only on BarsInProgress == 0. Please try the attached test reference on a 1min chart. The indicator adds two additional 30 second series which would process twice as much as the BIP0 of 1min. The indicator has 3 plots, each one representing the number of bars of each Bar series multiplied by a different factor so we can view them easily. With the Output Window open you can see the last BIP0 event shows CurrentBar counters of 4805, 22764, and 33738 for BIP0, BIP1, and BIP2 respectively. The next event was the BIP1 event which updated the BIP1 counter to 22766 and the final BIP2 event updated the BIP2 counter to 33741. There has been no subsequent BIP0 event yet so if it were the case that plots only updated on BIP0 then we would actually still be seeing the original values of 4805, 22764, and 33738, but instead we are seeing the BIP1 and BIP2 updated values on the chart of 4805, 22766, and 33738.
In our test the chart is “refreshing” and updating whenever deemed necessary by the code as it asks to update the plot values. I would be curious how your environment might differ from ours and/or how your code might be different? It would be great if you could breakdown how exactly you came to the conclusion that these values do not update on the chart outside of BIP0.
Thanks for responding, Ninjatrader. Glad to see your interest in this important and under appreciated topic.
Right now, in real time, I am running an indicator that plots an ADDed series of ^TICK on a chart having primary series YM. To test it I run it side by side with a Time and Sales of ^TICK.
If the line (#303)
,
is in the code, the plot of ^TICK updates in lockstep to the T &S. As soon as I comment out the line and refesh the chart, the plot of ^TICK only updates when there is a trade of the YM, which sometimes doesn't happen for a while.
It's ideal to test this on the chart of a master instrument that trades much slower than the ADDed secondary instrument. Then it is very noticeable when the chart does nothing in response to ticks of the secondary instrument that print to the Time and Sales.
I mentioned this on the Ninjatrader forums using my secret identiy of "Ricam". RyanM responded with a request for clarification.
In your code, all the events happen as they should. So the print statements all fire. Mine did that too. But the plots would not update on the screen image unless it was a BIP=0 update. It's only the visual appearance of the chart on the screen that lags. As far as I know the code in the OnBarUpdate method always DOES respond correctly to the events generated for each of the Bars series.
My indicator is attached fo you to play with. I would call this version a "pre-beta". You will see that I have been doing a lot of error tracking. It runs without any runtime errors most of the time now. It seems to be accurate for real time data, but maybe not for backfilled data... but that's a whole other story.
I have now slightly modified the indicator to show a problem that I have encountered. Same indicator, but I now use a 2 minute chart of 6E and add the 7-min and 29-min bar series of the same instrument 6E. Further I check for historical data to identify whether the ticks shown on the output window are historical or real-time ticks. Then I use the indicator in CalculateOnBarClose = false mode. Indicator is attached.
Below is an excerpt from the output file. In real-time, I would have expected that an incoming tick of 6E triggers BarsInProgress 0, 1 and 2 in an alternating way. However, what the output file shows, is that BarsInProgress is not at all called in a logical, but in a fuzzy way.
I ran the BIP test and agree with FT that something looks fishy.
Since all the bars are for the same instrument, all three of the Bar Series should update everytime there is a trade in the instrument. Or so it would seem.
@Zondor: Thanks again for identifying the bug. I have tested the indicator and identified the source of the problem. It is the code snippet below, which I used in OnStartUp().
It seems that ChartControl.EquidistantBars does not return a proper value.
I had used this because the algorithm, which interpolates the values calculated from the secondary bars series works in a different way on equidistant bars and non-equidistant bars as used for multi time series charts.
In case that the VisualEMA is called by another indicator or used in an indicator-on-indicator approach the visual interpolation cannot be used, so the indicator
-> should not be used in visual mode (repainting the distance between current and previous value of secondary bar series
-> does not need the information whether the chart is equidistant or non-equidistant
Does anybody know, how I can check whether the indicator is used for another indicator or whether it plots to a chart?
I don't know how to do this either, but as an expedient you could add a Parameter that allows the user to specify whether the indicator is being used by another indicator, or being displayed on a chart (default).
Needs to be under Category "Parameters" so it will be accessible in the dialog box when setting up the indicator of an indicator.
I asked Ninatrader Support to look into the BIP test. They have been extremely gracious, responsive and helpful.
I have overwhelmingly positive experience with the support staff as well. Basically there are just a fwe pending issues that are difficult to reproduce.
I do not want to go the route with the user selectable option, whether the indicator will be used within a strategy or by another indicator. As you suggested, I used try{} catch{}, so in case that ChartControl cannot be accessed the indicator will automatically switch to strategy mode. As the information, whether the indicator runs on equidistant bars or not is only needed for the interpolation in visual mode of the indicator, this should be a first solution. This is what I used and it seems to work.
Not elegant, but prevents that the indicator stops working.
Again tried using the VisualEMAX as the base for another indicator, this time choosing strategy mode, but got the same error from OnStartUp. I do realize that there is no error handler in this version, but this shows that simply switching to Strategy mode will, by itself, not prevent the error.