AllowSendOrdersAlways with intrabarorder generation OFF

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!

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.

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.

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

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

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

But order submission doesn’t occur when barstatus=2, it happens on the next calculation.

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

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.

Code: Select all

Vars: BS1 (0); BS1 = Barstatus (1) = 2;

Will this produce a result for BS1 on every tick or do I need this.

Code: Select all

Vars: intrabarpersist 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

If Barstatus (1)=2 then begin “Do something” End;

Just wondering how this would effect finding a Barstatus = -1 if it’s not updating on every tick regardless of intrabarpersist status.

GuppyDRV

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.

Just wondering how this would effect finding a Barstatus = -1 if it’s not updating on every tick regardless of intrabarpersist status.

It will update on every tick, even -1 events.

This is all in the Wiki and is easy to see when using the print statement.

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

The open of the next bar is Barstatus=0.

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

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