intraday volume returned by volume(0) is not correct

[clearpicks]

It seems main() is not called every tick, which is not a big deal when efs is running on fast moving futures contracts like YM and CL because at any price level, the bid and ask sizes are very small. Threfore main() is called frequently enough so that an EFS can use "return volume(0)" to return the volume within current bar without introducing much error. Even for ES, this is not a big problem either, because the last price changes frequently therefore the intraday volume returned by volume(0) is updated quick enough. However, for futures contracts like ZN, this is a big problem. For most time, the bid and ask sizes are hundreds contracts, and hundreds even more than one thousand contracts may be executed at the same price level with ask , bid and last prices unchanged. Because main() is not called every transaction, the volume of "ZN H8" is not displayed correctly, which is especially true for time frame les or equal to 1 minute. To ilustrate what I am saying, just open an 1 minute chart of ZN H8 and apply the following efs and the basic volume study coming with esignal and keep the chart running for a whole in realtime. Soon you may see the diff value printed is not equal to 0 for most bars. Clicking at "OK" on the cursor window to force ZN H8,1 being reloaded, then you may very likely to see the volume values in corsor window have be changed. It seems if calling volume(-1) when getBarState() == BARSTATE_NEWBAR ( at the beginning of each bar ), volume(-1) reurns the correct volume of the previous bar, however volume(0) can not always return the correct volume of the current bar because main() is not called every transaction.

Any comment on this? One workaround I can think of is to do something at the beginning of each new bar to correct the volume value of the previous bar.


- Clearpicks



var v1;
function preMain()
{
setPriceStudy(false);
setStudyTitle("Volume_Test");

setDefaultBarFgColor(Color.grey,0);
setPlotType(PLOTTYPE_HISTOGRAM,0);
setHistogramBase(0, 0);
setDefaultBarThickness(2,0);
setShowCursorLabel(false);

}

function main( )
{
if ( getBarState() == BARSTATE_ALLBARS ) {

}

if ( getBarState() == BARSTATE_NEWBAR ) {
if ( getCurrentBarIndex() == 0 )
debugPrintln(hour(-1) + ":" + minute(-1) + " volume(-1) = " + volume(-1) + " v1 = " + v1 + " diff = " + ( volume(-1) - v1 ) );
}
v1 = volume(0);
}

[eSignal_JasonK]

Hello Clearpicks,

Thank you for reporting. You're findings are correct and this is a known issue. This issue has been under investigation internally. Unfortunately there isn't a EFS work-around for this. The source of the problem is not within the EFS environment.

[tinker70]

Jason, Thanks for the info. Is this still a problem? If so, is it fixed in the ActiveX API? Or is this a data-manager 'problem' (issue?)?

Thanks.

Originally posted by eSignal_JasonK
...You're findings are correct and this is a known issue. This issue has been under investigation internally. Unfortunately there isn't a EFS work-around for this. The source of the problem is not within the EFS environment.