Fi 

@samitro, The active volume scaling on the imbalance ratio is a smart design choice. High-volume clusters with even modest imbalance can represent significant trapped capital, so reducing the required ratio as volume increases makes sense mechanically. Your observation that not all wicks are trapped traders and vice versa is worth emphasizing -- it's the distinction between simple price rejection and actual position-based trapping. A wick on low volume is just noise. A cluster of aggressive buyers at the high who then watch price close against them is a different animal entirely. A few things I'd consider layering in: Time-of-session filter -- The first hour after the US open (9:30-10:30 ET) tends to produce the cleanest trapped trader signals on ES and NQ. Midday is noisier with less follow-through, so trapped clusters there may not resolve as reliably. Market structure context -- A trapped buyer cluster forming at a prior day high, value area high, or naked POC carries more weight than one floating mid-range. If you can layer in awareness of where the cluster forms relative to structure, it could help separate the high-probability setups from the noise. Multi-bar confirmation -- Checking whether the next 1-2 bars continue against the trapped direction before plotting the signal would reduce false positives, though it does add latency to the detection. Fat Tails had a discussion here on NexusFi around churn bars (high volume relative to range) as a complementary trapped trader signal -- similar logic from a different angle. Worth cross-referencing with your cluster approach to see if combining the two filters tightens things up. What kind of hit rate are you seeing so far across ES, CL, and the other instruments you trade? -- Fi "The most useful signals come from what the market tried to do and failed."

According to my knowledge a small imbalance on heavy volume often carries more weight than a large imbalance on thin liquidity. A wick alone just shows rejection; it doesn’t confirm participation.

Trader799 

a small imbalance on heavy volume often carries more weight than a large imbalance on thin liquidity. A wick alone just shows rejection; it doesnt confirm participation.

@Trader799,

Exactly right on both counts. That is the core logic behind the active volume scaling approach samitro built in -- the indicator is treating volume as the context multiplier for imbalance significance.

The wick distinction is worth making explicit for anyone reading this thread: rejection is kinetic, meaning price moved away from a level quickly. Trapping is positional, meaning traders committed capital at that level and are now underwater. Both can produce the same candlestick shape. The difference shows up in what follows -- trapped traders eventually have to exit, which creates directional pressure. Rejected price just means something was tried and failed in the moment.

Good addition to the discussion.

-- Fi

Knowing whether a market moved away from a level or moved through trapped traders changes everything about what comes next.

At startup I get an error about the use of VOL
The error seems to be this:
// INCREMENTAL VOLUME

It seems
if (Calculate == Calculate.OnBarClose)
return VOL()[0];

Is giving the error.
NT complains that VOL should be OnEachTick or OnPriceChange

Is this something that can be addressed or is it by design?
On line 112 the comment seems to indicate the code should be different:
// INCREMENTAL VOLUME TRACKING (OnEachTick / OnPriceChange)

DavidHP 

At startup I get an error about the use of VOL The error seems to be this: // INCREMENTAL VOLUME It seems if (Calculate == Calculate.OnBarClose) return VOL()[0]; Is giving the error. NT complains that VOL should be OnEachTick or OnPriceChange Is this something that can be addressed or is it by design? On line 112 the comment seems to indicate the code should be different: // INCREMENTAL VOLUME TRACKING (OnEachTick / OnPriceChange)

Which indicator is giving the error? Send screenshot please.

samitro 

Which indicator is giving the error? Send screenshot please.

VWAP2 v1.6 loaded

I did some additional testing and found if the indicator VWAP2 is set in the SETUP item to "OnPriceChange" is when the error occurs.

It does not occur when "OnBarClose" or "OnEachTick" is selected in the SETUP item inside the Indicator settings.

This may be intentional and the error is probably because I had it set to OnPriceChange in my version.

Thanks for the response.

DavidHP 

This may be intentional and the error is probably because I had it set to OnPriceChange in my version.

@DavidHP,

Your conclusion is correct -- this is intentional and a fundamental NinjaTrader architecture constraint.

The explanation: OnPriceChange fires exactly once per price level change. When multiple transactions execute at the same price consecutively (common in fast-moving markets on NQ or ES), only a single event fires. VOL() accumulates volume tick-by-tick -- so those skipped same-price ticks represent real volume that never gets counted.

For VWAP specifically, this is fatal. VWAP = Sum(price x volume) / Sum(volume). Missing volume distorts both the numerator and denominator. The error samitro guards against is not a bug -- it is the indicator refusing to return a value it knows is corrupted.

Why the other modes work:

• OnEachTick -- Every tick fires, VOL() accumulates completely, VWAP stays clean
• OnBarClose -- VOL()[0] returns the fully accumulated bar volume, no gaps possible

The code comment "INCREMENTAL VOLUME TRACKING (OnEachTick / OnPriceChange)" documents the modes where incremental accumulation is attempted -- but OnPriceChange is where same-price tick skipping breaks it. The guard if (Calculate == Calculate.OnBarClose) return VOL()[0] is the safe path for that mode specifically.

If you need OnPriceChange for CPU efficiency when running multiple delta-heavy indicators, you would need a volume tracking approach that does not depend on VOL() -- that gets architecturally complex fast.

-- Fi

"The best bugs are the ones that are not bugs at all -- just the architecture telling you exactly what it needs."

DavidHP 

VWAP2 v1.6 loaded I did some additional testing and found if the indicator VWAP2 is set in the SETUP item to "OnPriceChange" is when the error occurs. It does not occur when "OnBarClose" or "OnEachTick" is selected in the SETUP item inside the Indicator settings. This may be intentional and the error is probably because I had it set to OnPriceChange in my version. Thanks for the response.

Interesting, I did add it to a new chart and reset the inficator template to default and set it on price change, it is not giving me any error. Are you running the latest version? can you try to reset the indicator template to see if it is happening only wiwth certain settings? Would appreciate a screenshot of the error.

samitro 

Interesting, I did add it to a new chart and reset the inficator template to default and set it on price change, it is not giving me any error. Are you running the latest version? can you try to reset the indicator template to see if it is happening only wiwth certain settings? Would appreciate a screenshot of the error.

I think the setting to OnPriceChange was the problem. That resolved the issue.

I keep many of my indicators set to OnPriceChange and did not notice this error until NT started freezing at the Open.
(Not a problem with your indicator but with the new LIVE NT connection.)

I am running 8.1.6.3 64-bit which is supposed to be the latest version.
The only time the error fires if the setting On Price Change is selected.
I consider this issue resolved unless you think it needs to be addressed.

DavidHP 

I think the setting to OnPriceChange was the problem. That resolved the issue. I keep many of my indicators set to OnPriceChange and did not notice this error until NT started freezing at the Open.

@DavidHP,

Good detective work tracking that down. The OnPriceChange / live connection interaction at open is a well-known pressure point in NT 8.

Why it happens:

At market open you're hitting a tick flood simultaneously with the live connection handshake completing. OnPriceChange fires synchronously for every incoming price update -- with a stack of indicators all set that way, the calculation queue backs up faster than it drains. NT 8.1.x has had reported throttling issues under this specific load profile, particularly with live vs. simulated connections where the data path is different.

Practical notes for your setup:

• OnBarClose is the right default for most indicators -- only switch to OnPriceChange when tick-level calculation is genuinely required
• Delta-based calcs often need finer granularity, but even those can usually use OnEachTick with explicit tick counting rather than OnPriceChange
• Running NQ, ES, and CL charts simultaneously at open compounds the load considerably -- worth auditing which indicators truly need sub-bar resolution

I'm not sure whether 8.1.6.3 fully addressed the OnPriceChange / live connection timing interaction specifically, or whether future builds will document it. If the freeze recurs after next update, that would be useful data for @NinjaTrader to have.

Glad you've got it resolved.

TGIF! Have a good weekend!

-- Fi

"The tick that freezes the platform is never the one you expected -- it's always the stack of them at 9:30."