closing status of a bar sometimes takes too long

Questions about MultiCharts and user contributed studies.
janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

closing status of a bar sometimes takes too long

Postby janus » 18 Jul 2012

I've noticed even when the markets are liquid and very active, but there's no tick update for whatever reason after the end of the expected completion of a bar for several seconds, the study does not receive a barstatus value of 2 for way too long. I expect that say around two seconds after the end of a 1-minute bar to be completed that the system should send a barstatus value of 2 to notify the study the bar is finished even though no further update ticks have been received. Even using the new feature of forcing the study to run without update ticks is of no help. I now have to resort to special code to check when the bar is completed based on the computer's time, then wait a couple of seconds to generate my own equivalent of barstatus = 2. I understand MC waits a little while to make sure there are no stray update ticks with timestamps assigned to the previous bar. But to wait for anything like 15 or more seconds on a 1-minute chart is ridiculous. Yet that's what I see happen on occasion. It looks like a bug to me. Anyone else see this?

User avatar
JoshM
Posts: 2195
Joined: 20 May 2011
Location: The Netherlands
Has thanked: 1542 times
Been thanked: 1565 times
Contact:

Re: closing status of a bar sometimes takes too long

Postby JoshM » 18 Jul 2012

I've noticed even when the markets are liquid and very active, but there's no tick update for whatever reason after the end of the expected completion of a bar for several seconds, the study does not receive a barstatus value of 2 for way too long.
I haven't noticed that specifically, but you're right in stating that it can last a couple of seconds before the new bar is formed. However, this seems to be due that no new incoming tick is received, since only after a new tick is received the new bar is formed.

For example, in the output below there was no new bar for some 28 seconds, but this is seemingly due to no new tick received:

Code: Select all

19-07_06:45:48 BarStatus: 1, Ticks: 96, TotalVol: 42585, Time last quote: 06:45:49, Last: 1371.25
19-07_06:45:49 BarStatus: 1, Ticks: 96, TotalVol: 42585, Time last quote: 06:45:49, Last: 1371.25
19-07_06:45:50 BarStatus: 1, Ticks: 96, TotalVol: 42585, Time last quote: 06:45:49, Last: 1371.25
19-07_06:45:51 BarStatus: 1, Ticks: 96, TotalVol: 42585, Time last quote: 06:45:49, Last: 1371.25
19-07_06:45:52 BarStatus: 1, Ticks: 96, TotalVol: 42585, Time last quote: 06:45:54, Last: 1371.25
19-07_06:45:53 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:45:55, Last: 1371.25
19-07_06:45:54 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:45:56, Last: 1371.25
19-07_06:45:55 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:45:56, Last: 1371.25
19-07_06:45:56 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:45:57, Last: 1371.25
19-07_06:45:57 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:45:59, Last: 1371.25
19-07_06:45:59 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:45:59, Last: 1371.25
19-07_06:46:00 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:01, Last: 1371.25
19-07_06:46:01 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:01, Last: 1371.25
19-07_06:46:02 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:03, Last: 1371.25
19-07_06:46:03 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:04, Last: 1371.25
19-07_06:46:04 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:04, Last: 1371.25
19-07_06:46:05 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:04, Last: 1371.25
19-07_06:46:06 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:04, Last: 1371.25
19-07_06:46:07 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:04, Last: 1371.25
19-07_06:46:08 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:04, Last: 1371.25
19-07_06:46:09 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:11, Last: 1371.25
19-07_06:46:11 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:11, Last: 1371.25
19-07_06:46:12 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:11, Last: 1371.25
19-07_06:46:13 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:11, Last: 1371.25
19-07_06:46:14 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:11, Last: 1371.25
19-07_06:46:15 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:16, Last: 1371.25
19-07_06:46:16 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:18, Last: 1371.25
19-07_06:46:17 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:18, Last: 1371.25
19-07_06:46:18 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:18, Last: 1371.25
19-07_06:46:19 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:21, Last: 1371.25
19-07_06:46:20 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:21, Last: 1371.25
19-07_06:46:22 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:22, Last: 1371.25
19-07_06:46:23 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:22, Last: 1371.25
19-07_06:46:24 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:22, Last: 1371.25
19-07_06:46:25 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:26, Last: 1371.25
19-07_06:46:26 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:26, Last: 1371.25
19-07_06:46:27 BarStatus: 1, Ticks: 97, TotalVol: 42586, Time last quote: 06:46:28, Last: 1371.25
19-07_06:46:28 BarStatus: 2, Ticks: 97, TotalVol: 42588, Time last quote: 06:46:30, Last: 1371.25
19-07_06:46:28 BarStatus: 0, Ticks: 2, TotalVol: 42588, Time last quote: 06:46:30, Last: 1371.00
19-07_06:46:29 BarStatus: 1, Ticks: 3, TotalVol: 42589, Time last quote: 06:46:30, Last: 1371.00
19-07_06:46:30 BarStatus: 1, Ticks: 3, TotalVol: 42589, Time last quote: 06:46:31, Last: 1371.00
19-07_06:46:31 BarStatus: 1, Ticks: 3, TotalVol: 42589, Time last quote: 06:46:32, Last: 1371.00
19-07_06:46:32 BarStatus: 1, Ticks: 3, TotalVol: 42589, Time last quote: 06:46:32, Last: 1371.00
19-07_06:46:33 BarStatus: 1, Ticks: 3, TotalVol: 42589, Time last quote: 06:46:32, Last: 1371.00
(Note: The new bar started, in theory, on 6:46:00, 2 minute chart ES).

Code: Select all

Variables:
numDeci(DecimalsOfInstrument);

if (LastBarOnChart_s = True) then begin

once cleardebug;

Print(TimeNow, "BarStatus: ", NumToStr(BarStatus(1), 0),
", Ticks: ", NumToStr(Ticks, 0),
", TotalVol: ", NumToStr(Q_totalVolume, 0),
", Time last quote: ", FormatTime("HH:mm:ss", ELTimeToDateTime_s(q_time_s)),
", Last: ", NumToStr(Close, numDeci)
);

RecalcLastBarAfter(1);
end;
I don't know if it's a bug, since it seems to be designed that way. It wouldn't be a bad idea to have an option like: "Generate new bar after... [_] Time expires [_] New tick received (Default)" where the user can specify how he wants bar to be formed.

On which market(s) did you experience this Janus? I'd like to see if I can spot the same behaviour.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 19 Jul 2012

I don't know if it's a bug, since it seems to be designed that way. It wouldn't be a bad idea to have an option like: "Generate new bar after... [_] Time expires [_] New tick received (Default)" where the user can specify how he wants bar to be formed.
That's effectively what I'm now doing using my own code. I'm using a two second recacl time-out. I'm not generating a bar of course but at least any orders I need to submit can be done within a couple or so seconds from the end of a completed bar instead of 15+ seconds.
On which market(s) did you experience this Janus? I'd like to see if I can spot the same behaviour.
I speak of the Sydney Futures ASX200 contract, currently symbol APU2.

User avatar
JoshM
Posts: 2195
Joined: 20 May 2011
Location: The Netherlands
Has thanked: 1542 times
Been thanked: 1565 times
Contact:

Re: closing status of a bar sometimes takes too long

Postby JoshM » 19 Jul 2012

I speak of the Sydney Futures ASX200 contract, currently symbol APU2.
I couldn't see you problem/bug, it seems to me that new bars are formed just like it should be expected - when a new tick is incoming. Perhaps the relative 'slowness' of this instrument only makes the default behaviour more apparent.

I think this is more a feature request then a problem or bug (you certainly have my vote for such a feature request :) ).
Attachments
spiOutput.txt
(170.92 KiB) Downloaded 807 times

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 19 Jul 2012

it seems to me that new bars are formed just like it should be expected - when a new tick is incoming. Perhaps the relative 'slowness' of this instrument only makes the default behaviour more apparent.
That's my point. If there's no tick at or soon after the end of bar time, there's no way the study knows the bar is complete without writing some extra code. I would have thought any trading platform would automatically announce when the bar is determined to be complete within a very short time after the expected time, with say 1-2 seconds of wait time to make sure any delayed ticks are captured. There is no need to wait for the next tick, which can be a long time after. To be honest, I wouldn't even bother waiting for any time. I would prefer MC closed off a bar at the expected time regardless of any delayed ticks. It would avoid delays in submitting orders. The precision of the ticks coming through is not that good anyway, especially with IB's faking of the real-time feed. Anyway, my solution is working fine. I simply check the computer's time and issue any orders regardless of whether barstatus = 2 or not. BTW, yes I'm using a time synch tool to make sure the PC's time is accurate.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 19 Jul 2012

Janus, what is the resolution and chart type of the chart you are using?

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 19 Jul 2012

Janus, what is the resolution and chart type of the chart you are using?
Resolution is 1 minute and chart type is standard candle stick.

About three years ago I touched on this issue with tech support. Here is the response:
The 3 seconds wait is necessary because quite often data providers send ticks with delays. According to our tests on eSignal which is a very good provider, delays of 1.5 seconds are quite frequent. In other words, without the waiting time, ticks that, according to their timestamps, should be included into the current bar arrive 1.5 seconds late. Moreover, on some feeds the delay is even longer. Without the timeout, many ticks would be simply cut off and not included into the bar they belong to.
I hope the above provides a sufficient explanation as to why we wait 3 seconds before closing a bar.
When I read that reply I assumed ever since that MC closes a bar about 3 seconds after the expected end of the interval by signalling the study with barstatus = 2. From the observations by JoshM and my own it appears I misinterpreted the explanation. I now understand more accurately what is going on and I have no other option but to workaround it the way I described earlier. If it weren't for the relatively new keyword called RecalcLastBarAfter my workaround would not be possible, so again I thank you for providing that feature to force a study to run without waiting for an update tick.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 20 Jul 2012

Resolution is 1 minute and chart type is standard candle stick.
Time-based bars (Second, Minute, Hour, Day) are forced to close after the bar interval is exceeded + Timeout (300 seconds by default), or session close + Timeout (300 seconds by default).

Time-based bars (2 Day and higher, Week, Month, Quarter) are forced to close after the bar interval is exceeded + Timeout (300 seconds by default).

All other bars (TickBar, Contract, Point, Point (Original), Change) are forced to close at session close + Timeout (300 seconds by default).

If session consists of multiple time intervals the bars are forced to close at each close of session interval + Timeout (300 seconds by default).

To adjust the timeout for the bar close the following registry key can be used (time is specified in seconds):
HKEY_CURRENT_USER\Software\TS Support\ your MultiCharts product \Shaper\CloseBarTimeout

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 21 Jul 2012

To adjust the timeout for the bar close the following registry key can be used (time is specified in seconds):
HKEY_CURRENT_USER\Software\TS Support\MultiCharts\Shaper\CloseBarTimeout
Thanks Henry, that's very useful information. A default timeout of 300 seconds explains what I'm observing. I'll change it to 1 second or perhaps even 0 seconds and see what happens. I presume during very quiet periods when there are no update ticks for several minutes (happens overnight but still very rarely) I will see dashes on my chart every 1 minute thus distorting certain indicators unnecessarily. It doesn't really matter since I don't trade during those times anyway. I'm more interested in trading during the more liquid day sessions and seeing each 1 minute bar closed preciously at the end of each 1 minute interval regardless of whether there are any update ticks or not at those times. That's how any charting package should work, and most do. The assumption that there is a high enough frequency of update ticks all the time even during the day sessions to allow for a timeout more than say a second is not only wrong but also very dangerous, at least with most data feeds today over high speed internet connections.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 24 Jul 2012

As it turns out reducing the CloseBarTimeout from 300 to 2 seconds has uncovered another bug in MC. When there are no update ticks for 2 seconds after a bar is expected to close on a 1-minute chart, it is closed and barstatus returns a value of 2. On subsequent recalcs barstatus returns a value of -1 instead of 1 every 1 second (RecalcLastBarAfter set to 1) until the next update tick arrives making barstatus = 0, then 1 for subsequent update ticks or recalc timeouts until the bar is closed and the whole process repeats. During that period from the official end of bar to the first update tick of the new bar (not inclusive) any orders that are submitted are completely ignored (when barstatus = -1).

Now, this may be fine if all one is interested in is to submit orders when the bar is officially closed (barstatus = 2) but unfortunately it's not that simple for me. In my study I actually delay another 2 seconds after I detect barstatus = 2 before submitting any orders. The reason I do this is I need to wait for other studies that are applied on other charts to complete their work and retrieve information using global variables.

I now have two options. One is to go back to having CloseBarTimeout set to 300 seconds and my previous solution where I have created my own end of bar flag equivalent to barstatus = 2 based on the computer's time. At least that way when there are no update ticks and RecalcLastBarAfter is set to 1, barstatus returns 1 every second all the time and I can submit orders 2 seconds after I have detected the official end of bar. The other option, which I ways had in the back of my mind to do, is to stop using global variables and perform all my necessary computations in the main study. Then I can submit any orders immediately barstatus returns 2 with CloseBarTimeout set to say 2 seconds. The bonus here is my orders are at most 2 seconds and not 4 seconds later than the expected end of a bar. The downside is the computations on the other charts are performed on different time frames so I would have to plot numerous dataseries (and make them invisible). It becomes too painful doing it this way as I have lots of them. It would be so much easier and simpler if we could access directly dataseries of different timeframes within the one study without plotting them. I'm not sure any other package can do this but it would be a welcome enhancement.

On reflection, it's really odd one has to go through such workarounds just to make sure one can submit orders at any time based on information gathered from other charts. I can see some enhancements are necessary for MC to make it a truly modular multi-study as well as a multi-charting trading package. Perhaps the .NET version is better for this.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 25 Jul 2012

That is expected that barstatus will return "-1" when RecalcLastBarAfter triggers recalculation on the bar that does not exist.
Attachments
screenshot-1.jpg
(174.69 KiB) Downloaded 5341 times

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 25 Jul 2012

That is expected that barstatus will return "-1" when RecalcLastBarAfter triggers recalculation on the bar that does not exist.
That's odd, I get a completely different result. Besides, the whole point of using RecalcLastBarAfter is to kick start a strategy to make computations and if required submit orders. I've been doing this for some time now. When it happens for me barstatus = 1. If it weren't the case, RecalcLastBarAfter would be totally useless to me. Barstatus returns -1 under the circumstances I've outlined. I've also noticed it happens with CloseBarTimeout set to the default 300 seconds when the market is dead quiet for longer than that period. As long as there is at least one update tick within 300 seconds of the previous one, barstatus returns 1, not -1 with RecalcLastBarAfter timing out. If you don't believe me I can provide proof. I've carried out a lot of tests on this issue and I know I'm right. I just checked again before posting this reply. So, I don't know what you are doing to get the result you obtained. My tests applied to signal studies, not indicators. That's one difference.

Another difference is I'm focusing on the few seconds immediately past the expected end of a 1-minute bar, not the absence of a complete 1-minute bar as you indicate on your plot. In other words, I'm focusing intrabar and I need to submit any orders within that very small time window even if there are no update ticks. RecalcLastBarAfter works well for me in that regard, provided CloseBarTimeout is set greater than that window, which it is by default.

In any case, why can't orders be submitted when barstatus = -1? If orders were allowed at such times, we wouldn't be having this discussion in the first place.

Triage
Posts: 28
Joined: 12 Mar 2012
Has thanked: 2 times
Been thanked: 3 times

Re: closing status of a bar sometimes takes too long

Postby Triage » 26 Jul 2012

I can confirm that we also experience what janus has. We see the exact same thing.
That is expected that barstatus will return "-1" when RecalcLastBarAfter triggers recalculation on the bar that does not exist.
That's odd, I get a completely different result. Besides, the whole point of using RecalcLastBarAfter is to kick start a strategy to make computations and if required submit orders. I've been doing this for some time now. When it happens for me barstatus = 1. If it weren't the case, RecalcLastBarAfter would be totally useless to me. Barstatus returns -1 under the circumstances I've outlined. I've also noticed it happens with CloseBarTimeout set to the default 300 seconds when the market is dead quiet for longer than that period. As long as there is at least one update tick within 300 seconds of the previous one, barstatus returns 1, not -1 with RecalcLastBarAfter timing out. If you don't believe me I can provide proof. I've carried out a lot of tests on this issue and I know I'm right. I just checked again before posting this reply. So, I don't know what you are doing to get the result you obtained. My tests applied to signal studies, not indicators. That's one difference.

Another difference is I'm focusing on the few seconds immediately past the expected end of a 1-minute bar, not the absence of a complete 1-minute bar as you indicate on your plot. In other words, I'm focusing intrabar and I need to submit any orders within that very small time window even if there are no update ticks. RecalcLastBarAfter works well for me in that regard, provided CloseBarTimeout is set greater than that window, which it is by default.

In any case, why can't orders be submitted when barstatus = -1? If orders were allowed at such times, we wouldn't be having this discussion in the first place.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 27 Jul 2012

Janus, I am not sure that we are at the same page. Probably my reply was not clear enough.
"When there are no update ticks for 2 seconds after a bar is expected to close on a 1-minute chart, it is closed and barstatus returns a value of 2. On subsequent recalcs barstatus returns a value of -1 instead of 1 every 1 second (RecalcLastBarAfter set to 1) until the next update tick arrives making barstatus = 0, then 1 for subsequent update ticks or recalc timeouts until the bar is closed and the whole process repeats. During that period from the official end of bar to the first update tick of the new bar (not inclusive) any orders that are submitted are completely ignored (when barstatus = -1)."
Everything you have mentioned above is correct.
In any case, why can't orders be submitted when barstatus = -1?
Orders cannot be sent when barstatus = -1 by design due to security reasons.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 27 Jul 2012

Perhaps the screenshot here will help. The yellow bars and lines are hand drawn, and denote when there was no tick update for 1 minute or more (chart is set to display empty periods). The indicator is drawn using the study which is here also. As you can see barstatus = -1 only when there is a long enough period of no activity (ie, greater than CloseBarTimeout).

Code: Select all

variables:
intrabarpersist hold(False);

value1 = barstatus;
if value1 = -1 then begin // barstatus = -1
plot1(value1);
hold = True; // do not update the indicator for the rest of this bar
print ("barstatus = -1, time_s = ",time_s:0:0);
end else if not hold then begin // barstatus = 0,1,2
plot1(value1);
end;
if barstatus = 2 then hold = false;
RecalcLastBarAfter(1); // recalc after 1 second if no update ticks are received
Attachments
barstatus.png
(20.08 KiB) Downloaded 5315 times
Last edited by janus on 01 Aug 2012, edited 1 time in total.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 01 Aug 2012

I apologize for misinformation. I have edited my last post.

Whether the order would be sent or not is determined by the BarStatus.

If Barstatus = 0, 1, 2 – the orders would be sent even if there are no new ticks, RecalcLastBarAfter is used for that.

If Barstatus = -1 – the orders cannot be sent during this “in-between” bar status, even with RecalcLastBarAfter. Only PlaceMarketOrder can be used in such situation. That is expected behavior.

CloseBarTimeOut – is the time interval after which the BarStatus changes from 1 to 2, if there is no opening tick of the new bar, then an order can be sent during this interval (using RecalcLastBarAfter). If the interval is too short, for ex. 0 or 2, then the bar will be closed almost immediately and bar status becomes = 2.

If RecalcLastBarAfter is not used, then the BarStatus is as the following: 0 - the opening tick of the bar, 1 - the tick is within the bar, 2 - the closing tick of the bar. Then the cycle is repeated.
If RecalcLastBarAfter is used, the BarStatus is as the following: 0, 1, 2, if there is no new opening tick of the bar, then BarStatus becomes -1 after the specified timeout RecalcLastBarAfter( N ).

I understand your frustration but trading is forbidden with barstatus=-1 due to security reasons (it is causing unexpected behavour using PowerLanguage).

What we can recommend in your situation is to increase the CloseBarTimeOut (from 0 or 2 seconds you have mentioned) in order to have barstatus=1 when there are no new ticks on the chart.
You can also use PlaceMarketOrder command in your code.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 01 Aug 2012

I understand your frustration but trading is forbidden with barstatus=-1 due to security reasons (it is causing unexpected behavour using PowerLanguage).

What we can recommend in your situation is to increase the CloseBarTimeOut (from 0 or 2 seconds you have mentioned) in order to have barstatus=1 when there are no new ticks on the chart.
You can also use PlaceMarketOrder command in your code.
Thanks Henry for the correction. I too have edited my earlier response to be in sync. For the reasons I mentioned earlier, your recommendation only makes the situation worse as it prevents me submitting orders as frequently. At the moment I am reasonably satisfied with CloseBarTimeOut set to 300 seconds because I avoid trading during very quiet times. If I ever have to close positions during such times I'll just have to take the risk I will get a bad fill. Hopefully it doesn't happen too often. As for your explanation why orders are not allowed when barstatus = - 1 for security reasons (it is causing unexpected behavour using PowerLanguage) I'm sorry but that's not good enough, especially since you allow orders to be submitted using PlaceMarketOrder. A more likely reason is it's too difficult to make the change in MC. That's understandable. However, it would be nice one day to make the change in any case as a trader needs to have the assurance an order can be submitted at any time regardless of the trading activity without resorting to workarounds such as PlaceMarketOrder, which only makes the coding more complicated than necessary. Out of interest does the .NET version of MC have the same issue?

Triage
Posts: 28
Joined: 12 Mar 2012
Has thanked: 2 times
Been thanked: 3 times

Re: closing status of a bar sometimes takes too long

Postby Triage » 01 Aug 2012

Would there ever be a situation where RecalcLastBarAfter is triggered at the same time a new tick comes in? A new tick always overrides the RecalcLastBarAfter barstatus?
I apologize for misinformation. I have edited my last post.

Whether the order would be sent or not is determined by the BarStatus.

If Barstatus = 0, 1, 2 – the orders would be sent even if there are no new ticks, RecalcLastBarAfter is used for that.

If Barstatus = -1 – the orders cannot be sent during this “in-between” bar status, even with RecalcLastBarAfter. Only PlaceMarketOrder can be used in such situation. That is expected behavior.

CloseBarTimeOut – is the time interval after which the BarStatus changes from 1 to 2, if there is no opening tick of the new bar, then an order can be sent during this interval (using RecalcLastBarAfter). If the interval is too short, for ex. 0 or 2, then the bar will be closed almost immediately and bar status becomes = 2.

If RecalcLastBarAfter is not used, then the BarStatus is as the following: 0 - the opening tick of the bar, 1 - the tick is within the bar, 2 - the closing tick of the bar. Then the cycle is repeated.
If RecalcLastBarAfter is used, the BarStatus is as the following: 0, 1, 2, if there is no new opening tick of the bar, then BarStatus becomes -1 after the specified timeout RecalcLastBarAfter( N ).

I understand your frustration but trading is forbidden with barstatus=-1 due to security reasons (it is causing unexpected behavour using PowerLanguage).

What we can recommend in your situation is to increase the CloseBarTimeOut (from 0 or 2 seconds you have mentioned) in order to have barstatus=1 when there are no new ticks on the chart.
You can also use PlaceMarketOrder command in your code.

User avatar
TJ
Posts: 7739
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1032 times
Been thanked: 2221 times

Re: closing status of a bar sometimes takes too long

Postby TJ » 01 Aug 2012

Would there ever be a situation where RecalcLastBarAfter is triggered at the same time a new tick comes in? A new tick always overrides the RecalcLastBarAfter barstatus?
...
Computers are serial processors. Nothing ever happens at the same time, either one has to precede the other.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 01 Aug 2012

Would there ever be a situation where RecalcLastBarAfter is triggered at the same time a new tick comes in? A new tick always overrides the RecalcLastBarAfter barstatus?
...
Computers are serial processors. Nothing ever happens at the same time, either one has to precede the other.
Strictly speaking computers can perform parallel operations at the same time to handle events that also occur at the same time. That's why we often need some way to avoid clashes and deadlock events, such as critical sections, mutexes and the like in multi-threaded and mutli-core written applications. I do it all the time in my DLLs. Depending on how MC is written, it's possible for Triage's scenario to come about, but I presume if that's so MC applies the means necessary to avoid any consequential clash or deadlock in like manner. So, such a scenario would not present a problem, and be treated as though the events were not coincident in the first place even though they were.

Triage
Posts: 28
Joined: 12 Mar 2012
Has thanked: 2 times
Been thanked: 3 times

Re: closing status of a bar sometimes takes too long

Postby Triage » 10 Aug 2012

If RecalcLastBarAfter time interval coincides at the same time a bar opens or closes, can the recalc affect the barstatus of the natural bar open or close?
Would there ever be a situation where RecalcLastBarAfter is triggered at the same time a new tick comes in? A new tick always overrides the RecalcLastBarAfter barstatus?
...
Computers are serial processors. Nothing ever happens at the same time, either one has to precede the other.
Strictly speaking computers can perform parallel operations at the same time to handle events that also occur at the same time. That's why we often need some way to avoid clashes and deadlock events, such as critical sections, mutexes and the like in multi-threaded and mutli-core written applications. I do it all the time in my DLLs. Depending on how MC is written, it's possible for Triage's scenario to come about, but I presume if that's so MC applies the means necessary to avoid any consequential clash or deadlock in like manner. So, such a scenario would not present a problem, and be treated as though the events were not coincident in the first place even though they were.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 103 times

Re: closing status of a bar sometimes takes too long

Postby janus » 10 Aug 2012

If RecalcLastBarAfter time interval coincides at the same time a bar opens or closes, can the recalc affect the barstatus of the natural bar open or close?
If as I said MC is written such that precautions are taken to avoid clashes (in this case updating the barstatus value) then any such coincidence will be "separated". If the RecalcLastBarAfter section of the code hits the clash avoidance mechanism (ie, locks out any other code updating barstatus) first then barstatus is updated before the actual open or close updates barstatus. If the code that determines when a bar is open or close hits the clash avoidance mechanism first then it will be updated before RecalcLastBarAfter updates it. It's pretty much hit and miss as to what the sequence of events ends up being.

Triage
Posts: 28
Joined: 12 Mar 2012
Has thanked: 2 times
Been thanked: 3 times

Re: closing status of a bar sometimes takes too long

Postby Triage » 10 Aug 2012

Well that does explain a lot. Janus thanks for the explanation. Not sure I'm better off for knowing :-)

If using RecalcLastBarAfter, then it is difficult to know what sequence of events will happen if the same signal has both IOG related code, and also code that should be governed non-intrabar (controlled by barstatus).

I guess the best way is to separate IOG + RecalcLastBarAfter code in one signal, and have all your non-IOG code in another signal.

But even here, I'm still not quite sure what sequence of events to expect. If mixing IOG and non-IOG signal types in a single chart, what is to be expected? Will RecalcLastBarAfter from one signal trigger clash avoidance in another signal running in the same chart?
If RecalcLastBarAfter time interval coincides at the same time a bar opens or closes, can the recalc affect the barstatus of the natural bar open or close?
If as I said MC is written such that precautions are taken to avoid clashes (in this case updating the barstatus value) then any such coincidence will be "separated". If the RecalcLastBarAfter section of the code hits the clash avoidance mechanism (ie, locks out any other code updating barstatus) first then barstatus is updated before the actual open or close updates barstatus. If the code that determines when a bar is open or close hits the clash avoidance mechanism first then it will be updated before RecalcLastBarAfter updates it. It's pretty much hit and miss as to what the sequence of events ends up being.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: closing status of a bar sometimes takes too long

Postby waveslider » 20 Mar 2013

Please advise the best course of action:

I want to send an order EXACTLY (to the second) as a minute bar ends.

This is the only way to match historical testing.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 21 Mar 2013

Hello waveslider,

The closing tick of the bar is determined by the opening tick of the next bar. So there is no 100% solution to send an order exactly on the closing tick of the bar, but you can get close to it. Here is what I can suggest:
Enable IOG for your signal. Start Recalculating your code two seconds before the bar close. On the next calculation or next tick (depending on the market activity) send the order you need. Example for closing a position:

Code: Select all

[intrabarordergeneration = true]
input: TimeClosePosition(0);
if (currenttime_s >= TimeClosePosition) then
Begin
RecalcLastBarAfter(1);
sell ("EOD_LX") next bar market;
buytocover("EOD_SX") next bar market;
End;
As an input you need to specify the time when you need to close the position, for example 152958 – is 15:29:58.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: closing status of a bar sometimes takes too long

Postby waveslider » 15 Apr 2013

Hi Henry -
This solution did not work for me. I can't say why and it would take some time to decipher the reason.
I am trading only the S&P emini - a very liquid market. You said that the code would recalc and issue orders on the opening tick of the following bar, with this market there is normally zero delay since it is so liquid.
Is there someway to override the logic Multicharts has built into the platform and have bars close according to the clock on the computer?

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 16 Apr 2013

Hi Henry -
This solution did not work for me. I can't say why and it would take some time to decipher the reason.
I am trading only the S&P emini - a very liquid market. You said that the code would recalc and issue orders on the opening tick of the following bar, with this market there is normally zero delay since it is so liquid.
Is there someway to override the logic Multicharts has built into the platform and have bars close according to the clock on the computer?
MultiCharts already uses the PC clock for bar close. Please refer to my post above to learn how bar close rules work. You can also adjust the timeout.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: closing status of a bar sometimes takes too long

Postby waveslider » 16 Apr 2013

Thanks Henry -
I missed that post.

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: closing status of a bar sometimes takes too long

Postby hilbert » 08 Nov 2014

As it turns out reducing the CloseBarTimeout from 300 to 2 seconds has uncovered another bug in MC. When there are no update ticks for 2 seconds after a bar is expected to close on a 1-minute chart, it is closed and barstatus returns a value of 2. On subsequent recalcs barstatus returns a value of -1 instead of 1 every 1 second (RecalcLastBarAfter set to 1) until the next update tick arrives making barstatus = 0, then 1 for subsequent update ticks or recalc timeouts until the bar is closed and the whole process repeats. During that period from the official end of bar to the first update tick of the new bar (not inclusive) any orders that are submitted are completely ignored (when barstatus = -1).
A new keyword AllowSendOrdersAlways has been introduced in MC9. Typing [AllowSendOrdersAlways=true] in powerlanguage code allows sending of orders even when barstatus = -1, thereby solving this problem.

So, If you want to send an order immediately after bar close,
1) Go to registry HKEY_CURRENT_USER\Software\TS Support\MultiCharts\Shaper\CloseBarTimeout
2) modify the registry value for CloseBarTimeout to 2 seconds from 300 seconds which is default,
3) use RecalcLastBarAfter(1) and [AllowSendOrderAlways=True] in your code.

Your order will get sent to your broker on Recalculation, even without a tick in the market, after 3 seconds of the bar close.

Solves a lot of problems. Thanks MC Team :)

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 10 Nov 2014

hilbert, that is also required to have IOG=ON.

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: closing status of a bar sometimes takes too long

Postby orion » 17 Jan 2015

Some barStatus questions:

1. According to thread above, recalculate due to recalcLastBarAfter() can result in barStatus = 0, 1, 2, or -1 depending on when the recalculate event arrived. Should we assume same applies to recalculate due to broker events for auto trading setting of recalculate on 'Market position change' or 'Order filled'?

2. Is it guaranteed that barStatus = 2 will occur once and only once for each bar? Some of my code relies on this. If this is not the case, then it can be coded around; not a big deal but please advise.

3. With multiresolution price data where all time series are aligned, is it guaranteed that all time series will see barStatus = 2 on same calculation? [What is meant by 'aligned' is time series such as 1 minute, 5 minute, and 60 minute. They are aligned since 60 is a multiple of 5 which is a multiple of 1 whereas if you have 1 minute, 3 minute, and 10 minute data then they are not aligned.] So if a chart has data1 (1 minute), data2 (5 minute), data3 (60 minute) for same symbol, it will always be the case that when barStatus(3) = 2, we also have barStatus(2) = 2 and barStatus(1) = 2?

Thanks.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 26 Jan 2015

Some barStatus questions:
1. According to thread above, recalculate due to recalcLastBarAfter() can result in barStatus = 0, 1, 2, or -1 depending on when the recalculate event arrived. Should we assume same applies to recalculate due to broker events for auto trading setting of recalculate on 'Market position change' or 'Order filled'?
That is correct. You can use GetAppInfo(aiCalcReason) to return the reason of the calculation.
2. Is it guaranteed that barStatus = 2 will occur once and only once for each bar? Some of my code relies on this.
Yes.
3. With multiresolution price data where all time series are aligned, is it guaranteed that all time series will see barStatus = 2 on same calculation? [What is meant by 'aligned' is time series such as 1 minute, 5 minute, and 60 minute. They are aligned since 60 is a multiple of 5 which is a multiple of 1 whereas if you have 1 minute, 3 minute, and 10 minute data then they are not aligned.] So if a chart has data1 (1 minute), data2 (5 minute), data3 (60 minute) for same symbol, it will always be the case that when barStatus(3) = 2, we also have barStatus(2) = 2 and barStatus(1) = 2?
For the same symbol - yes, for different instruments barStatus can be different.

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: closing status of a bar sometimes takes too long

Postby orion » 26 Jan 2015

Some barStatus questions:
1. According to thread above, recalculate due to recalcLastBarAfter() can result in barStatus = 0, 1, 2, or -1 depending on when the recalculate event arrived. Should we assume same applies to recalculate due to broker events for auto trading setting of recalculate on 'Market position change' or 'Order filled'?
That is correct. You can use GetAppInfo(aiCalcReason) to return the reason of the calculation.
2. Is it guaranteed that barStatus = 2 will occur once and only once for each bar? Some of my code relies on this.
Yes.
Henry, thanks for the reply. I think the two answers above both can't be right. So let me state in more detail my understanding of how things work and you can correct me if I am wrong.

1. We have following cases for barStatus on recalculation:
(a) if barStatus = 0 on previous calculation, then on recalculation event barStatus = 0
(b) if barStatus = 1 on previous calculation, then on recalculation event barStatus = 1
(c) if barStatus = 2 on previous calculation then there are two cases:
(c)(i) previous calculation barStatus = 2 was due to CloseBarTimeOut and so following recalculation event will have barStatus = -1
(c)(ii) previous calculation barStatus = 2 was due to close of last bar based on arrival of tick for new bar, which means we will have barStatus = 0 (new tick) event before the recalculation event which will now happen with barStatus = 0. Is this correct?

2. So barStatus = 2 can never happen on a recalculation. Hence the guarantee that barStatus = 2 occurs only once on a bar. Correct?

3. You pointed me to GetAppInfo(aiCalcReason) which returns the reason of the calculation. Per the documentation, besides the mouse events, this has only two other values (calclReason_default and calcReason_timer). I don't see values for recalculation due to market position change or order fills. It may be useful to have keywords calcReason_marketPosition and calcReason_orderFill if those can be easily provided?

Thanks.

User avatar
JoshM
Posts: 2195
Joined: 20 May 2011
Location: The Netherlands
Has thanked: 1542 times
Been thanked: 1565 times
Contact:

Re: closing status of a bar sometimes takes too long

Postby JoshM » 27 Jan 2015

3. You pointed me to GetAppInfo(aiCalcReason) which returns the reason of the calculation. Per the documentation, besides the mouse events, this has only two other values (calclReason_default and calcReason_timer). I don't see values for recalculation due to market position change or order fills. It may be useful to have keywords calcReason_marketPosition and calcReason_orderFill if those can be easily provided?
Those two keywords are available in the PowerLanguage Editor:

Image

I've already pointed out to MC Support that these were missing from the GetAppInfo wiki page, but was told these were already described in the help for MC .NET (miscommunication). So they should work as follows:

Image
Attachments
scr.27-01-2015 13.02.25.png
(9.41 KiB) Downloaded 5480 times
scr.06-01-2015 06.42.12.png
(3.71 KiB) Downloaded 5480 times

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: closing status of a bar sometimes takes too long

Postby orion » 27 Jan 2015

Thanks Josh. You get my votes for both the most helpful and the most knowledgeable on the forum.

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: closing status of a bar sometimes takes too long

Postby MAtricks » 27 Jan 2015

Thanks Josh. You get my votes for both the most helpful and the most knowledgeable on the forum.
Agreed :)

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 30 Jan 2015

1. We have following cases for barStatus on recalculation:
(a) if barStatus = 0 on previous calculation, then on recalculation event barStatus = 0
(b) if barStatus = 1 on previous calculation, then on recalculation event barStatus = 1
(c) if barStatus = 2 on previous calculation then there are two cases:
(c)(i) previous calculation barStatus = 2 was due to CloseBarTimeOut and so following recalculation event will have barStatus = -1
(c)(ii) previous calculation barStatus = 2 was due to close of last bar based on arrival of tick for new bar, which means we will have barStatus = 0 (new tick) event before the recalculation event which will now happen with barStatus = 0. Is this correct?
That is correct.
2. So barStatus = 2 can never happen on a recalculation. Hence the guarantee that barStatus = 2 occurs only once on a bar. Correct?
Yes.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: closing status of a bar sometimes takes too long

Postby Henry MultiСharts » 30 Jan 2015

3. You pointed me to GetAppInfo(aiCalcReason) which returns the reason of the calculation. Per the documentation, besides the mouse events, this has only two other values (calclReason_default and calcReason_timer). I don't see values for recalculation due to market position change or order fills. It may be useful to have keywords calcReason_marketPosition and calcReason_orderFill if those can be easily provided?
Those two keywords are available in the PowerLanguage Editor
I've already pointed out to MC Support that these were missing from the GetAppInfo wiki page, but was told these were already described in the help for MC .NET (miscommunication).
I have updated the description of GetAppInfo in the Wiki. The description in the PowerLanguage Editor will be updated in MultiCharts 9.0 Release 5.

zfsamzfsam
Posts: 9
Joined: 09 Aug 2014
Has thanked: 31 times
Been thanked: 3 times

Re: closing status of a bar sometimes takes too long

Postby zfsamzfsam » 16 Mar 2016

d) Or best way is to have a new advance SetExitOnClose(=>SetExitOnSession) which can handle all these issues once and for all. Please vote for it
http://www.multicharts.com/pm/viewissue ... no=MC-1521


This is just a small feature, but very useful!!!


Return to “MultiCharts”