Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Thu, 25 Apr 2024 15:46:59 +0000
[Locked] - Version 2151 Available: Foundation For Millisecond/Microsecond Timestamping
View Count: 12409
| [2020-08-20 21:57:42] |
| ejtrader - Posts: 688 |
|
SC Team - What are the new functions for the following (version 2154 was the last version supported these functions)? sc.AreTimeSpecificBars() sc.RenkoTicksPerBar Thanks |
| [2020-08-20 22:13:03] |
| Ackin - Posts: 1865 |
|
ejtrader) sc.AreTimeSpecificBars() Type: Function This ACSIL structure member is considered out of date/deprecated. Instead use the sc.GetBarPeriodParameters and sc.SetBarPeriodParameters functions. sc.RenkoTicksPerBar
ACSIL Interface Members - Variables and Arrays: sc.RenkoTicksPerBar
Type: Read/Write integer variable. This ACSIL structure member is considered out of date/deprecated. Instead use the sc.GetBarPeriodParameters and sc.SetBarPeriodParameters functions. Date Time Of Last Edit: 2020-08-20 22:19:00
|
| [2020-08-21 04:25:34] |
| Sierra_Chart Engineering - Posts: 14088 |
|
Yes post #51 is correct in regards to answering post #50.
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 Date Time Of Last Edit: 2020-08-21 04:25:42
|
| [2020-08-21 05:59:18] |
| User79074 - Posts: 105 |
|
I asked if you were done with code breaking changes in 2155 and you said yes. Now there is breakage once again in 2156. There needs to be a better system of communication for Sierra Chart users to know exactly what is going on. Especially since I am a vendor and people are writing me saying the indicators are broken after installing 2156, very frustrating and this has been consuming a lot of my time this week doing re compilations for my indicators every day.
|
| [2020-08-21 06:19:20] |
| Sierra_Chart Engineering - Posts: 14088 |
|
In regards to post #53, what is the problem? We are unaware of any change in 2156 which would cause a compatibility issue with custom studies compiled in 2155. There should be none and we are not observing anything ourselves. We need precise details. There is no change between 2155 and 2156 which would cause a compatibility issue with custom studies. The most likely explanation is that the users are using an ACSIL DLL which was not compiled with 2155 and they are running an older one. 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 Date Time Of Last Edit: 2020-08-21 06:36:41
|
| [2020-08-21 09:49:45] |
| Ackin - Posts: 1865 |
|
User79074: very frustrating and this has been consuming a lot of my time this week doing re compilations for my indicators every day.
Same experience as you and thanks for your words, I already felt like I was alone ...In this respect, a very simple thing would suffice, as it works in other software. That they release Update only once in a longer period and in the meantime beta versions are created which are available only for testers and programmers (registered users see separate new content of new updates in separate sections). This would eliminate cases where the Newcomer automatically downloads the last update and then requires the full functionality of everything. Or ... chaotic patches when a part of an already functioning feature falls out and is fixed in the next update. I worked for many years in a development company. Errors can occur in the update ... it is not always possible to test everything, but it is always possible to improve communication with "colleagues in the same area" or facilitate the work of those who rely on this information. Not only errors but also changes in code writing. Sierra_Chart Engineering: But 2151 or higher is needed to receive the microsecond timestamps.
Could you please post an opinion somewhere on the sierrachart forum for everyone what the change to milliseconds will bring? People trading live are worried about what will happen to their charts and settings in the trading session after this weekend.You don't write anywhere how the change will affect people who do not update to 2151 and higher. Will the axes in the charts change? Will DOM / T & S / QuoteBoard change? Problems and unexpected states cannot be solved while running in trade. You're an excellent trading platform, but in the press releases you keep things secret like the FBI. I write because of many Sierrachart traders with whom I am in contact every day. thanks |
| [2020-08-21 09:55:29] |
| |
|
: very frustrating and this has been consuming a lot of my time this week doing re compilations for my indicators every day. The changes were only during pre-releases. Not the main release. You could have also waited a few days, for the changes to be completed and become stable.If a user of your custom studies wanted to update to the prerelease and could not run your custom studies, that is not a problem. They should just simply live without the custom studies for a few days or go back to the main release. It was their choice to update to the prerelease. There is no consequence for them to having updated to the prerelease and roll back to the main release. People trading live are worried about what will happen to their charts and settings in the trading session after this weekend. There has not been anything said about this because there is nothing to be concerned with. There is no impact if the user does not update, and if they do update, there still is no impact. There is nothing for anyone to be concerned with.You don't write anywhere how the change will affect people who do not update to 2151 and higher. Will the axes in the charts change? Will DOM / T & S / QuoteBoard change? Problems and unexpected states cannot be solved while running in trade. And if nobody notices an impact now, then this proves as a matter of fact, that there will be no impact because we have been running for several days now with some of our systems already updated with the latest code to support microsecond time stamping. Our server processes are aware, of the supported messages from the DTC clients and only send out compatible messages. For example on one of our Denali data servers, for CBOT, the new microsecond time stamping is being transmitted. The same is true for our market statistics data, crypto currency data and Forex data. One of the systems has been updated for days now transmitting microsecond timestamps. ---- And we are also very happy, with how gracefully everything has worked, with next to zero problems. And the reason for this is that there has been extensive testing going on for more than a year now and lots of consideration of so many different things related to the time stamping change and a lot of updates to Sierra Chart over this time to make the transition very graceful with zero impact. 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: 2020-08-21 10:16:05
|
| [2020-08-21 10:14:28] |
| |
|
We may also decide that for the CME data, and all of the exchange feeds, that we may just simply support the native exchange microsecond time stamping, if available, rather than just the millisecond component. We will evaluate that over the next few days. Update: Our decision on this, is not to do this because it does increase the amount of bandwidth requirement for data transmission. Already millisecond time stamping is increasing the amount of bandwidth requirement. Not by much but a little. 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: 2020-08-21 10:19:35
|
| [2020-08-21 10:18:04] |
| |
|
The only issue that someone can face, which does create some extra effort and an issue them would require help/guidance from us is if they update to 2151 or higher and then go back to a version earlier than 2110. In this case they would need to re-download a portion of their historical Intraday data, and go back to backup Chartbook files and a backup of the main configuration file. The thing to keep in mind is that there are automatic backups made, and the historical Intraday data is readily available to be re-downloaded. 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: 2020-08-21 10:18:23
|
| [2020-08-21 10:22:48] |
| BlakJak - Posts: 108 |
|
Thanks for working on this. It is working perfectly for me and I have been waiting for the millisec timestamping to update some of my orderflow studies which currently use computer timestamps (not so successfully). I am glad it is done.
|
| [2020-08-23 18:16:10] |
| BrMa - Posts: 77 |
|
Dear Sierra Chart Engineering, first of all thank you for the update and the intended increase in precision out of a timing perspective. I worked through it today and adapted my code. When doing this I approached three minor topics I'd like to address here and ask you for updates: 1) In my code I'm using sc.GetEndingDateTimeForBarIndex() which returns a double value representing the ending Date-Time of a chart bar specified by its bar index. Isn't that inconsistent? From my point of view the interface should return a consistent data-type representing date/time information - whatever you decide to go for. sc.GetTradingDayStartDateTimeOfBarForChart() is affected as well. For the time being I'm passing the double value returned to the SCDateTimeMS()-constructor which seems to me to be a multiple convert SCDateTime (I guess used internally) -> double -> SCDateTimeMS!? scdatetime.h says SCDateTimeMS is derived from SCDateTime - just adapted methods for SCDateTimeMS... so it would be much more efficient to have the "original" data-type for further processing... 2) In post #43 you mentioned that the following text string members are now changed to functions but documentation lacks information or is at the wrong place: SCString sc.VersionNumber();
Marked as type function but still in the secion Variables and Arrays - not FunctionsSCString sc.UserName();
Marked as Read-only Character string and still in the secion Variables and Arrays - not FunctionsSCString sc.DataFilesFolder();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not FunctionsSCString sc.ServiceCodeForSelectedDataTradingService();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not FunctionsSCString sc.SCDataFeedSymbol();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not FunctionsSCString sc.CustomAffiliateCode();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not FunctionsSCString sc.ChartbookName();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not FunctionsSCString sc.ChartTextFont();
Marked as Read-only string variable and still in the secion Variables and Arrays - not Functions3) As with normal coding guidelines and also your naming conventions for functions up to now I'd suggest to add a "get" in front of the function name - e.g.: sc.getVersionNumber() or sc.getUserName() Date Time Of Last Edit: 2020-08-24 06:18:13
|
| [2020-08-24 10:26:59] |
| |
|
1. In general we do not change functions in order to not break compatibility in a way which requires code changes if we can avoid it. There is a very good reason why that function returns a double and that is when SCDateTime is passed as a copy either as a return value or as a parameter the GCC compiler handles it differently for unknown reasons than Visual C++ and therefore there is a stack corruption which occurs because there is a slightly different convention/size being used with that parameter type. This is avoided by using a double. Regarding the other items, the documentation will be updated. 3. You are not the one providing support here. You need to understand, the massive load and the massive complaints we deal with the user support. This is why we do not put Get here. We do not want to put up with the complaints. Understand that! There always is a reason for everything. We can make all kinds of changes to improve things tremendously, but we do not want to deal with all of the dumb questions that get posted here. It really is quite dumb when people basically tell us that their code does not compile, and they can easily look at the documentation and see that function has been renamed and is also documented on the What is New page. Why do you think we complain so massively about Interactive Brokers. A true garbage service. Complete utter garbage. Our intelligence level is not worth stooping down to that level of garbage for any price. For any price. And when we ask people to pay extra for support which is well justified they do not even want to pay. Just look at a lot of the nonsense that gets posted on this Support Board . We should start deleting more posts (Which we will do). It is astounding the level of alleged problems that people post which are just simply just nonexistent or are the result of operating system problems or external service issues, or failure to read documentation. Just look inside of this thread at the things that get posted. And we decided not to remove sc.FreeDLL even though it is completely unused because we want to have a most studies recompile without any error and eliminate unnecessary support questions. 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: 2020-08-25 09:35:51
|
| [2020-08-24 10:39:01] |
| BrMa - Posts: 77 |
|
Sorry, I did not want to bother you. My post was meant to be constructive - NOT provoking. I do appreciate your tool a lot! That's why I thanked in the beginning of the post for the step you've taken. |
| [2020-08-27 22:34:31] |
| User806682 - Posts: 10 |
|
Hello - I use to have this working before the recent upgrade for a custom chart I've created. The method `GetMillisecond` on the IntradayRecord is returning 0 every time. This is inside the `sc.fp_ACSCustomChartBarFunction` function. Could you tell me what I'm doing wrong here. const s_IntradayRecord record = ChartBarInterface.NewFileRecord; const SCDateTimeMS date = record.DateTime; date.GetMillisecond(); // This now returns 0 every time Thanks for the help. |
| [2020-08-27 22:44:13] |
| |
|
Use GetMicrosecond instead.
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 |
| [2020-08-28 23:02:07] |
| User654912 - Posts: 26 |
|
How can I receive trade data structures with the new milli/micro timestamps via DTC? The structs I'm interested in are: s_MarketDataUpdateTradeWithUnbundledIndicator
ors_MarketDataUpdateTradeWithUnbundledIndicator2
The default struct returned when I make a market data request with DTC is: s_MarketDataUpdateTradeCompact
Thanks |
| [2020-08-29 04:36:32] |
| |
|
For the latest DTC server messages, bitwise or these with the Integer_1 variable in the logon request: const unsigned int DTC_LOGON_REQUEST_INTEGER_1_USE_MARKET_DEPTH_UPDATE_FLOAT_WITH_MS_MESSAGES = 0x80;
const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_NO_TIMESTAMP_MARKET_DATA_MESSAGES = 0x400; const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_MARKET_DEPTH_SNAPSHOT_LEVEL_FLOAT = 0x800; const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_MARKET_DATA_UPDATE_TRADE_WITH_UNBUNDLED_INDICATOR_2 = 0x80000; const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_MARKET_DATA_UPDATE_BIDASK_MICROSECOND_MESSAGE = 0x100000; 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: 2020-08-29 04:38:14
|
| [2020-08-30 00:38:09] |
| ejtrader - Posts: 688 |
|
SC Team - I have version 2159 running one with All Services and one with Futures Order routing. With All Services - I get true milli/micro second timestamps in T&S data and only a counter based timestamp with Order routing service. What setting I should use to make sure I get true timestamp for the T&S data? Both of them are using Denali feed. Is this data dependent on the server I am connected to or some setting on the client side? Attached are the T&S data from these 2 sources. Thanks Date Time Of Last Edit: 2020-08-30 00:39:37
|
 AllServices_TS_data.JPG / V - Attached On 2020-08-30 00:37:50 UTC - Size: 216.9 KB - 630 views Furtues_OrderRouting_TS_Data_IncorrectTimestamp.JPG / V - Attached On 2020-08-30 00:37:57 UTC - Size: 144.96 KB - 617 views |
