Overriding Plot() method in multi-series indicator

[MikeInMA]

If you override the Plot() method in a multi-series indicator, is BarsInProgress available within Plot()?

[NinjaTrader_Brett]

Hello,

No Bars In Progress would not be availiable inside of Plot(). Plot is meant to change the output of the data generated out of OnBarUpdate() which then has access to BarsInProgress since this is a OnBarUpdate() function.

Let me know if I can be of further assistance.

[MikeInMA]

Does override of Plot() run before or after OnBarUpdate()? If after, it would seem that OnBarUpdate() could capture BarsInProgress and make it available for Plot(). Otherwise it would appear that you can override Plot() or have a multi-series indicator, but not both.

[NinjaTrader_Brett]

Hello,

This is a race condition where there is no set "Run Before or Run After". Therefor you could find it always goes one way or you may find this changes from time to time. Pretty much anything with overriding Plot() I really cant offer a supported response on Unfortunately.

Let me know if I can be of further assistance.

[ETFVoyageur]

Brett,

Not to argue with you, because you know your system thoroughly and I do not.

That said, how do you reconcile the following two things you said in this thread? I would think that the second of them would imply that Plot() must run after OnBarUpdate(), which is what common sense would also say -- how can you plot something if OnBarUpdate() has not yet run to create what needs to be plotted?

--EV

This is a race condition where there is no set "Run Before or Run After". Therefor you could find it always goes one way or you may find this changes from time to time.

Plot is meant to change the output of the data generated out of OnBarUpdate() which then has access to BarsInProgress since this is a OnBarUpdate() function.

[David Lean]

ETF Voyageur
In a multi-threaded (multi-cpu) environment multiple tasks can occour in parallel.
While I did much more testing in v6.5 than v7.0. I've found you need to treat the plot event as completely independant to the other events (ie OnBarUpdate() )

So far I've been totally unsuccessful in passing state between them. I believe they both grab the Graphics object & manipulate it as they desire.

While I suspect you are correct & the OnBar logic needs to complete prior to the PLOT even being called. It would also possible to architect it so that the PLOT even it not called for every bar & the chart is often treated as a bitmap that is slid to the left with only the right most bar invalidated & painted by another undocumented event.

OR alternatively the PLOT event fires, partially completes, waits on a spinlock, calls OnBarUpdate() & then completes.

But most likely the memory structures of OnBarUpdate are isolated in a separate piece of memory owned by 1 thread & not shared with the PLOT structures owned by the other thread.

[ETFVoyageur]

In a multi-threaded (multi-cpu) environment multiple tasks can occour in parallel.
While I did much more testing in v6.5 than v7.0. I've found you need to treat the plot event as completely independant to the other events (ie OnBarUpdate() )

Interesting. I have no idea how much parallelism NT has. My testing has only been on a single P4 w/hyperthreading, so I am probably not seeing the parallelism, even if it is there.

Actually, the whole idea that parts of my indicator may be operating in separate threads strikes me as bizarre, because I have seen no mention anywhere of needing to lock data that is shared between different class methods. Ar you certain that OnBarUpdate() and Plot() can operate on separate threads? Furthermore, they want creating custom indicators to be easy -- and it they make single indicator instances be multi-threaded ... wow.

My observation is that Plot() is called a great deal -- at times it is called when I can see no reason at all for it to even be called. Most of these Plot() calls bear no relationship to OnBarUpdate(). I have been of the impression that one of the times Plot() will be called, though, is after OnBarUpdate() has completed its series (i.e. not after each call to OnBarUpdate()).

Do my observations mesh with yours?

So far I've been totally unsuccessful in passing state between them. I believe they both grab the Graphics object & manipulate it as they desire.

I would not know about the graphics object, because I have never tried to do any graphics form OnBarUpdate().

I was passing state from Plot() to OnBarUpdate(), and my Plot() reads the data the OnBarUpdate() produces. So far that is working. From what you say, I may just be lucky because I am not in a multi-core environment (I don't suppose the hyperthreading qualifies?). So far, I have seen no evidence of multi-threading issues. Is there a writeup anywhere about that?

While I suspect you are correct & the OnBar logic needs to complete prior to the PLOT even being called.

Some of the time. Plot() is called lots of other times, too. My experience is that Plot() appears to be called any time NT has any suspicion that there might be a pixel out of place. It just needs to go with whatever data it has available at that time. One of those times appears to be right after the last call to OnBarUpdate() for its data series (i.e. after the call about CurrentBar, if you are scrolled all the way to the right).

It would also possible to architect it so that the PLOT even it not called for every bar & the chart is often treated as a bitmap that is slid to the left with only the right most bar invalidated & painted by another undocumented event.

I hope they do not ever do that -- it would be a disaster for the class of indicators that plot depending on the right edge. As it is, when the user scrolls left (backwards in time) OnBarUpdate() is not called. What I have to do is have Plot() notice that has happened and arrange to have the right logic called to update the screen.

This is one of those indicators that needs to update the screen whenever you scroll in either direction. It is bad enough that there is no way to tell NT that OnBarUpdate () need to be called for scrolling left, but to remove that from Plot() as well would make this class of indicator impossible to even do for NT.

--EV

[David Lean]

Hey EV- Your observations are consistant to mine. I've been running on a Quad core + HT, so it has simulated 8 procs. I did read that NT 7 has code changes that make more use of threading. And I have seen more threads than v6.5.
As SQL server is the most thread efficient engine I've ever seen, I thought it might be responsible but as it is only SQL Compact & not the Desktop (server) edition, it would mostly run in process.

Of course as so much of the API is undocumented it is no surprise that the threading engine is even more of a black box. I've not bothered to reverse engineer it. As anything I learnt could change from service release to the next.

I expect you are right & all the methods of the same indicator run in the same thread. It would be much easier to introduce parrallism into NT by :-
1. Using different threads for different functional groups (eg: Data Feed, Order Execution, Disk IO, Presentation layer(Charting & User UI). Especially the Async Tasks.
2. Perhaps spin up a thread per Chart.
3. Breaking each indicator into its own thread. Thus Permitting the calculations to be done in parrallel.
The .NET Parallel Extensions would make this a largely simple process.

Of course you can over do it. Then the overhead of managing vast numbers of threads becomes greater than the benefits they provide.

Generally I saw PLOT() called after OnBarUpdate() but it was called so many other times I wondered if my tesing was incomplete & there were circumstances when it wasn't called after OnBarUpdate() & I'd just been unable to create a test that produced that event.
Dave

[ETFVoyageur]

> Hey EV- Your observations are consistant to mine.

Good -- glad our observations are consistent.

> ... I wondered if my tesing was incomplete & there were circumstances when it wasn't called after OnBarUpdate() & I'd just been unable to create a test that produced that event.

That's the Black Swan issue -- no amount of observation will prove it is always called after OnBarUpdate() has completed its series. All I can say is that my program works on that assumption, and I have never seen a problem. Note that it is not called after every call to OnBarUpdate(), just after NT is done calling OnBarUpdate() for now.

--EV