Support Board
Date/Time: Tue, 21 Jan 2025 04:16:49 +0000
Report Possible Bug: sc.SellEntry() Incorrectly Displays Order Fills
View Count: 1052
| [2018-08-01 15:53:33] |
| Richard Chinn - Posts: 28 |
|
Report Possible Bug: sc.SellEntry() Incorrectly Displays Order Fills Sierra Chart Version 1785 64-bit. No settings were changed from the original download except as noted "I am using my own custom automated trading study running as a SIMULATION." SETUP: true: sc.AllowOnlyOneTradePerBar Checked: Trade>>Chart Trade Mode On Checked: Trade>>Show Order Fills Checked: Trade>>Show Orders And Positions Checked: Trade>>Auto Trading Enabled - Global Checked: Trade>>Auto Trading Enabled - Chart OBSERVATION: - An order has filled - Chart display is: 1@2824.25 - Study tries to fill another order in the same bar - Message sent to Trade Service Log stating trade is ignored because AllowOnlyOneTradePerBar is true - The attempted fill 1@2826.00 is displayed as a fill on the same bar Chart display is incorrect. The second "order fill" is reflected on the same bar even though the additional 1@2826.00 was rejected. This happens multiple times with each new attempt and rejection until the bar is closed, displaying a new “fill” on the chart each time. I only observed this with the sc.SellEntry() function. It hasn’t happened in my program with the sc.BuyEntry() function. The program performs correctly in the sense that no additional fills are made. CODE SNIPPET: s_SCNewOrder NewOrder; NewOrder.OrderQuantity = 1; NewOrder.OrderType = SCT_ORDERTYPE_MARKET; NewOrder.TimeInForce = SCT_TIF_DAY; orderResult = (int)sc.SellEntry(NewOrder); if (orderResult < 1) sc.AddMessageToLog(sc.GetTradingErrorTextMessage(orderResult), 1); DOCUMENTATION SEARCH: None SUPPORT BOARD SEARCH: sc.SellEntry / sc.BuyEntry: No relevant threads found Thanks Richard |
| [2018-08-01 17:14:58] |
| |
|
Chart display is incorrect. The second "order fill" is reflected on the same bar even though the additional 1@2826.00 was rejected.
This conclusion must be wrong unless there actually was a fill. Provide an image of the chart showing this fill. Probably what you are seeing is not a fill if there never was a fill.This happens multiple times with each new attempt and rejection until the bar is closed, displaying a new “fill” on the chart each time. Provide an image of the chart or Trade DOM, by following these instructions: https://www.sierrachart.com/index.php?page=doc/PostingInformation.php#Image Highlight where the questionable fill is. 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: 2018-08-01 17:15:36
|
| [2018-08-01 18:42:19] |
| Richard Chinn - Posts: 28 |
|
http://www.sierrachart.com/image.php?Image=1533148536407.png This is from a chart running right now. As you can see a position was opened on this bar. The bar also shows a close on the same bar and at the same price in this case. You can see that I've taken the snapshot a few bars after the bar and the position did not close even though there is a message -1@2811.00 that a position close took place. |
| [2018-08-02 04:49:20] |
| |
|
You need to understand how this variable works: Automated Trading From an Advanced Custom Study: sc.AllowOnlyOneTradePerBar It is impossible from our perspective to know whether the position quantity reporting is correct or not but there has never been any known problem with 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 |
| [2018-08-02 13:15:47] |
| Richard Chinn - Posts: 28 |
|
I think I am understanding the documented action of the variable correctly. It does work properly, preventing another of the same type trade on the same bar. I think maybe this is a clue from the documentation: sc.AllowOnlyOneTradePerBar Documentation ... For example, once sc.BuyEntry is called and is successful with an order submission (whether the order fills or not), additional calls to sc.BuyEntry will be ignored on the same chart bar and will return SCT_SKIPPED_ONLY_ONE_TRADE_PER_BAR. My program code checks if the bar closed, sets variables, then determines if a trade is possible. If no trade is possible a return is made and the code to initiate a new order should never be evaluated. This is what I am seeing happen: - A successful sc.BuyEntry is made, the price 1@____ is displayed on the bar and the position is displayed (I have Checked: Trade>>Show Orders and Positions) - Almost immediately a -1@____ is displayed but the first position is NOT closed and is still actively displaying (I'm watching the P&L calculations change) - At some point my study sees an exit condition on a future bar and closes the position as expected. This is what I think MAY be happening: - A successful sc.BuyEntry() is made and the sc.AllowOnlyOneTradePerBar becomes active - On a subsequent iteration through the study on the same bar, an unsuccessful sc.BuyEntry() attempt is made. Probably because my entry conditions are valid. - The -1@____ is displayed on the chart and I get the error message "Order skipped because only one trade per bar is allowed." Could this be what is happening? On the first unsuccessful attempt, the -1@____ is being displayed in error As I stated in my first post, I have not seen this happen when sc.SellEntry opens a position first. This does not happen on every successful sc.BuyEntry. When it does happen, it only happens once and I get the error message only one time. My programming style is defensive so I should never get this message even on a first unsuccessful attempt. The ACTUAL complete code pertaining to the issue is below. I think this may be an actual bug and not my programming. I hope this helps. if (sc.GetBarHasClosedStatus() == BHCS_BAR_HAS_CLOSED) orderEntryDelayed = orderExitDelayed = false; sc.GetTradePosition(PositionData); if (PositionData.PositionQuantity <= -1 && !orderExitDelayed) { if (exitOdds >= ir_MinExitOdds.GetFloat() / 100) { orderExitDelayed = true; orderType = atm_ORDER_EXITBUY; } else return; } else if (PositionData.PositionQuantity == 0 && !orderEntryDelayed) { if (entryOdds >= ir_MinEntryOdds.GetFloat() / 100) { if (entryDirection >= 1) { orderEntryDelayed = true; orderType = atm_ORDER_ENTRYBUY; } else if (entryDirection <= -1) { orderEntryDelayed = true; orderType = atm_ORDER_ENTRYSELL; } else return; } else return; } else if (PositionData.PositionQuantity >= 1 && !orderExitDelayed) { if (exitOdds >= ir_MinExitOdds.GetFloat() / 100) { orderExitDelayed = true; orderType = atm_ORDER_EXITSELL; } else return; } else return; s_SCNewOrder NewOrder; NewOrder.OrderQuantity = 1; NewOrder.OrderType = SCT_ORDERTYPE_MARKET; NewOrder.TimeInForce = SCT_TIF_DAY; if (orderType == atm_ORDER_ENTRYBUY || orderType == atm_ORDER_EXITBUY) orderResult = (int)sc.BuyEntry(NewOrder); // Submit order if (orderType == atm_ORDER_ENTRYSELL || orderType == atm_ORDER_EXITSELL) orderResult = (int)sc.SellEntry(NewOrder); // Submit order if (orderResult < 1) sc.AddMessageToLog(sc.GetTradingErrorTextMessage(orderResult), ir_OpenMessageLog.GetBoolean()); |
| [2018-08-02 15:29:17] |
| Richard Chinn - Posts: 28 |
|
UPDATE I added some code to help debugging. It appears the issue is in the sc.SellEntry function. I have watched it happen several times this morning. My debugging code gave me the following information: Chart: ESU8-CME 1 Min #1 | Study: ATM Short Term | DEBUG: Entry Buy is order type | 2018-08-02 11:13:08 * Chart: ESU8-CME 1 Min #1 | Study: ATM Short Term | DEBUG: A BUY ENTRY attempt was Successful | 2018-08-02 11:13:08 * Chart: ESU8-CME 1 Min #1 | Study: ATM Short Term | DEBUG: Exit Sell is order type | 2018-08-02 11:13:59 * Chart: ESU8-CME 1 Min #1 | Study: ATM Short Term | DEBUG: A SELL EXIT attempt was UNsuccessful | 2018-08-02 11:13:59 * Chart: ESU8-CME 1 Min #1 | Study: ATM Short Term | Order entry skipped because only one trade per bar is allowed. | 2018-08-02 11:13:59 * A Successful BUY Position is established In the same bar an Unsuccessful SELL Position is attempted The Unsuccessful SELL attempt is shown on the chart (I have Checked Trade>>Show Order Fills) as a Sell -1@____ It was unsuccessful so the BUY position is not closed The BUG is the display of a SELL attempt as an actual SELL on the chart |
| [2018-08-03 00:09:22] |
| |
|
Really we are 100% certain there is not a problem here. That would be incredibly unlikely there actually is. We cannot debug what you are doing: Automated Trading Management: Troubleshooting Automated Trading System Behavior We can only analyze this from our perspective and use a structured approach. It really is impossible the Position Quantity is going to be reported incorrectly. Make sure the Order Fills Start Date-Time is set to 0: http://www.sierrachart.com/index.php?page=doc/ChartSettings.html#OrderFillsStartDateTime If this is not set right it can lead to what appears like an incorrect Position Quantity. We will also add documentation on this page explaining how the Position quantity is determined. Trade Activity Log Also if you see an order fill on the chart, there was indeed an order fill and whatever function you used to cause that order fill, worked properly. We cannot accept any other explanation because we know how this works. What your automated trading system has done, is fully logged in the Trade Activity Log: Trade Activity Log: Viewing Historical Trade Activity That is the definitive reference. Once again we do not provide debugging services and the information you are giving here is not something we analyze. If sc.SellEntry is giving an error, then there will have been no order submitted. We verified 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 Date Time Of Last Edit: 2018-08-03 00:59:28
|
| [2018-08-03 00:18:25] |
| |
|
When we have that documentation mentioned ready we will update this thread.
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 |
| [2018-08-03 03:07:40] |
| Richard Chinn - Posts: 28 |
|
Please bear with me and give me a chance to show you what is happening! There is a bug! I respect what you do and this is an EXCELLENT program. I am absolutely sure that you guys and girls are much smarter than I am about this stuff! I know you are bombarded with lots of stuff. I do read the support board but, I would not be so persistent if I wasn't sure myself that there is an erroneous action taking place. From your last post: If sc.SellEntry is giving an error, then there will have been no order submitted. We verified that. The "bug" is NOT that an actual order was or was not placed, the bug is that the displayed information on the chart shows an order that did not happen. I did not say an actual order was placed. I said an order is displayed on the chart. (Like a position was initiated. That is the bug I am referencing.) My code has nothing to do with the issue I am talking about and I am not looking for any sort of debugging help. I am trying to help you understand an issue with SierraChart. So here is what I did to prove it for you: I deleted my Sierra Chart directory and downloaded the program again. It is version 1785. So I am working from a completely clean install. The only changes I have made to the settings are: Trade>>Show Order Fills Trade>>Show Orders And Positions The snippet below does make sure that sc.AllowOnlyOneTradePerBar is set to true. I opened a 1 minute chart for the S&P500. I made NO changes to the chart or any of it's settings. I'm on Rythmic data service. I wrote this short function (No fluff whatsoever) to prove what is happening: #include "sierrachart.h" SCDLLName("EntryTest") SCSFExport scsf_EntryTest(SCStudyInterfaceRef sc) { SCInputRef enabled sc.input[0]; s_SCPositionData PositionData; sc.GetTradePosition(PositionData); if (sc.SetDefaults) { sc.AllowOnlyOneTradePerBar = true; sc.AutoLoop = 1; sc.FreeDLL = 0; enabled.Name = "Enabled"; enabled.SetYesNo(false); } if (!enabled.GetBoolean()) return; s_SCNewOrder NewOrder; NewOrder.OrderQuantity = 1; NewOrder.OrderType = SCT_ORDERTYPE_MARKET; NewOrder.TimeInForce = SCT_TIF_DAY; if (PositionData.PositionQuantity == 0) sc.BuyEntry(NewOrder); else if (PositionData.PositionQuantity >= 1) sc.SellEntry(NewOrder); } I ran this on LIVE data, SIMULATION mode. You can look at my chart, generated from the function above, http://www.sierrachart.com/image.php?Image=1533264496906.png and tell this is clearly not correct, at most we should see no more than 2 fills per bar, 1 BUY and 1 SELL, but PLEASE run the snippet for yourself, you can see it is a complete function with NO fluff whatsoever. I noticed running this snippet without any type of delay that the program will momentarily display a "Not Responding" message which does clear after several seconds. My Trade journal correctly shows orders as Order Sent | Open | Filled in the Order Status column. The additional displayed but not real orders shown on the chart are NOT listed in the Trade Activity Log. This is what I expect because an actual order was not made and should not have been made because only one trade per bar is set to true. I hope this is clearly presented so you can understand the erroneous information displayed on the chart is the problem, not that an actual order was not placed. Thanks Richard |
| [2018-08-03 04:49:37] |
| |
|
We will test that but the reason for this: I noticed running this snippet without any type of delay that the program will momentarily display a "Not Responding" message which does clear after several seconds. Is that study function is doing processing on all of the historical bars and may be generating a lot of log messages. You need to add a check to not do any processing when sc.IsFullRecalculation is true. We can see our examples do not have that check. We will need to update them. We are quite certain that your conclusions are not correct. We tested your system and sometimes we do see what you are seeing: http://www.sierrachart.com/image.php?Image=1533271676928.png We do sometimes see more than two fills on the same bar but that is just going to be a case of the actual timing of the fill itself. We would have to look into that to understand that better. We do not think it is a case, where the triggering itself is actually occurring for each order action type, more than once per bar. But we would have to verify that. And all of those fills are in the Trade Activity Log. There is no way we can believe otherwise. We clearly see them. We can do a remote assistance session and show you. Never in the history of Sierra Chart has anyone ever reported this and we have never seen this: The additional displayed but not real orders shown on the chart are NOT listed in the Trade Activity Log. 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: 2018-08-03 05:07:21
|
| [2018-08-03 05:00:43] |
| |
|
We do sometimes see more than two fills on the same bar but that is just going to be a case of the actual timing of the fill itself. We would have to look into that to understand that better. We do not think it is a case, where the triggering itself is actually occurring for each order action type, more than once per bar. But we would have to verify that. Okay we determined the reason for this. Your computer's clock is not in synchronization with the data feed. We will see if we can do anything to improve upon this to prevent this kind of an 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: 2018-08-03 05:01:13
|
| [2018-08-03 05:23:56] |
| Richard Chinn - Posts: 28 |
|
Thank you! A remote session isn't needed. My whole point was to show you a duplicatable situation that appears incorrect, more than two fills on the same bar, that could be a little bug in a part of the program. I agree that a clock issue is entirely feasible. Just for your information I do have my clock set to periodically sync with the server though I did not change that setting when I ran the above test because of downloading a new copy of Sierra Chart. I am just glad we were finally able to both see the issue! I appreciate you guys! The program is AWESOME! That why its important to me. Richard |
| [2018-08-03 05:32:13] |
| |
|
We are quite certain it is simply just a fill timing issue. It is not a case where there is more than one order action type being allowed on the same bar. We are implementing a solution now to the fill timing issue. But even this, does not completely solve the issue. it can still occur due to the chart update interval setting and also when evaluating bars on a close.
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: