Support Board
Date/Time: Fri, 31 Jul 2026 17:48:59 +0000
[Programming Help] - Attached/entry orders in ACSIL custom study intermittently not closing position in backtes
View Count: 12
| [2026-07-31 15:54:01] |
| User244885 - Posts: 1 |
|
I have a custom ACSIL study running in Chart Replay mode on MNQ futures (1-min chart). It submits entry orders via sc.BuyEntry()/sc.SellEntry() and I'm trying to reliably protect and exit each position with a stop and a target. What I've tried, and what happened: Entry order with Target1Offset/Stop1Offset attached, using SCT_ORDERTYPE_MARKET for entry — the entry filled, but neither the attached stop nor target ever triggered, even after price moved 100+ points past where they should have fired. Position stayed open indefinitely. Same attached-offset approach with SCT_ORDERTYPE_STOP for entry — identical result: entry filled, but stop/target never triggered. Same attached-offset approach with SCT_ORDERTYPE_LIMIT for entry — this worked once (a stop correctly closed a position), but on a separate trade, the same setup's stop never triggered even after price moved 300+ points past it. On another trade, the target never triggered even after price moved 1,000+ points past it. I gave up on attached orders entirely and switched to manually checking price each bar in code, calling sc.FlattenAndCancelAllOrders() when my own calculated stop/target level is reached. This mostly works, but now I'm seeing a new issue: some entries fill and then the position closes again on the exact same 1-minute bar, with no stop or target condition actually met (my code logs it as "Reason: OTHER" since neither of my manual checks fired) — as if something else is flattening the position immediately after entry. My questions: Are Target1Offset/Stop1Offset attached orders known to be unreliable specifically in Chart Replay/backtest mode (vs. live/simulated real-time trading)? Is there a setting (e.g., related to sc.MaximumPositionAllowed, sc.SupportAttachedOrdersForTrading, or order routing in Replay mode) that could cause a filled entry to be immediately reversed/flattened without any of my own code causing it? Is there a more reliable ACSIL pattern for "enter a position, then guarantee a stop and target actually execute" in backtest/replay specifically, that I should be using instead? I can share the relevant portion of my .cpp file if that's helpful. |
To post a message in this thread, you need to log in with your Sierra Chart account: