Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Thu, 25 Apr 2024 14:51:53 +0000
[User Discussion] - Flatten and cancel
View Count: 2862
| [2014-03-07 15:52:53] |
| User35525 - Posts: 179 |
|
Dear support, I am using SC 997, CTS sim feed, and ACSIL, and every month or two my programmed flatten and cancel partially closes out a position but fully cancels the stoploss, leaving me with a net position but no protective stop. What is the best way to prevent this? Will it help to update to the latest SC version with FIX? On the "What's new page" I see these issues and wonder if they're affecting me: 1039 Release Date: 2013-10-26 CTS server-side OCO has now been restored and supports Stop and Limit orders as both Attached Orders and as top level orders without any children. 924 Release Date: 2012-11-30 Corrected an issue with the CTS T4 Trading service where Attached Orders would not be automatically adjusted after the parent order filled. This would result in an error message added to the Trade Service Log. This issue arose in a recent release. Also, corrected a small timing issue that might have led to Open Orders, Positions, and Order Fills from not being processed upon connection to the CTS T4 service. I have delayed updating to the CTS FIX feed because of data and order handling issues, but those look resolved. I'm thinking of signing-up for the new SC realtime CME data feed and updating to version 1102 which uses FIX with CTS, and am hoping that will fix what sometimes happens with flatten and cancel, as well as provide better data. Best, Ted |
| [2014-03-07 18:12:19] |
| |
|
CTS FIX is good now. We definitely recommend updating. You may also want to disable Global Settings >> Data/Trade Service Settings >> Use Server-Side OCO after updating. See how the CTS FIX data feed works for you. It should be good. 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 |
| [2014-03-07 18:24:19] |
| User35525 - Posts: 179 |
|
Thank you. Do you mean "enable" server-side OCO? The trade service page for CTS says it supports server-side OCO, and the attached orders page says to enable it (in Global Settings >> Data/Trade Service Settings) if it's present: http://www.sierrachart.com/index.php?l=doc/doc_AttachedOrders.html I'd feel protected better with server-side OCO, but can disable it if you think that is actually better with CTS and FIX. Best, Ted Date Time Of Last Edit: 2014-03-07 18:38:26
|
| [2014-03-07 18:37:16] |
| |
|
We mean disable "Use server-side OCO" because sometimes when we hear about problems involving the quantities of Attached Orders, then disabling server-side management of those orders will resolve it. Although not sure if this applies to you or not. Disabling it should only be tried if needed. 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: 2014-03-13 17:06:36
|
| [2014-03-13 14:55:37] |
| User35525 - Posts: 179 |
|
This happened again today so I just failed my TsT combine I think. At least it was only a few hundred dollars lost and not thousands. Can you tell me more about this issue? Do server-managed OCO's at CTS depend upon my computer in any way, such that I could improve my situation by getting a better computer or better network connection? I'm using a VPS with good network connection, but only have 1.7GB of RAM. I'm just trying to determine why on earth server-managed attached orders might not work. It doesn't make any sense, after-all, it's 100% server-managed, I thought. I'm just looking for some more insight so I can properly weigh my risks and talk to TopStepTrader if necessary. One would hopefully carefully consider losing the safety-net of server-side OCO's, and I'd hate to have to switch to T4 API or another inferior platform just to get the benefit of server-side OCO's. Something smells fishy here... Either CTS isn't managing server-side OCO's properly, or Sierra Chart isn't, which I can't fathom. Best Regards, Ted |
| [2014-03-13 17:20:36] |
| |
|
Please look at the Trade >> Trade Activity Log to determine what has happened: https://www.sierrachart.com/index.php?l=doc/doc_TradeActivityLog.php Can you tell me more about this issue? No, because we do not know exactly what specific problem you have had that you are reporting in this most recent post. The Trade Activity Log will indicate that.If there is a specific question about a particular order activity line in that log, then let us know about it and provide us the actual line or lines. Server-side OCO does not depend upon your computer system. 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 |
| [2014-03-13 18:03:16] |
| User35525 - Posts: 179 |
|
Please see my attached Trade Activity Log, Trade Service Log, and Message Log. I've pruned the lines so they're small. I only had a couple of trades today, and the trade in question is the one entered at 8:56a.m. and exited at 9:09a.m. For my exits, I'm always using "flatten and cancel" with ACSIL, but if the order is split on exit, the "flatten" doesn't actually always flatten the entire position, while the "cancel" part does completely cancel the attached stop. Best Regards, Ted |
Private File Private File Private File |
| [2014-03-13 19:49:38] |
| |
|
One problem. We see you are using version 997. We do not provide support for 997 any longer. We had a look at the Trade Activity Log. The only thing unusual we saw was an order with internal order ID 797, when canceled went to a "pending open" status and then to a "filled" status but did not seem to generate an actual fill. We cannot tell definitively because you are only showing the order activity and not the "Fills". The order statuses is are provided by the CTS system. In any case, really you need to contact CTS and your broker about the particular issue. It is also hard for us to match up what you are describing in text here, to the Trade Activity Log. As we said we do not see anything really unusual other than what we described. This support request is outside the domain of our support. Please be aware of our policy about this here: https://www.sierrachart.com/index.php?l=doc/support.html#TradingSupport To be clear, we will not be providing further support as it is currently presented to us, on this particular issue. 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: 2014-03-13 19:51:05
|
| [2014-03-13 20:10:20] |
| User35525 - Posts: 179 |
|
Thanks. Is it possible to pay for remote assistance or pay to have Sierra Chart look at my trade log and possibly code? ...or just to answer another question here?: I'm now wondering if there's a race condition that I, and others who use "flatten and close" should know about. For my trading, I don't have set targets, so always must manually close out positions, which I've been doing with "flatten and close". Is that naive to do in some cases? If necessary, I can try to detect that the order is already in the process of being closed-out by my broker, though that gets more complex in cases where an initial order was split. I thought I could avoid all that management by letting Sierra Chart handle it for me, with a simple "flatten and close" request. Best Regards, Ted |
| [2014-03-13 20:39:57] |
| |
|
Is it possible to pay for remote assistance or pay to have Sierra Chart look at my trade log and possibly code? No. We do not have the resources to spend time on this. The best approach is for you to look over and understand the Trade Activity Log. Everything is right there including the current position at every order update. Everything you need to know is in that log. It has been designed to provide complete information for someone to analyze a trade order problem. And newer versions provide even more details.We are confident you can easily help yourself with this. And then if there is something you do not understand the Trade Activity Log, ask us about that one specific item as clearly as you can with as minimal information as is needed. We can help with a clear specific question about some item in the Trade Activity Log. If there is some mishandling of an order, then do these two things: Update Sierra Chart to see if that resolves the problem. Contact CTS about it for an explanation. Is that naive to do in some cases? What you are doing seems fine. We do not see a problem with that.Let us explain our perspective of this. You mentioned a problem with flattening your position and give us a lot of log files. The Trade Activity Log is the most important log. The others were not relevant other than to see you are running 997 from the main Message Log. Obviously we cannot take the time to go through all of the lines in the Trade Activity Log. So we search for a line that says "flatten". We then look to see what the current position quantity is. We see that after some order activity it goes to 0. We did point out one issue that we saw during that process. So at this point, we do not even see the problem that you are asking about to begin with. This is why it is best you analyze the log yourself, and then ask us a question about a specific item. 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 |
| [2014-03-14 01:11:13] |
| User35525 - Posts: 179 |
|
Dear SC, Thanks for taking a look. I understand that you don't have time to investigate everybody's trade activity log extensively. I do have a couple specific questions now, after doing some more research. You said: The only thing unusual we saw was an order with internal order ID 797, when canceled went to a "pending open" status and then to a "filled" status but did not seem to generate an actual fill.
What do you mean by "did not seem to generate an actual fill"? From what I can tell looking at earlier log entries (for example the above T4 stop trigger (8:18:14.000, 8:18:14.001, 8:18:14.003), it is normal for T4 order updates, on a stoploss, to first show as "Pending Open", then "Open", then finally "Filled". Order ID 797 is doing the same (goes from "Pending Open" to "Filled" at 9:09:18.002 and 9:09:18.003). The problem that I see is my "flatten and cancel" first happens. Sierra Chart sees that at 9:09:18.000 and 9:09:18.001 and logs "Cancelling all orders" (this works on ID 797) then "Auto-Trade: ....Flatten&Cancel" (this starts a new internal order ID 798). And then immediately afterwards, T4 stops me out at 9:09:18:003, while Sierra Chart continues working on the flatten and close (order ID 798) by submitting three T4 updates (market Buy 3). I'm sure T4 will concur after I show them the ServiceOrderID's for internal order ID 798 (I still need to check my official "fills" as you said). Next steps: I will follow-up with T4 just so I have done all the due diligence possible, then I'll update SC to the latest version that uses FIX. But, I'm still perplexed why you say the flatten&cancel had nothing to do with the problem. When I asked about a race condition you wrote: We do not see a problem with that. It's clear from the log that order ID 798 originated with the flatten&cancel action at 9:09:18.001, and it's clear that there is some sort of "race condition" that caused SC to attempt to close a position that T4 had already closed a few millisecond earlier at 9:09:18:003. So T4 closes the position, THEN Sierra Chart tries to close it again.And now I know why some users must disable server-managed OCO's. If I let SC completely manage the OCO's, I guess this issue cannot happen because SC won't have any race condition to monitor (SC will be handling ALL the entries and exits and won't have to watch for broker-initiated attached orders). This looks to me like a serious problem with CTS server-side OCO's and Sierra Chart, but maybe it only pertains to SC 997. From your earlier response I understand that this is probably a rare event, and from the fixes on the "what's new page" I'm guessing the problem may have been fixed. Best Regards, Ted Date Time Of Last Edit: 2014-03-14 01:14:27
|
| [2014-03-14 02:04:44] |
| User35525 - Posts: 179 |
|
It looks like Sierra Chart needs to watch for broker-initiated action messages -- like "CTS T4 order update. T4 status: Stop Trigger" -- and then intelligently handle any SC-initiated orders that may have been submitted a few milliseconds BEFORE the broker-initiated order. If the idea is to "get flat", and SC is "managing" that for us, then the final outcome should be flat, just as if a human was trading, and saw that they needed to take additional action to really get flat. So to recap, right now with 997, if SC said "get flat" at nearly the same time as the server-side stop is triggered, there can be a "collision". Maybe the collision doesn't happen if the broker first initiates the stop (SC can just watch for that easily), but it can and does happen when SC initiates the stop immediately before the broker. This all gets pretty complex, but it looks like something that SC should be able to handle. I'm not trying to so HFT programming, but just would like to see SC play well with a server-side OCO and "flatten and cancel" command. Will upgrade to 1102 this weekend. Best Regards, Ted Date Time Of Last Edit: 2014-03-14 02:05:51
|
| [2014-03-14 02:34:19] |
| |
|
What do you mean by "did not seem to generate an actual fill"? From what I can tell looking at earlier log entries (for example the above T4 stop trigger (8:18:14.000, 8:18:14.001, 8:18:14.003), it is normal for T4 order updates, on a stoploss, to first show as "Pending Open", then "Open", then finally "Filled". Order ID 797 is doing the same (goes from "Pending Open" to "Filled" at 9:09:18.002 and 9:09:18.003). The problem that I see is my "flatten and cancel" first happens. Sierra Chart sees that at 9:09:18.000 and 9:09:18.001 and logs "Cancelling all orders" (this works on ID 797) then "Auto-Trade: ....Flatten&Cancel" (this starts a new internal order ID 798). And then immediately afterwards, T4 stops me out at 9:09:18:003, while Sierra Chart continues working on the flatten and close (order ID 798) by submitting three T4 updates (market Buy 3). I'm sure T4 will concur after I show them the ServiceOrderID's for internal order ID 798 (I still need to check my official "fills" as you said). We see no problem with orders 797 or 798 other than the status reporting with 797. 797 did not get filled because when we go to look at the Position Quantity it does not change. It only changes after the market order 798 fills and then goes flat. But we cannot see the fills because you do not select All Activity at the top left of the Trade Activity Log. We also see no reason why canceling of stop order suddenly causes it to become filled. It does not make sense. And then immediately afterwards, T4 stops me out at 9:09:18:003, If this order is really filling when being canceled, and it should not based upon its price, then you really have to ask CTS about this. After all of this, you really have everything in front of you. You have more information and an understanding of what is going on than we do. And if you are running the current version, you would not have the order status problem. This is one of the reasons why we use FIX connections.The trouble we have seen with server-side OCO is straightforward. What we find is that when increasing the quantity or maybe decreasing the quantity of one of the orders in the OCO group, it does not always work. This is the only issue. At this point, we cannot commit more time to this. These kinds of support requests are costly to us. If something is important, we will dedicate our time to it, no matter the cost. Otherwise we just have to draw the line on these kinds of requests and not get involved with them. They are very time-consuming. This thread is closed and cannot respond more. 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: 2014-03-14 02:40:40
|
| [2014-03-14 02:40:15] |
| |
|
It looks like Sierra Chart needs to watch for broker-initiated action messages -- like "CTS T4 order update. T4 status: Stop Trigger" -- and then intelligently handle any SC-initiated orders that may have been submitted a few milliseconds BEFORE the broker-initiated order. If the idea is to "get flat", and SC is "managing" that for us, then the final outcome should be flat, just as if a human was trading, and saw that they needed to take additional action to really get flat. We do not even see a problem occurring here which would require this and what you are asking for is not even possible because the canceling of working orders and the sending of the market order happens all at the same time before any order reports from the remote server side.
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: