Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 18 May 2024 07:14:42 +0000
Chart replay - order ID returned from future?
View Count: 534
| [2021-09-03 15:22:40] |
| jwick - Posts: 142 |
|
Hi, I'm running a chart replay (Calculate at every tick, 45 second processing interval on a 3 minute chart, 200000 speed, All Charts in Chartbook. Charts reference each other and use different time based intervals (3 minute is the lowest)). On each bar, I am storing the InternalOrderID of any submitted order. In the attached screenshot, the 8 PM bar receives an InternalOrderID which isn't actually sent according to the trade log until 8:06 PM (two bars later). Why is this? Am I using too high of a processing interval? Thanks |
Private File |
| [2021-09-07 08:10:27] |
| Sierra_Chart Engineering - Posts: 14423 |
|
All we can say, if the custom study was able to access a particular order, it was definitively sent. What exactly is happening in your case is not within the scope of our support. You need to analyze this. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2021-09-07 11:37:20] |
| jwick - Posts: 142 |
|
hmm ... the answer might be the same as before, but have you ever encountered a situation where the internal order ID received is from a different chart? If you look at the attached screenshot, that is what I'm seeing (the NQ and ES charts have no references to each other). So weird! All the orders are sent with a BuyEntry or SellEntry function call.
Date Time Of Last Edit: 2021-09-07 11:38:03
|
Private File |
| [2021-09-07 12:29:11] |
| |
|
That order came from chart number #4 and the date of it is 2009-9-13. So that timestamp must have been encountered in that chart during the replay. Maybe there was an incorrect timestamp around that time. but have you ever encountered a situation where the internal order ID received is from a different chart? Certainly this is possible because a custom study can access all orders. How was that internal order ID obtained?
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2021-09-07 12:29:33
|
| [2021-09-07 14:09:54] |
| jwick - Posts: 142 |
|
Thanks for the reply. How was that internal order ID obtained?
Here is how I'm obtaining the internal order ID's: s_SCNewOrder order; order.InternalOrderID = 0; order.OrderType = SCT_ORDERTYPE_STOP; order.Price1 = price; order.OrderQuantity = (int)quantity; order.Price2 = price; order.TimeInForce = SCT_TIF_GTC; sc.BuyEntry(order); idEntry[sc.Index] = (float)order.InternalOrderID; |
| [2021-09-07 15:01:30] |
| jwick - Posts: 142 |
|
Arrrgghhhh I might? have figured it out ... I think the issue is with that last line ... For instance, when the InternalOrderID is 17557725, printing "%f", (float)order.InternalOrderID yields 17557724.000000! Which surprises me since I've been careful going from a float to an int in case of situations like .000001 or .99999 but an int to a float (assuming its not an overflow situation)? I'm not 100% sure this is the issue but I noticed this after adding various logging at different locations. Will keep investigating / confirm EDIT: If I test a simple print: "%d as int vs %f as float", 17557725, (float)17557725 ... indeed I get 17557725 and 17557724.000000. Looks like this explains why: https://stackoverflow.com/questions/28325738/why-does-a-cast-from-int-to-float-round-the-value. Would I be able to store InternalID's in subgraph arrays or do I have to use a persistent int / pointer? EDIT2: Yep looks like switching over to storing ID's in a persistent int fixed things. It would be nice to still be able to display internal order ID's in the chart values window but it's not too big of a deal since I know the actual order id might be a few ID's above / below what is displayed in a subgraph. Thanks Date Time Of Last Edit: 2021-09-07 18:56:48
|
To post a message in this thread, you need to log in with your Sierra Chart account: