Rogue trades ? How to start AutoTrading !

Dear Team, Dear all,

(first post, so be gentle with me somewhat )

I must be doing something wrong, or possibly there's a bug somewhere, but ... look :
What I try to picture here is the trade you see in the left which is without Broker part of it, and the others which do bear their broker part. Zooming in to clarify :
So we have the "broker" arrows and the MC arrows. The broker arrows come along with the @ price and the tick triangle.
Here is a part from earlier tonight (same day as the picture above) :
These are all without Broker data - hence not real trades.
Now on to the real issue I have with this :

This is in AA mode, which is all fine for me. But when I start AutoTrading, the real trades only start to occur when such a rogue trade exits. Thus, back to the first picture, I am sitting there waiting for whatever it is I can't see, until finally "some" exit occurs and the Live trading begins.
N.b.: To me it seems that as long as no Live AutoTrading is in order, this is just forward testing BUT which would not be entirely correct, because normal forward testing would remove the "backtest" trades from the chart, which clearly does not happen here.
FYI, this does not bring any solution with all the combinations I tried :
... which in this case is more complicated because of the here loose running trade which I should kill first before AutoTrading tries to deal with it. So why do I show this latter ? well, because it is always involved; it still is so that rogue trades are present and I need to deal with them first. Ehh ... How ?? This part summarized, I can't let my Strategy quickly kill that open trade because it won't get in anyway, waiting for a rogue trade to finish first ... which could be in a DD for a day. Side note : I don't even want to throw out such a loose running trade - just start-through the Strategy (ehm, as quickly as possible).

I am not asking for solving this bug - if it is a bug in the first place.
But I do kindly ask for a work around which someone may know ? Some kind of workflow that I could apply ?

If nobody has ever seen this, then my hint for MC would be : please look into the separate Bid and Ask streams which I use. As @Kate may recall, something was amended for me there.

Thanks !
Peter

ah ok, chatgpt was able to explain their problems to me, I couldn't figure them out from their extensive text myself, so their problems are:
1. Rogue Trades: Peter sees "rogue trades" on his chart, which are without broker data, which means that these are not real trades.
2. AA Mode (Automatic Trading): When you start autotrading, the real trades only begin when these “rogue trades” have ended.
3. Forward Testing: During forward testing, these “backtest trades” remain on the chart and do not disappear as expected.
4. Problem when starting autotrading: Autotrading cannot start because the strategy is waiting for these "rogue trades" to finish first.
5. Manage ongoing trades: Peter doesn't want to have to manually exit an ongoing trade before automatic trading can start.r?

So as far as I know, if it is switched to live trading the script (signal/indicator) should be recalculated. Accordingly, I assume that you are not initializing something correctly in your code so that data persists when switching.

You should initialize your values ​​in the protected override void StartCalc() method. Alternatively, the protected override void Destroy() method could possibly help.

I understand what you're heading for, but I can not imagine anything my StartCalc (or Constructor or anything) could do to clear any old running code (that's what it comes down to, I think ?).