| [2020-08-30 17:45:59] |
| ejtrader - Posts: 688 |
|
Update to Post #67. Explored further on this. Interestingly the same data works fine and displays correctly(DateTime) during replay. Same T&S data gets counter based time immediately after the replay. (Same chart/instrument - no other changes). The T&S data is from Friday - when the charts were running. SC Team - Would you please review and comment? Thanks Date Time Of Last Edit: 2020-08-30 20:14:24
|
| SC_TS_Data_AccurateDuringReplay.JPG / V - Attached On 2020-08-30 17:44:52 UTC - Size: 229.54 KB - 615 views SC_TS_Data_ImmediatelyAfterReplay_Incorrect.JPG / V - Attached On 2020-08-30 17:45:00 UTC - Size: 232.81 KB - 619 views |
| [2020-08-31 13:29:52] |
| ejtrader - Posts: 688 |
|
Post # 67 & 68 can be marked as closed. Read the release notes for 2156 and apparently related to Market Data servers update. All good now with respect to the T&S data displayed correctly now. https://www.sierrachart.com/index.php?page=doc/Whats_New.php#SCVer2156 Thanks |
| [2020-08-31 15:39:20] |
| |
|
Reviewed.
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 |
To post a message in this thread, you need to log in with your Sierra Chart account: