Support Board
Date/Time: Wed, 27 Nov 2024 02:34:52 +0000
[Programming Help] - Trade Management By Study failing to move target, but reports success
View Count: 384
| [2023-10-01 21:10:51] |
| j4ytr4der_ - Posts: 938 |
|
This has been really messing up the results of some replays I've been running. My TWConfig is set to move stop to BE+1 at 4 ticks gain (I think this stop-out is related). I'm adjusting the target by a subgraph. After the target is in place, it should not adjust at all so I have it set to adjust every N seconds, and set N to 100000 seconds. Most of the time it works correctly. The target is initially placed at 4 ticks based on the settings for the attached bracket, and then is instantly moved to the desired subgraph, and stays there until the trade is flat. But sometimes, the target goes in at the initial 4 ticks, and stays there. It is never adjusted to where the target subgraph is. I finally enabled logging for the TMBS study, and found that it reports that the order was moved, but in actuality it isn't! Here is a screen capture illustrating the chart and the log: https://snipboard.io/G0oCqX.jpg I've been chasing this down all day and have found a specific trade where it always occurs. On looking at the exact timestamps of the trade, I noticed that this is a case where a trade entered, moved the stop to BE+1, and was stopped out. Instantly (in the same microsecond), a new entry order was issued. This new entry is the one that fails to move the target. Here is the TAL showing the timestamps in question: https://snipboard.io/vSMqgi.jpg So something about the entry being at the precise moment of the prior exit, seems to prevent the TMBS study from moving the target, despite its logging believing that it did so. Any suggestions on if this can be addressed on my side, are appreciated. Or if there's something in the study that needs fixing, to know that would also be helpful. Thanks. |
| [2023-10-01 22:33:13] |
| j4ytr4der_ - Posts: 938 |
|
I can't verify/validate this but this feels like it's somehow related to the OCO group. If I set the TMBS study to move OCO Group 1, the target is not moved at all. If I set it to move OCO Group 2, the target is not moved at all. If I set it to move the Nearest, then it works/fails as described above. Might be nothing but, adding it as a data point.
|
| [2023-10-01 22:52:36] |
| j4ytr4der_ - Posts: 938 |
|
OK I've validated something. This is explicitly related to the exit and entry times being identical. I'm able to disable auto trading before the first trade exits, and as long as I re-enable it any length of time past the exit of the first trade, the next entry triggers and correctly moves the target as expected. So to be clear, there is a problem with the TMBS study, if a trade exits and another enters at the precise same moment. |
| [2023-10-02 21:23:30] |
| ForgivingComputers.com - Posts: 960 |
|
If the controlling subgraph isn't changing, leaving the update at 1 second doesn't hurt. It will not attempt the move if it is already at that price. Your large number may be forcing it to wait before it does the first move.
Date Time Of Last Edit: 2023-10-02 21:26:43
|
| [2023-10-02 21:43:30] |
| j4ytr4der_ - Posts: 938 |
|
But the subgraph does move, which is specifically why I have it set to a large number, so that it doesn't change. The first move always works perfectly UNLESS the new trade enters at precisely the same instant the prior trade exits. It's an unusual condition, but it can (and does in this case) happen in a scalping system.
|
| [2023-10-02 21:49:04] |
| ForgivingComputers.com - Posts: 960 |
|
You could create a new subgraph that doesn't move based on being in a position or modify the TMBS code to only work under your rules. Or you could just do your own order modification in ACSIL.
|
| [2023-10-02 22:42:49] |
| j4ytr4der_ - Posts: 938 |
|
Yeah, if I had the programming skills to build my own system in ACSIL I would just do that, but unfortunately I don't.
|
| [2023-10-03 16:53:45] |
| Sawtooth - Posts: 4120 |
|
I agree with @bradh: the TMS study will move a target to the price that is returned by the subgraph it is referencing. Using a long delay is unnecessary in this case. If the TMS thinks it has moved the target, it must wait the long delay to move it to the correct price. Use a formula in a Formula Column that returns the new target price, and reference that column/subgraph in the TMS study. |
| [2023-10-03 17:06:57] |
| j4ytr4der_ - Posts: 938 |
|
I think the point to the "long delay" is being missed. I don't want the target to EVER move once it's placed. That is why I set it so high. I want to ensure it is initially placed where it needs to go (the subgraph) and then never changes. I am NOT using a spreadsheet system.
|
| [2023-10-03 17:15:36] |
| ForgivingComputers.com - Posts: 960 |
|
Let me know if you would like a quote for a custom study with the simplest solution: A one-shot TMBS. I would be modifying the existing code, so it will be easy for me. Brad (at) forgivingcomputers (dot) com |
| [2023-10-03 17:19:49] |
| j4ytr4der_ - Posts: 938 |
|
Nah, I could probably manage to do that myself if I really felt the need. The whole point here is that there is an issue ONLY under one specific circumstance - if one trade exits, and another trade enters, at exactly the same timestamp, then the TMBS fails to move the target to the designated subgraph. This does not happen as long as the entry happens any amount of time after the prior exit. In that case, the target is moved as it should be, regardless of the update frequency (which is why I can have it set so high and have no problem except under this very specific edge case).
|
To post a message in this thread, you need to log in with your Sierra Chart account: