Don’ (re)start your Autotrading Systems for now in Live
Forums › ProRealTime English forum › ProRealTime platform support › Don’ (re)start your Autotrading Systems for now in Live
- This topic has 1 reply, 1 voice, and was last updated 2 years ago by PeterSt.
-
-
08/02/2022 at 7:28 AM #198329
(or do as you please after reading this)
N.b.: This problem is handed to PRT support accompanied by a link to this topic. It is related to the Live environment (for Demo see more below).
The original exhibit of something being wrong is written here. But this appears only an exhibit while the real problem must be elsewhere. This is my conclusion after a full day of testing, yesterday.
The problem
Since the June 22 2022 version (or later with invisible updates), Systems perfectly working before, now fail somewhere;
Systems which ran for months (over 800 full trades) don’t behave as should any more, once they are restarted today.
In my case it exhibits as Stop and Limit orders not coming through any more (see link above). But after close observation it appears way more complex;
This small outlay below is totally irrelevant to the issue, and only explains how difficult it will be to troubleshoot and how anything can go wrong now in anyone’s System. So please don’t ask questions about this little text below, as it is unrelated to whatever the issue is.
The relevant code performs a transition from Trailing Stop to normal pending exit code (Stop and Limit). To perform this transition, (obviously) all kind of If’s and settings etc. are performed. For example, the Gain has to be sufficiently high and you can imagine all sorts of code to determine that. Of course there is much much more like being OnMarket in the first place, whether this stage of pending stops already has entered or not and well … anything.
So in latter “anything” something does not work any more.
What has been the most decent way to check whether it is indeed changed behaviour at the PRT side of things ?
Easy : Stop the Autotrading System, and restart it. It worked for many weeks, and now it fails.Additional checks : With everything I do I have backtest (debug-) data and graphs, and that data and graphing still shows all as it should be. This immediately imposes the problem for real, because where graphs tell that this transition takes place, in reality
a. the still running old systems behave exactly like that;
b. the newly started same systems don’t enter that transition and thus don’t change state of the exit system (the backtest does and will exit when appropriate).#a above implies that I can run the old and new same systems alongside, which is so indeed. On one side this makes the issue even more clear but on the other it vaguens the happening(s), like arrows and crosses all over the place, not really being sure which is which (bug #xxx (didn’t look it up) causing that the labels of the systems are hidden because of a wrong Z-order). For this reason I now set up such a System in Demo, not even knowing yet whether the issue exhibits there. If it does not, PRT could use that data for comparison; if it does, I can use it to very easily and clearly show the difference (which currently, in Live, is hard).
Testing is tedious because 1. a trade must happen, 2. it must sufficiently go in the direction of winning (which is not always so 😉 ) and it could take hours before it (may) lose and has to wait for the next trade, re-iterating to 1.After I can clearly show what happens (I assume I will succeed in that), I am clueless on how to attack this problem. This time I would be prepared to share my code with PRT engineers (via the Help system), but I see no way how they will be able to trace what goes wrong where. So PRT, please, consider a rollback of whatever you did with the June 22 version, OR carefully go through your changelog and see what possibly can cause this. It won’t be about the ordering system (the original topic – see link in the beginning of this post – suggested that) so it even could be an If statement not working out. It could be as bad as suddenly respecting parentheses properly where I forgot a pair all together.
PS: of course I should add my ever so (not so) funny bug number : #398.
1 user thanked author for this post.
08/02/2022 at 5:36 PM #198370I am posting this as soon as possible, but without 100% guarantee that all makes definitely sense :
First of, it seems that I could solve it for Live. Secondly, in Demo I have it now running with ProOrder failing in the same fashion while Forward (Back)Test running fine. In Demo I run the unchanged situation as of this morning.
In Live I changed things with the focus on TradePrice – mainly the “when” of its dtermination. This requires somewhat more tricky stuff as it tries to solve the (inordinate) situation of the factual impossibility to normally determine a change of trades when the Exit and Enter happen in the same bar (this never exhibiting Not OnMarket hence no decent possibility to reset things).
I still don’t know what the cause is, but I set this up differently, that out of all FIRST making the Live trades OK but the Backtest wrong (so go figure). But from there I could see what to change more and now backtest is equal to live trading again, plus live trading occurs as it did prior to the June 22 version.
I made a Technical Report of the situation in Demo which is nicely isolated (and still wrong) so I really hope the PRT engineers can deal with this now with the hints around TradePrice and some more in the code I pointed at.
Let’s softly say that if people did not try to solve double in-bar trades (and resetting stuff in between trades), they probably won’t be affected by whatever it exactly is anyway.
Merely for support :
Below a small screenshot of Live, where the red rectangles (pending stops of Live) now resemble the pink crosses (pending stops how forward testing shows them). The solitude trade events you see further are from an other system.
The second screenshot is from Demo, where “Live” and Forward Testing live their own life – see the start at the blue and green arrow on top of each other (the “Live” never exits as its pending stop never emerges – eventually it will run into its trailing stop – which can still be profitable) – both being the same system and which ran fine prior to June 22.I hope I don’t have to recall this all, later.
-
AuthorPosts