Maybe some emphasis to AA mode : Opposed to SA mode, AA mode lets MC operate Asynchronously from the Broker. So MC has a life, and the Broker has another, and both should work synchronously (very much depending on your order types), but without any guarantee.
SA mode (which is what most will be using), works synchronously with the Broker and one shouldn't worry about all orders having the same state as MC has them (because MC reads them from the Broker data).
(at least that's my perception of it al).

I feel that the whole issue may be triggered by using AA mode.

Anyway ... are you saying that e.g. the Destroy is executed when AutoTrading starts (program gets kicked out and is restarted) ?

Anyway ... are you saying that e.g. the Destroy is executed when AutoTrading starts (program gets kicked out and is restarted) ?
: https://www.multicharts.com/trading-sof ... Calculated
I'm not 100% sure myself, as it's not described anywhere what happens during the transition from backtest to autotrading, but I think it behaves like in the link posted here (destroy is described at the bottom)

Unfortunately, I can't test this because I don't have a live trading account. But you could do the following: you can insert the destroy method as an empty method and then write the following lines of code in it, which you can also write in your other methods to see what happens when you switch between the backtest and live trading . You then just need to look in the output window of the powerlanguage editor. with you can clear the output window .

I've just tested it myself, the destroy method is only called if you completely remove the signal from the chart (so that it is no longer displayed under "format signals"). Just removing the tick there isn't enough to call the method automatically.

I found the following from Josh, it actually seems to be the case that the orders remain open when switching between backtest and live trading, maybe the Boolean condition in your code will help you cancel the orders when switching to live trading:

Environment.IsRealTimeCalc

https://www.tradingcode.net/multicharts ... ior-close/

or

I probably confused the destroy method with the stopcalc, I actually only use it as a precaution to desubscribe to events. So there might be another option to call up the Stopcalc method manually before moving on to live trading https://www.tradingcode.net/multicharts ... rice-data/

I hope I could help them. Since I don't have access to your setup, I can only help you with coding problems and workarounds. If there are technical errors in multicharts itself, you would otherwise have to contact support. If necessary, they can also access their PC in live chat and analyze in more detail what the problem is. I hope I understood your problem correctly:
I would actually have expected that orders from a backtest should be deleted when switching to live trading. I would therefore interpret this as an actual undesirable behavior and it should be fixed from the multicharts side.

Thanks a lot for your insights. I think it gives me sufficient ideas to work out;

It is my idea to go the following route :
Have an input parameter that says "Live or Backtest". Then right prior to Live, I set that parameter to Live and close the "Format" form. That will force a reload internally, while the code now anticipates If Live - IsRealTimeCalc .
Now it should not start up a backtest as its first thing to do, and thus won't interfere with a first next Live trade as I described (clarified by your ChatGPT sauce ).

------------------------
Observing this solution, makes me wonder whether my normal workflow is as should - and I wondered many times whether it is in the first place. So :
I'm having a code in the editor (Visual Studio, but alas), apply changes, do some optimization etc. etc., then wait for the moment to press the AutoTrade button (AA in my case). This already smells to wrongness in my view, because I'm not separating my Test from Production formally. It's in the same Workspace and all, and it should not be like that. Still it is a kind of hell to maintain two "spaces" for this because of the time it takes to set up one chart alone (and have that redundant !), not speaking about the cpu cycles it consumes. Still, if I'd dunk my production-ready version in there without the IsRealTimeCals solution, it will readily start back (and forward) testing.
But everybody should be bugged by this ? unless it bound to the usage of AA mode after all.
Anyway, if someone has an idea of a better workflow regarding this, I'd be happy to read.

Unfortunately, I'm not entirely sure if I fully understand your problem. However, here is how I manage it: I use one PC for programming and testing, and another for live trading. I'm not entirely certain, but usually, code changes are only applied to studies directly when they are not in use.

Another approach you could consider is the following: Simply save your workspace/desktop and open MultiCharts a second time. Now you have the opportunity to make changes to your code in Visual Studio. As long as you do not save, the code will not be applied to the running MultiCharts programs. If you still want to test your code, go to "Debug" -> "Attach to Process" in Visual Studio and select the second instance of multicharts.exe from the list (recognizable by the process number that appears after starting the second instance of MultiCharts). You should now be able to test your changes independently of the first instance of MultiCharts. You just have to make sure not to save - although, as mentioned, studies in use should not be applied to running trades anyway (unless you force compile in the PowerLanguage editor).

Of course, this requires additional computer resources. Personally, I save my studies in a Google Drive folder and transfer them to another PC when I want to continue working there. I have also tried GitHub, but this doesn't seem to work well with MultiCharts - hard to explain: I was often told that the versions did not match, which is very annoying when you have to re-match everything each time. MultiCharts seems to change something each time it opens, so the code base of the studies is no longer recognized as identical.

If you don't like long posts - please just skip.

Great stuff. Thank you very much for that.

I hate GitHub anyway (it barely can do what we made ourselves for the same purpose), so that can't be a problem.

The PC's/Servers etc. set up is something I am working on right now. Not sure yet how bad it is to go offtopic - I usually hate it myself. So maybe it is better to open a new thread for that later. Anyway, in this first topic/thread it could be nice to announce that my professional life consists of "performance" in general. Know the Windows OS from inside out and such; was working yesterday on a OS fully from RAM, to give an example (not RAM-DISK, but RAM) - with the note that such an OS is a factor 13000 more lean to begin with (outside of loading from RAM).
All this stuff for another thread - anyway it is great fun.

Unfortunately, I'm not entirely sure if I fully understand your problem.

"Problem" would be too harsh. But if I tell you that setting up a chart may take 45 minutes, then you may start to grasp what all could be issues suddenly, just because of the time it takes. This is all about MC anomalies (which I don't complain about at all) but cause me "swimming" somewhat in the general setup. I will give you one example which actually is a struggle (no need to solve it, really !) :

So I have this one month worth of tick data. For Testing this is fine, BUT once in the Workspace it consumes quite some CPU cycles to maintain it (this is just how MC deals with it - all fine). So what do I do ? I minimize that chart to only today (thus one day worth of tick data). Now, that takes MC a nice 10 minutes or so (why ?!?). After that all is fine, and my "production chart" is lean and ready for production. But wait, I have more feeds in there, and they all need to be minimized to this one day. So there we go again - again waiting. And this can't be done in one iteration - all have to be done per piece, and instead of waiting 45 minutes and do something else, it is 3 times waiting, plus some general overhead because all is slow with tick data (1 tick). Hey, try to change from Future Contract ... ouch.
Meanwhile I should ditch that "test" chart because in there all is still happening with the one month of tick data; one thing - I can shut off the forward testing there by just not having a Strategy active. Great. Now I can't test further (but I read your post with the two PC's which was my plan already anyway).

Please keep in mind : this was one example.

So yea, have two PC's at least, have the backtesting module so both can be used at the same time, or simply buy two licenses.

I fully understand what you all propose. But it is easy to lose the oversight.
Part of my "problem" will be that I backtest alright, but that I never trial anything in paper or such. Thus, my testing is in Live, making it an ad-hoc operation, continuously. The being able to kill the Strategy because it can be started-through comes very handy, but not if other for that required stuff does not work. Hence this thread ...

No complaints again, but with MC a lot seems to be upside down (maybe I am myself ). To me it is obvious that with all the n:n relationships the user interface becomes confusing, but it merely is about all what is always recalculated while I want to perform a next step first. Hence the example of the several feeds combined with the time it takes to process them. If I press close on the Format form, I probably do that because all is modeless edit : I meant Modal and I need to arrange for something else I can't reach otherwise (like a revisit of the Optimization Report). And THUS MC starts the calculations. I know, I could have unchecked the Strategy from being operational, but hey, our live consists of 1000 clicks per hour, and at some stage it becomes uncomfortable to think of all.
"Let's restart MC to see whether the sluggishness goes away and the memory will be back to normal proportions", but *know* that you will lose 30 minutes in the first place.
This is all newbie stuff, which I just am in this environment.

I am happy as it is because MC does ALL I like to do. And bugs are there to work around.
I love reading your contemplations - so thank you for that (including the great hint of attaching VS to another MC instance).

Of course I don't know your exact setup to judge where speed can be obtained. I myself have 2 PCs, one for very long backtests and one for programming. Even if you have two PCs, you could simply go offline on one and then start Multicharts with the same license on another PC, but Multicharts will only work for a while without access to the license manager on the first PC (unfortunately I don't know how at the moment long it is - but maybe it's enough for your purposes). I have 2 full licenses, just ask support for a discount, or wait for something like Black Friday deals for Thanksgiving.

I've also thought about running MS purely in RAM, maybe I'll look into it again at some point. The problem with multicharts is that it is not able to decompose time series and therefore always has to happen one thing after the other (there are good reasons for this that have already been explained in another thread). Everything takes a correspondingly long time. What should fundamentally increase the speed is a fast SSD, especially when loading (offline?) data. But if they already have the data in ram, I wonder why it would take long. But there are already threads here about performance. If you use a lot of charts, a CPU with many cores is an advantage; if you only use one, the speed in MHz should be more important.

I've also been thinking about outsourcing calculations to the graphics card, but unfortunately I haven't been able to get Tensorflow to run in multicharts so far. (I've been working with neural networks and tensorflow is heavily optimized for graphics cards).

Maybe take a look under Preferences -> Data: maybe go into offline mode and you could also try currency conversion. Under Preferences ->Misc you could consider moving your data to another drive. (The emptier a drive, the faster the data should be found). And fewer calculations and drawings could also increase speed. Something like : if (Bars.LastBarOnChart)
{

} might also help in the backtest.

By right-clicking on the chart and using format instrument you should be able to add several symbols to the chart at the same time, but it is true that the loading times for tickcharts are long! So for me, several years of tick data were loaded in maybe 2-3 minutes. Maybe also check the cache location again and perform “flush cached data to database”. If you always use the same settings, you are loading the symbols programmatically
https://www.multicharts.com/trading-sof ... DataLoader

This is indeed what helps against the waiting of "rogue" trades, which as we know are just backtested trades without me backtesting; it just happens like that when we activate the Strategy (Signal) by checking its checkbox and press Close. Please note : this is part of the MC procedures which think a little bit too much for me (and you and everybody) as I can't determine myself when to backtest and wait for the calculations to be done (which would be a sheer pain with several months of tick data and tick processing).
This is remedied by
a. As few data as possible (like the last day only - MC, what about "nothing" except for the required preload ?) ;
b. Force the Strategy into RealTime mode.
Ad b.: As soon as that's detected, the "backtest" trades disappear from the chart - I hope I saw that correctly (not many chances to observe all, once trades are running - just need more opportunities to observe the behavior).

This now at least starts trading right away.
It also allows for the now better observation of what happens with that form asking for where the position to take from (broker, chart, just enter something). This is because it now readily does what you want, instead of waiting for a "backtest" trade to finish first.
I think MC should really change this way of working. Just for a next person who doesn't comprehend this out of the box.

Later I will add that mentioned Parameter (Live/Test) so I could backtest with the same chart, if needed. -------------------

Yesterday I wrote a post of a mile long about PC stuff, which I did not post - but instead ordered for a shipload of PC stuff which I now have here and will implement over the weekend. It will be a Gold 6230 based machine for backtesting (already had that) and a 14900KF for production. Or maybe the other way around - must see which behaves best where.
Either will run at a most lean OS which I produce (configure) for other reasons - but thus have that - implying that 13000 times less activity (see ProcessMonitor) I mentioned earlier on (this is mostly about eliminating LI, II, II cache communications). Probably all way overdone, but why not. Although it can, I won't load these OSes into RAM and boot from there. This feels more hindering than be beneficial. The lean OS is way more crucial.

Again, thank you for your considerations and insights - the "rogue" thing is luckily solved.