Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 27 Apr 2024 13:04:26 +0000
[Locked] - Move to Breakeven Stop Issue
View Count: 5040
| [2016-10-07 21:40:23] |
| rhovega - Posts: 279 |
|
Today 10/7 I experienced what I believe is Sierra Chart's faulty management of moving a stop to breakeven. Details are as follows: Before the NFP news release I placed on Sierra Chart a limit order to sell GC (Dec'16 contract) at 1265.0, with an attached profit target of 40 ticks, stop loss of 35 ticks, and a Move to Breakeven for Stop with Offset in Ticks Triggered, BE Level Offset 0 and Trigger Offset 30. Order was filled at 1265.0 at 08:30:01. Stop was filed at 1265.9 at 08:30:02. My broker registers an attached stop loss order, transmitted by Sierra Chart, of 1265.0 filled at 1265.9. If SC had worked properly, after the 1265.0 fill, price needs to have traded 1262.0 and then gone back up to at least 1265.9. Nonetheless, in between the 1265.0 fill and the 1265.9 fill, 1262.0 did not trade. According to Time Sales, the low price in between fills was 1262.3. Therefore the stop should not have been moved to 1265.0, and should have remained at 1268.5. 1268.5 never traded. After the 1265.0 fill, 1262.0 first traded at 08:30:22. Then 1261.0 traded at 08:30:30, before 1265.0 traded again. How is this possible? |
| [2016-10-07 22:55:16] |
| |
|
The only possible scenario would be faulty data or an unexpected issue involving the reported fill price of the parent order. Follow the instructions here to provide the Trade Activity Log lines for those two particular orders: http://www.sierrachart.com/index.php?page=doc/TradeActivityLog.php#TradeActivityLogToSupport The other possibility is that the Trigger Offset was not actually set to 30. This is something to be aware of related to that: http://www.sierrachart.com/index.php?page=doc/TradeWindow.html#SettingsNotApplying 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 |
| [2016-10-08 17:39:12] |
| rhovega - Posts: 279 |
|
GC has a dedicated DOM with dedicated order presets. The trigger was offset at 30. Logs should be capable of showing this - assuming Sierra Chart logs everything, which it should. The requested log lines are as follows: ActivityType DateTime Symbol OrderActionSource InternalOrderID OrderType Quantity BuySell OpenClose Price FillPrice Price2 OrderStatus FilledQuantity TradeAccount ParentInternalOrderID PositionQuantity FillExecutionServiceID ServiceOrderID Order 2016-10-07 08:29:45.491 GC-201612-NYMEX IB order fill (execution) 24216 Limit 1 Sell Open 1265.0 1265.0 Filled 1 U11XXXXX 9613 Order 2016-10-07 08:29:45.492 GC-201612-NYMEX Updated Internal Position Quantity to -1. Previous: 0 Unspecified U11XXXXX Fill 2016-10-07 08:29:45.493 GC-201612-NYMEX IB order fill (execution) 24216 Limit 1 Sell Open 1265.0 1265.0 Filled 1 U11XXXXX -1 0000fe1c.57f6d502.01.01 9613 Order 2016-10-07 08:29:45.494 GC-201612-NYMEX Auto trail order modification (Move to breakeven). Trigger price: 1258.200019. Requested Price: 1265. Requested Quantity: 1 24218 Stop 1 Buy Close 1268.5 Pending Modify U11XXXXX 24216 -1 9615 Order 2016-10-07 08:29:45.529 GC-201612-NYMEX IB Open Order update 24218 Stop 1 Buy Close 1265.0 Open U11XXXXX 24216 -1 9615 Order 2016-10-07 08:29:46.474 GC-201612-NYMEX IB Open Order update 24217 Limit Buy Close 1261.0 Canceled U11XXXXX 24216 -1 9614 Order 2016-10-07 08:29:46.475 GC-201612-NYMEX IB order fill (execution) 24218 Stop 1 Buy Close 1265.0 1265.9 Filled 1 U11XXXXX 24216 -1 9615 Order 2016-10-07 08:29:46.476 GC-201612-NYMEX Updated Internal Position Quantity to 0. Previous: -1 Unspecified U11XXXXX I have replaced last digits of my account number by XXXXX as this is a public post. Time stamps are wrong as computer had time off by about 1.5 seconds. Timestamps from original post are actual timestamps from IB. |
| [2016-10-09 08:35:10] |
| |
|
As you can see here: Auto trail order modification (Move to breakeven). Trigger price: 1258.200019. The trigger price is 1258.20 which is the last trade price which caused the move to break even. However, the timestamps in your Trade Activity Log and the prices we see do not correspond with the market action assuming these are US Eastern times. December GC was not at 1265 at 08:29:45. Here is the second by second activity: http://www.sierrachart.com/image.php?Image=1476000270806.png It reached that price at 08:30:01 Anyway we do see why this happened and that is the move to breakeven was using market data slightly before the fill. In order to not miss any prices, Sierra Chart does use all of the trading activity in between chart updates but we can see, that in this particular scenario, it only must be the activity after the fill and after the move to breakeven was allowed. We need to examine this more closely and see how best to handle that. 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 |
| [2016-10-09 08:49:26] |
| |
|
So at this point it appears as though that Sierra Chart is using market data since the last chart update and before the fill for the move to breakeven action when it should not be doing that. We are going to filter that data out. Since the market was moving fast at the time of the fill, that data before the fill is apparently what triggered the move to breakeven. Update: However, we later learned that you are using true real-time data from Interactive Brokers which is the definitive cause of the problem in this particular case because that data is lagging by five seconds. We have added a time credit to your account. We certainly are aware of these kinds of scenarios and do manage these accordingly but this particular one involving move to breakeven actions was never considered. However, one thing we do recognize is that if market data is ever delayed, relative to the time of a fill, and is received after the fill, it will not/cannot be filtered and can still affect the move to break even action. 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: 2016-10-12 03:26:54
|
| [2016-10-09 09:07:51] |
| |
|
Thinking about this some more, if prices are delayed then still the most recent old price at the time of the fill will still be used to trigger the move to breakeven. Therefore, there is still some potential risk in the case of a fast-moving market that it is not going to work properly. This risk cannot be completely removed. And it could very well be, that the particular problem you experienced is what we describe in this post and not what we are actually patching and has the potential to happen again. This is entirely reasonable. So you need to be aware of this risk and we will make sure to document it. 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: 2016-10-09 09:10:06
|
| [2016-10-09 16:35:37] |
| rhovega - Posts: 279 |
|
So the explanation is that: a) Sierra Chart uses market data since last chart update for the move to breakeven, and b) because the computer's clock (and thus the charts) were off by 1.5 seconds, then c) Sierra Chart used market data before the fill for the move to breakeven, therefore d) using 1258.20 (rather than 1262.0) as the breakeven trigger price, which e) resulted in an immediate move to breakeven of the stop order. Is this accurate? And the solution you are implementing is to only use activity after the fill for the move to breakeven. Then why do you say on post #5 that "if prices are delayed then still the most recent old price at the time of the fill will still be used to trigger the move to breakeven"? I must be misinterpreting your words, to me it seems post #5 contradicts post #4. Will you be filtering out activity prior to the fill or not? |
| [2016-10-10 09:04:59] |
| |
|
The computer clock has no effect on this. It is the Chart Update Interval which had the most significant effect and the fact that the market was moving very fast. If the Chart Update interval was under 100 milliseconds, and the data was also being received with very minimal delay from the exchange, then it is much less likely there would have been a problem. And also based upon the time stamping we see in the Trade Activity Log your clock was more than off by 1.5 seconds but that was not relevant to the problem. There simply was too much price movement within a one second period of time and various order events occurring that led to the problem. And the solution you are implementing is to only use activity after the fill for the move to breakeven. Yes.Still though if the prices are delayed, then a delayed old price received after the fill can affect the move to breakeven functionality. It is not possible to filter out the delayed prices because it is not possible for Sierra Chart to know they are delayed to begin with. Especially in the case of Interactive Brokers. Trying to detect this is very inherently unreliable especially with subsecond precision which would absolutely be needed in this case. There is always going to be an element of risk with a fast-moving market which is extremely hard to remove without creating other problems. 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: 2016-10-10 09:08:44
|
| [2016-10-10 09:12:53] |
| |
|
Also are you using true real-time data?: http://www.sierrachart.com/index.php?page=doc/InteractiveBrokers.php#TrueRealTimeData If so, then the changes we are making are not going to help at all. Also like we said previously, even with the changes we are making and even if you are not using true real-time data, this can still potentially happen again. So you really should avoid using the move to breakeven functionality for a stop which is going to be triggered during a fast-moving market. It is very obvious to us how this kind of scenario can develop in that particular case and we do not see a solution to it without filtering out even more data which could be relevant. 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 |
| [2016-10-10 18:28:33] |
| rhovega - Posts: 279 |
|
Settings mentioned were: - Chart update in miliseconds = 40 (in General Settings). - Record True Real-Time Data in Intraday Charts = True (in Data/Trade Service Settings). This means that the effective chart update interval is 5secs rather than 40ms. This applies to chart bars, and not to Time & Sales nor the DOM, which update at 40ms. So the delay you are talking about is 5s for the chart bars and 40ms for the last traded price. Is the breakeven functionality not working because it uses prices from the charts (5s delayed) rather than real-time prices (40ms delayed)? If so, can you not use last traded price and Time & Sales data rather than chart bars as input for the breakeven functionality? Date Time Of Last Edit: 2016-10-10 19:02:24
|
| [2016-10-11 06:42:58] |
| |
|
We are not saying that data was delayed, we are noticing that the clock based upon what we see in the Trade Activity Log was off by more than 1.5 seconds. However, all market data is delayed to some extent even if it is milliseconds. When the market moves several points in a single second, millisecond delays count. According to this line: Fill 2016-10-07 08:29:45.493 GC-201612-NYMEX IB order fill (execution) 24216 Limit 1 Sell Open 1265.0 1265.0 Filled The order fills at 08:29:45.493, but the market did not reach the fill price of 1265 until 8:30:01. This is indisputable. so the clock must have been off by more than 1.5 seconds. Record True Reak-Time Data in Intraday Charts = True (in Data/Trade Service Settings). If so, can you not use last traded price and Time & Sales data rather than chart bars as input for the breakeven functionality? No because at the point where the data is being used it is not possible to distinguish the origin of it.Consider using the Sierra Chart Exchange Data Feed: Sierra Chart Exchange Data Feed 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: 2016-10-11 06:45:47
|
| [2016-10-11 13:06:44] |
| rhovega - Posts: 279 |
|
I made the clear the clock was off. By 1.5 to 2.5 seconds based on timestamps. You said before that the clock has nothing to do with this issue. If that is indeed the case, then this is not relevant. The bottom line seems to be the Sierra Chart orders modification (move to breakeven and trailing) execution engine is flawed. My takeaway is you can't or won't clearly state why the error happened, aside of blaming fast markets, the Chart Update Interval, and Interactive Brokers True Data. There should be a very precise answer to this. And the corollary is that Sierra Chart should not be trusted to execute orders in fast moving markets without an "element of risk". Would I have executed the same order within Interactive Brokers' TWS my risk would have been null and this trade would have yielded a profit of USD 400 (in 9 seconds) rather than a loss of USD 90. Thanks god I was only trading my account and it was only one contract. I think the minimum you could do is to cover the loss caused by this undocumented Sierra Chart unreliability - rather than providing for a one month time credit, which is what you did. |
| [2016-10-12 01:53:56] |
| |
|
I made the clear the clock was off. By 1.5 to 2.5 seconds based on timestamps. It is certainly more than that. That is clear.We have given a very clear answer to this and everyone can see this. This is explained at post #5 and other posts as well. Unlike Interactive Brokers Sierra Chart is designed to be very precise and uses all market data for trailing stops and not miss any data. As we previously indicated, we did make a small correction to use only the data received after the fill and not since the last chart update, but that would not have solved this at all in your case because you are using true real-time data. Today we did look into the possibility of filtering out the true real-time data for trailing stops, but concluded that is going to create another problem and reduce the precision of trailing stops and simulated orders. So that is not practical for us to do. I think the minimum you could do is to cover the loss caused by this undocumented Sierra Chart unreliability - rather than providing for a one month time credit, which is what you did. The Interactive Brokers system does not support move to break even stops. Only trailing stops. And their system is only going to sample the data and not consider all of the traded prices for the trailing stop because their data feed is not complete. Interactive Brokers does make mistakes, and does have technical issues, which does cause users to lose money. This is simply inevitable. We all try to do our very best but problems can arise for technical reasons which were never contemplated. So in your particular case, do not use trailing stops or move to break even stops in Sierra Chart since you are going to be using true real-time data because there is going to be this potential problem. It is precisely because Sierra Chart does its best to track all the prices, which can lead to this kind of potential problem. We did make a small correction, but that as we said was not relevant in your case. It would have happened anyway. 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: 2016-10-12 01:55:57
|
| [2016-10-12 02:00:51] |
| |
|
The more we contemplate this, the more we really realize that this is an inherent problem that can affect any trading platform. Whenever you have a burst of market activity like during an economic announcement, it is perfectly normal that a data feed is going to lag behind even if it is just 250 milliseconds or 2000 milliseconds. That is more than enough of a lag where if there is a several point move in a single second like in this case, where that lagging data is going to then be used for a trailing stop or a move to breakeven stop and be acted upon when it should not be. And it is not reliable to look at timestamps in this particular case to filter out the data 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: 2016-10-12 02:03:52
|
| [2016-10-12 02:43:10] |
| rhovega - Posts: 279 |
|
We have given a very clear answer to this and everyone can see this. This is explained at post #5 and other posts as well.
It is not clear at all. I have had quite a few people that use Sierra Chart look at this thread, and no, it is not clear. Please confirm the problem is the chart update interval. I think the minimum you could do is to cover the loss caused by this undocumented Sierra Chart unreliability - rather than providing for a one month time credit, which is what you did.
We cannot do this for obvious reasons and we have no further comment about this. We always do our very best and obviously we cannot be responsible for losses.
This shortcoming of Sierra Chart was undocumented. You just encountered it for the first time through me. This Sierra Chart shortcoming cost me money. You should have taken care of this shortcoming before going live with your platform, or have this documented as a known shortcoming. The Interactive Brokers system does not support move to break even stops. Only trailing stops. And their system is only going to sample the data and not consider all of the traded prices for the trailing stop because their data feed is not complete.
You are wrong. It is possible to setup breakeven stops. And in their system I would not have been stopped out at a loss, but rather been hit the profit target 8 seconds later. Interactive Brokers does make mistakes, and does have technical issues, which does cause users to lose money. This is simply inevitable. We all try to do our very best but problems can arise for technical reasons which were never contemplated.
Interactive Brokers certainly does make mistakes. Everyone does. Based on my experience Interactive Brokers assumes responsability for their mistakes. When it is their mistake, they make the client whole. This is how good business is supposed to be conducted: when the services provider makes a mistake that costs the client money, the service provider should compensate the client accordingly. The more we contemplate this, the more we really realize that this is an inherent problem that can affect any trading platform. Whenever you have a burst of market activity like during an economic announcement, it is perfectly normal that a data feed is going to lag behind even if it is just 250 milliseconds or 2000 milliseconds.
Seems an attempt to excuse Sierra Chart from good execution. Sierra Chart has unfortunately been hereby proven to be an unreliable trading platform in fast markets. You should have this shortcoming documented, with a clear disclaimer about it. I will not use Sierra Chart in fast markets, and I will not use Sierra Chart's order management options any longer. No live trader should do so. Date Time Of Last Edit: 2016-10-12 02:47:27
|
| [2016-10-12 02:59:26] |
| rhovega - Posts: 279 |
|
It is very disappointing to realize that Sierra Chart is not a reliable trading platform, and that it is so cheap for a reason, because it is unreliable. Sierra Chart is proving itself to be a trading platform for sim traders. Your attitude is very disappointing as well. Consistently disappointing. I will contact your management about this event. You know your platform was at fault here. Otherwise you would not have credited my account with one month of time. But you are unable or unwilling to apologize, and seem to be shifting the responsibility to others. I will have to explore switching platform as soon as I have free time. If you want to kick me out as a customer because I suffered from a Sierra Chart shortcoming and brought this up to your attention, then go ahead. There is nothing further to add to this thread unless you want to a) confirm the problem is the chart update interval, and b) offer a proper apology and compensation (how can you not offer USD 90 in time credit as a token gesture is baffling). |
| [2016-10-12 03:42:39] |
| |
|
We apologize for the delay with this, we have been quite busy and we needed some further time to consider this. Here is the situation: We were mistaken, with the initial analysis as to the cause of the problem. These are the potential causes of an issue like this: -Lagging market data relative to the order fill. It is impossible to determine the extent of the lag but there is always some element of lag that does exist. - The fact that you are using Interactive Brokers true real-time data which does lag by 5 seconds. This is a data feed which users use because of the substandard Interactive Brokers data feed. This data is used for trailing stops and simulated orders because our users expect this. This can and will cause a problem like this and definitively was the cause of the issue here, but there is no way that we could of contemplated this ahead of time. It is unreasonable to think that we can consider and document everything. - The fact that Sierra Chart uses data between chart updates for trailing stops and simulated orders after an order has been submitted and if the order is active. This is something that we changed in response to this and thought this was a cause, but we realized that the problems described above are the actual causes and this is simply just not relevant. We also realized the change we made is not necessarily correct because an order will fill some time between chart updates and it is reasonable to use the data since the last chart update to modify a trailing stop. So it is possible we may even change back what we previously changed. Also with the low 40 millisecond update interval you are using, the significance of this as being a cause is extremely minimal. And there is evidence of this in the Trade Activity Log. One thing we did change, is that true real-time data will no longer have any effect on trailing stops and simulated orders. This itself is going to be a negative consequence and some users are certainly going to raise issues with this in the future and ask why it is that a trailing stop did not move when it should have been and why a simulated order did not fill when it should have. Sierra Chart is very reliable and high quality software as is clearly evidenced by our users experiences and the fact that we promptly take care of any issues that arise that are within our control. Just like we did here. The basic cause of this problem is simply the circumstances and very fast-moving markets and lagging data. None of which we have any control over and the changes that have been made would not have avoided it anyway and would it still have happened. There is no way that we can prevent something like this from happening but there are things we can do to minimize it but the more we do to minimize it, it then creates a problem where some price action is ignored. It also is not reliable to use timestamps as a safeguard for this kind of potential issues because IB does not have a trustworthy highly accurate timestamp in our experience for order fills, which is in sync with market data which contains no timestamps. This is also especially a problem by the fact that your computer clock was off by 16 seconds which is indisputable. There is no way that any program built to work with Trader Workstation can handle move to break even stops perfectly. This can only be done on the backend using timestamps from the exchange itself. Apparently we were mistaken when we said Interactive Brokers does not have move to breakeven stops. We thought they did not, and before we made that statement, we checked the TWS documentation and there was no mention of them. So apparently these are undocumented. We apologize for adding a time credit to your account. It has been removed. With the low prices of Sierra Chart, and with the support cost you have put on us over time, and the way that we have been treated by you it was completely inappropriate for us to be adding a credit. The basis of the credit was the fact that something was brought to our attention, that we normally would not have been aware of and something that we thought at the time was of significance and should be changed. Our review of that has changed though. It is totally and completely inappropriate to be requesting payment for consequential damages. Besides Sierra Chart has done nothing wrong here. Sierra Chart is very high quality and reliable software. It is silly to think with the low prices of Sierra Chart and based upon the well-established law of contracts that we will be paying for consequential damages. Under contract law, consequential damages simply are not claimable. Any lawyer will tell you that. You need to understand we are not a broker and also as a general rule brokers will not compensate traders for losses when there are technical problems. There are certainly exceptions to this but in general this is simply not the case. This is a general statement not only applicable to Interactive Brokers but to all brokers. Now what can you do to prevent a problem like this: Certainly the changes that have been made will help minimize it. So update Sierra Chart to the current version. However, we cannot guarantee that it will not happen again. Although we would expect that it is unlikely to occur but cannot promise that. You also need to use the Sierra Chart Exchange Data Feed which is a low latency and complete data feed: Sierra Chart Exchange Data Feed If you do not even want to spend the money on this data feed, then this is your issue. ---- Furthermore, if you understand law you will know that we are not responsible for consequential damages and we should never get involved in that. You do not want to do anything which is going to increase the price of Sierra Chart or create unnecessary burdens on us. If you want to kick me out as a customer because I suffered from a Sierra Chart shortcoming and brought this up to your attention, then go ahead.
This statement makes no sense. We would never do such a thing we do not know why you are saying this. We gave the support request prompt attention and corrected what we thought was the problem, but that was not relevant to the issue after further analysis. Why we are being treated this way, we do not know. This statement reveals the true nature of who you are. You very often have been abusive towards us in words and have blamed for us for issues which are not even ours. Just like you are doing here. We acknowledge that there was a slight issue that potentially could have been a problem but it was not relevant to this case. What you are trying to do is tempt us to cut off your account so you can get even more angry at us and then complain to every other person out there to somehow make us look bad in your opinion. Why you are doing this, we do not know. It is very clear your following a strategy of bashing us and blaming us, when the root problem here is that is substandard Interactive Brokers data feed . Here is the relevant documentation we have prepared in relation to this issue: Order Types: Effect of Delayed Data on Trailing Stops We have also patched the issue described previously in post #5, although it did not contribute to the problem in this particular case. And another thing too, we have experience with the gold market ourselves. It is completely improper to blame us for any loss in the gold market and we will never accept that. The gold market is a known manipulated market which you should be very very well aware of. Stop orders are routinely touched off only for the market to reverse and go the opposite direction. Please do not blame us for this. I will contact your management about this event. You are already speaking to the top programmers and management here. There is no one else higher up. We are all involved in software development .
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: 2016-10-16 09:02:40
|
To post a message in this thread, you need to log in with your Sierra Chart account: