Hi,
Two questions:
-Am I right in saying AllowSendOrdersAlways only works when intrabarordergeneration is on?
-Am I right in saying that if we've reached the timeout, where we can define the last tick received as the barstatus=2 tick (and the next tick never arrived before the timeout), that orders can be submitted on a recalclastbarafter event instead of the barstatus=0 tick, when not in IOG mode?
Thanks!
AllowSendOrdersAlways with intrabarorder generation OFF
- Kate MultiCharts
- Posts: 596
- Joined: 21 Oct 2020
- Has thanked: 9 times
- Been thanked: 148 times
Re: AllowSendOrdersAlways with intrabarorder generation OFF
Hello wilkinsw,
AllowSendOrdersAlways allows sending orders when the BarStatus = -1.
Even if the IOG is disabled, the BarStatus can be = -1.
BarStatus = 0 means that the bar is opened.
BarStatus = 1 indicates the calculation inside the bar.
BarStatus = 2 means that the bar is closed.
BarStatus = -1 means that the bar is closed, but the calculation is performed at the bar close.
That can happen if the chart does not receive real-time data, the last bar is closed and has BarStatus = 2, but in the code the calculation is being performed, for example, due to an event caused by RecalcLastBarAfter. In that case all further calculations will take place with BarStatus = -1.
Barstatus can also be = -1 when you have several data series, the main one has a resolution larger than the secondary ones, and Realtime-History Matching is enabled. In that case the calculations are performed on the second data series and have Barstatus = -1 .
The bar can be closed, but you can force the calculation using the RecalcLastBarAfter keyword. The Barstatus will be = -1. To send orders you can enable the AllowSendOrdersAlways = true attribute.
AllowSendOrdersAlways allows sending orders when the BarStatus = -1.
Even if the IOG is disabled, the BarStatus can be = -1.
BarStatus = 0 means that the bar is opened.
BarStatus = 1 indicates the calculation inside the bar.
BarStatus = 2 means that the bar is closed.
BarStatus = -1 means that the bar is closed, but the calculation is performed at the bar close.
That can happen if the chart does not receive real-time data, the last bar is closed and has BarStatus = 2, but in the code the calculation is being performed, for example, due to an event caused by RecalcLastBarAfter. In that case all further calculations will take place with BarStatus = -1.
Barstatus can also be = -1 when you have several data series, the main one has a resolution larger than the secondary ones, and Realtime-History Matching is enabled. In that case the calculations are performed on the second data series and have Barstatus = -1 .
The bar can be closed, but you can force the calculation using the RecalcLastBarAfter keyword. The Barstatus will be = -1. To send orders you can enable the AllowSendOrdersAlways = true attribute.
Re: AllowSendOrdersAlways with intrabarorder generation OFF
So coming back to my question:
-Am I right in saying AllowSendOrdersAlways only works when IOG is on?
Assume that I already know what barstatus means......
Technically, default, non-IOG behaviour results in order submission on the first calculation that follows barstatus=2. Let's call this the "order submission event".
The order submission event doesn't happen if the first calculation to follow barstatus=2 is a barstatus=-1 event. Correct? Or Wrong?
If correct... default, non-IOG behaviour means that order submission only happens on barstatus=0 and barstatus=1 events? Correct? Or Wrong?
I just want to know if AllowSendOrdersAlways only works when IOG is on and if so why that is.
Thanks.
-Am I right in saying AllowSendOrdersAlways only works when IOG is on?
Assume that I already know what barstatus means......
Technically, default, non-IOG behaviour results in order submission on the first calculation that follows barstatus=2. Let's call this the "order submission event".
The order submission event doesn't happen if the first calculation to follow barstatus=2 is a barstatus=-1 event. Correct? Or Wrong?
If correct... default, non-IOG behaviour means that order submission only happens on barstatus=0 and barstatus=1 events? Correct? Or Wrong?
I just want to know if AllowSendOrdersAlways only works when IOG is on and if so why that is.
Thanks.
Re: AllowSendOrdersAlways with intrabarorder generation OFF
Barstatus can also be = -1 when you have several data series, the main one has a resolution larger than the secondary ones, and Realtime-History Matching is enabled. In that case the calculations are performed on the second data series and have Barstatus = -1 .
Ken,
What do you mean by secondary ones? Are you saying that if data 1 is the larger resolution as in say 5 minutes and data 2 etc.....are less such as 1 minute or are you implying the other way around. Could you clarify the language referencing specific data series numbers and time resolutions?
My experience has been that AllowSendOrdersAlways will only function with IOG=on as this is specifically is outside of the Barstatus = 2 event. I might be crazy though!
GuppyDRV
Ken,
What do you mean by secondary ones? Are you saying that if data 1 is the larger resolution as in say 5 minutes and data 2 etc.....are less such as 1 minute or are you implying the other way around. Could you clarify the language referencing specific data series numbers and time resolutions?
My experience has been that AllowSendOrdersAlways will only function with IOG=on as this is specifically is outside of the Barstatus = 2 event. I might be crazy though!
GuppyDRV
Re: AllowSendOrdersAlways with intrabarorder generation OFF
Sorry for the double post but after thinking on it I had another question.
When using the Barstatus (1) = 2 how is this calculated? By this I mean if I use the following code.
Will this produce a result for BS1 on every tick or do I need this.
What if I just use this in a statement. Will this update Barstatus with each incoming tick?
Just wondering how this would effect finding a Barstatus = -1 if it’s not updating on every tick regardless of intrabarpersist status.
GuppyDRV
When using the Barstatus (1) = 2 how is this calculated? By this I mean if I use the following code.
Code: Select all
Vars: BS1 (0);
BS1 = Barstatus (1) = 2;
Code: Select all
Vars: intrabarpersist BS1 (0);
BS1 = Barstatus (1) = 2;
Code: Select all
If Barstatus (1)=2 then begin
“Do something”
End;
GuppyDRV
Re: AllowSendOrdersAlways with intrabarorder generation OFF
But order submission doesn’t occur when barstatus=2, it happens on the next calculation.Barstatus can also be = -1 when you have several data series, the main one has a resolution larger than the secondary ones, and Realtime-History Matching is enabled. In that case the calculations are performed on the second data series and have Barstatus = -1 .
Ken,
What do you mean by secondary ones? Are you saying that if data 1 is the larger resolution as in say 5 minutes and data 2 etc.....are less such as 1 minute or are you implying the other way around. Could you clarify the language referencing specific data series numbers and time resolutions?
My experience has been that AllowSendOrdersAlways will only function with IOG=on as this is specifically is outside of the Barstatus = 2 event. I might be crazy though!
GuppyDRV
Re: AllowSendOrdersAlways with intrabarorder generation OFF
Your code doesn't make sense to me. Doesn't compile even. "BS1" would need to be declared as a True/False variable. Assuming you've done that and to answer your question.... you don't need intrabarpersist when you are asking upon every calculation what is barstatus(1). If you want to capture and remember the event intrabar, however, then yes you would need intrabarpersist. But since you are capturing a bartstatus(1)=2 event in the first place it will be remembered and indexed. So again, you don't need intrabarpersist.Sorry for the double post but after thinking on it I had another question.
When using the Barstatus (1) = 2 how is this calculated? By this I mean if I use the following code.
Will this produce a result for BS1 on every tick or do I need this.Code: Select all
Vars: BS1 (0); BS1 = Barstatus (1) = 2;
What if I just use this in a statement. Will this update Barstatus with each incoming tick?Code: Select all
Vars: intrabarpersist BS1 (0); BS1 = Barstatus (1) = 2;
Just wondering how this would effect finding a Barstatus = -1 if it’s not updating on every tick regardless of intrabarpersist status.Code: Select all
If Barstatus (1)=2 then begin “Do something” End;
GuppyDRV
It will update on every tick, even -1 events.Just wondering how this would effect finding a Barstatus = -1 if it’s not updating on every tick regardless of intrabarpersist status.
This is all in the Wiki and is easy to see when using the print statement.
Re: AllowSendOrdersAlways with intrabarorder generation OFF
The open of the next bar is Barstatus=0.I think I should say that it calculated on Barstatus = 2 with IOG = Off which would produce a trade open next bar or Barstatus = 1.
GuppyDRV
Re: AllowSendOrdersAlways with intrabarorder generation OFF
GuppyDRV, thanks for your help. Maybe consider starting a fresh thread?
Coming back to MC behaviour which I can't find in the wiki:
under default behaviour, on the calculation that locks in barstatus=2 (the calculation that occurs either on or after barstatus=0 or the timeout); orders are submitted in effect after barstatus=2. This is known.
My question is does default behaviour exclude barstatus=-1 submission; if a -1 event is the first event to occur after barstatus=2? Even with Allowsendorderalways=true?
If so, I think MC should consider making allowsendorderalways possible under non-IOG trading when specified in the code.
Thanks
Coming back to MC behaviour which I can't find in the wiki:
under default behaviour, on the calculation that locks in barstatus=2 (the calculation that occurs either on or after barstatus=0 or the timeout); orders are submitted in effect after barstatus=2. This is known.
My question is does default behaviour exclude barstatus=-1 submission; if a -1 event is the first event to occur after barstatus=2? Even with Allowsendorderalways=true?
If so, I think MC should consider making allowsendorderalways possible under non-IOG trading when specified in the code.
Thanks
Re: AllowSendOrdersAlways with intrabarorder generation OFF
I should probably have taken more time with the post. I appreciate any insight that you might have and always enjoy reading your posts.
The way I use it in my signal is as follows:
My understanding is that with IOG = True this will calculate on each new tick allowing Barstatus to be updated. With IOG = False it will only calculate on a bar close event or a coded recalcafter(n) event. If we have Intrabarpersist in our Variable section it will update with every tick allowing us to also see the Barstatus progression in the same fashion as having IOG = True but not allow us to send orders intrabar. If I'm understanding your response correctly I believe that you are saying that the Data1Close is updating on every tick regardless of IOG status?
My original, if poorly worded response, dealt with the multi data chart. I created a simple chart with three data series and a print statement that prints when Barstatus(3) = 2. All of them are 20 second charts using the 24/7 template. Just simple stuff with everything the same except that Data 1 is an Ask, Data 2 is a Bid and Data 3 is a trade. The following screen shot is the output. Notice that often times the Barstatus is different for all three but Data 3 trade is always 2. Why is this? If you were submitting orders with a -1 on any, would that happen without AllowSendOrdersAlways even though they are the same time series?? I'm really asking as I'm not sure....it's why I asked in your thread for a clarification.
Additionally, I have a question about the output of this setup. I would have expected the Close of Data 3 the trade series to be the same on any given close as either data 1 the ask series or data2 the bid series but its obviously not. Considering all ticks represent trades should the close of Data 3 not be concurrent with the close of either the ask or bid data series? I included the inside ask/inside bid just to see how they lined up with the other! I should add that I captured this in live market action.
When this setup is played back using tick-by-tick the ask/bid and the close always line up. Additionally, the Barstatus is always 2 for all three! This relates to my original question regarding multi data series and how Barstatus works as this would greatly influence backtest results.
Thanks as always for your help as well as any MC input that may follow.
GuppyDRV
The way I use it in my signal is as follows:
Code: Select all
Vars: Data1Close ( False ) ;
Data1Close = Barstatus(1) = 2 ;
if Data1Close and "other logic code" then begin
do something
end;
My original, if poorly worded response, dealt with the multi data chart. I created a simple chart with three data series and a print statement that prints when Barstatus(3) = 2. All of them are 20 second charts using the 24/7 template. Just simple stuff with everything the same except that Data 1 is an Ask, Data 2 is a Bid and Data 3 is a trade. The following screen shot is the output. Notice that often times the Barstatus is different for all three but Data 3 trade is always 2. Why is this? If you were submitting orders with a -1 on any, would that happen without AllowSendOrdersAlways even though they are the same time series?? I'm really asking as I'm not sure....it's why I asked in your thread for a clarification.
Additionally, I have a question about the output of this setup. I would have expected the Close of Data 3 the trade series to be the same on any given close as either data 1 the ask series or data2 the bid series but its obviously not. Considering all ticks represent trades should the close of Data 3 not be concurrent with the close of either the ask or bid data series? I included the inside ask/inside bid just to see how they lined up with the other! I should add that I captured this in live market action.
When this setup is played back using tick-by-tick the ask/bid and the close always line up. Additionally, the Barstatus is always 2 for all three! This relates to my original question regarding multi data series and how Barstatus works as this would greatly influence backtest results.
Thanks as always for your help as well as any MC input that may follow.
GuppyDRV
- Attachments
-
- 3 Data Series Output.PNG
- (56.25 KiB) Not downloaded yet