Keltner channel LE not working correctly?

First, a few questions to understand:

Are you using the original Multicharts signal?
Or have you modified them?

Do you have a problem setting the stop buy order or executing it?
From your picture I would assume that the stop buy has only been placed but not yet executed.

and why is the stop order named stop loss? Do you want to make a new long entry or close your short entry?

When exactly was the stop placed? Add the attached line of code: directly above your buy order code line, then you should be able to see in the chart when the order was generated, perhaps this will increase your/my understanding of the problem.

Code: Select all

DrwArrow.Create(new ChartPoint(Bars.CurrentBar, Bars.High.Value), true);

In the original code, an offset of 1pip is used for the stop order. The execution itself can also take place later after the stop has been triggered. And as far as I know, the stop order then becomes a market order that is executed at the next available price. This can also be significantly higher.

ah, ok, so the stop is only misplaced once when you switch to automatic trading? and then no more?

I'll take another look, I'm currently updating Multicharts.

i think your right: https://www.multicharts.com/trading-sof ... Channel_LE

I think it may be due to the transition from backtesting to automatic trading. Someone here recently had a problem like this, so can you answer my question, does this also occur with subsequent orders?

I mean: when you turn on automated trading, the stop order is generated immediately?

I'm wondering about the name of the stop. Do you have any other signals or indicators active?

For me it is called “KltChLE”, at least in the back test.

Therefore my question was whether if the stop order was reached once and then a new stop order was generated, whether it would also be placed incorrectly.

I suspect that the stop order does not come from the Keltner channel, but either from the backtest or from another strategy

I mean: when you turn on automated trading, the stop order is generated immediately?

I'm wondering about the name of the stop. Do you have any other signals or indicators active?

For me it is called “KltChLE”, at least in the back test.

Therefore my question was whether if the stop order was reached once and then a new stop order was generated, whether it would also be placed incorrectly.

I suspect that the stop order does not come from the Keltner channel, but either from the backtest or from another strategy

I only have the keltner channel signals applied.

When I turn on automated trading in portfolio manager, I see that the stop order is placed on the exchange immediately. Also, the screen shot I sent was non executed stop buy order on the exchange and not Multicharts so that is probably why it has a different name.

I mean: when you turn on automated trading, the stop order is generated immediately?

I'm wondering about the name of the stop. Do you have any other signals or indicators active?

For me it is called “KltChLE”, at least in the back test.

Therefore my question was whether if the stop order was reached once and then a new stop order was generated, whether it would also be placed incorrectly.

I suspect that the stop order does not come from the Keltner channel, but either from the backtest or from another strategy

I only have the keltner channel signals applied.

When I turn on automated trading in portfolio manager, I see that the stop order is placed on the exchange immediately. Also, the screen shot I sent was non executed stop buy order on the exchange and not Multicharts so that is probably why it has a different name.

Based on your new description, I can't yet rule out whether it's a multicharts/indicator or a broker problem. Of course I can only help with programming problems in Multicharts. Otherwise someone from multicharts has to answer here or you go to the live chat.

viewtopic.php?t=54379

I wonder if you have the same problem as described in the following forum post. If so, you should actually contact the live chat, as this seems to be a common problem. Perhaps Multicharts can then integrate automatic deletion of old "backtest orders" as a function into Multicharts.

Prior to finding the reference to my own thread (Rogue trades) I already thought to respond. So regarding the subject in this thread here (Keltner channel etc.) I hope to contribute with this :

The activation of Autotrading goes in a way which is (for me) weird, to say the least. First thing what happens (or seem to happen) is that from the moment you activate Autotrading, all the bars in the cache will be traversed for a reason unknown. My idea about it is that first the "backtesting" part is executed, and when finally the current bars are reached, Autotrading may commence for real. If you'd observe the CPU usage, you will know when this "preprocess" is finished (it consumes a lot more CPU than when all is ready to go).
Let me add that my Autotrading does not wait even one second before a position is opened - it does that right away. This allows to judge "anomaly" quite well.

Now here is where this "knowledge" meets the issue described in this thread :

At some stage the broker opens the position. This is always the first trade visible, and this is not the Strategy's trade. This is always later and when exactly is not clear to me, but later. This could be "minutes". Now, because I work in AA (Asynchronous) mode, this allows for this situation in the first place (with AS mode Broker and Strategy entries would occur at the same moment). But now the thing :
When the Strategy finally enters its own trade (with the notice that all the time Broker matches Strategy already (in the Order and Position Tracker)), this occurs at the price of the moment; would this price be higher (for a Long) then the Strategy only then starts to update its Currentosition.OpenProfit and thus the trade remains open longer than the Broker position would account for. This is how a first trade always is "off" with usually a much higher profit (this would be inherent for the Long position which starts like that for a reason (trend). Fact is :
This is incorrect.

What I now envision is that a SL etc. (formal TP too) would be submitted immediately while in your case (AS mode assumed) the real Entry is similar to what I encounter : thus later, when in my case the Strategy would enter.

The whole thing seems too complicated to even begin announcing it as bug (because how to mimic it, unless with real trading), but someone over at MC should be able to reason it out.

In addition, I feel that this is related to how the EnvironmentIsRealTimeCalc does its thing, which you don't need to be using in the first place. After days and days of observing this all, I now think that this property (or function) switches to True once the real Autotrading commenced (which is in my case when the Broker trade enters). This property / function lags because of the ticks (could be 10K ticks per second) *AND* the system is again disturbed by high CPU usage when the Autotrading commences (this higher CPU usage will settle down).

I did not work on the solution of this issue, because it is all with very indirect effects. But I already do know about some other way around : if I replace in my very case the EnvironmentIsRealTimeCalc with my self-made IsProd (read as IsLive) then no trade ever occurs. Also, referring to that other (Rogue) thread I am by now pretty much 100% sure that over there the same thing is happening, which is why I simply miss the start of it all and which is why I can't interfere with it. This is hard to explain, but the proper Output.Write tells it all easily. Thus, things occur during live trading, while the MC engine does not call the CalcBar() yet. The Rogue thing I solved, and for this SL etc. I would try to approach it the same.

My guts tell me that if you put the SL etc. under the condition of EnvironmentIsRealTimeCalc (True) that you will get there.
Ah, what helped me too is building in a System.Threading.Thread.Sleep(2000) before I start to do real things. This is to be build in CalcBar() (not in StartCalc) and of course only to be executed once (If "Initializing" and such). That at least allows me to show a "Start" entry in the Editor output and see things from the real beginning of the CalcBar calls.

Summarized (sort of)
Try to envision that you have conditions under If EnvironmentIsRealTimeCalc and that when you start Autotrading, all the bars in there are being processed with this property being false, until the current bar is reached. Then still all kind of arrangements have to be made, until finally this property gets true and you can formally do your thing (like putting SL/TP pending orders). In AA mode all is still vague, but I think in SA mode this should to the job decently. Do please notice that when all the bars have been processed (I deem this a necessity - so I accept that), it still will take many minutes before the first real trade occurs. You might think your conditions are not met for several minutes, but I jump in right away and thus can see it is not right (or at least it requires understanding which I can't yet).

Please respond with your own judgment and further findings, so we can hopefully all learn from it. Your issue and me writing about it helps myself as well.

(very) Generally I would put all the code under the IsRealTimeCalc condition. So all would be done in Backtesting mode, or all would be in Live Trading mode. In other words, be careful that you are not assigning value to variables throughout the processing of the backtesting part, which may have an inconsistent influence on the Live part of the process.

Btw, the "preprocess" of Backtesting when activating the Strategy is formal and written in the Programming Manual on paragraph 4.6.5 (found that myself yesterday). Why this is per se done like that, I don't know.

Edit :
Above is too simple, because it would not allow backtesting any more;
You can create an Input Variable e.g. Prod, and set that to true when you want to go Live. The code would then be subject to

Code: Select all

if (!Prod || (Prod && Environment.IsRealTimeCalc))

Code: Select all

protected override void CalcBar() { // N.b.: The If below is slightly different than // in my previous post but will do too. // But now all the "preprocessing" backtest stuff // will not occur in Live. if (!Prod || Environment.IsRealTimeCalc) // !Prod = Backtesting. { // All of your code to be executed per Bar goes here. } }

Clear a little now ?
Of course don't forget to set Prod to True when you apply the Strategy to Live.

The fact that MC herself does not respond in threads like these, really does not help.

An extension to the anomalies I encounter myself regarding this, is skipping (hence apply a return) all the bars/calls which are beyond the current date and time. Pseudo code :

Code: Select all

if (Bars.DateTime < DateTimeOfInput) // DateTimeOfInput = ** return;

**): an Input of the time today which is e.g. 3 minutes past when you start the Strategy, allowing for all the bars in the cache to be skipped up to the current point in time.

I can't tell how this cooperates with your situation of necessary preloaded bars for calculating averages etc. which may require x minutes as well, and which must be allowed to calculate.
Again I realize how vague this all is to explain. But it is MC who needs to have their act together in the first place. I can only hope this helps you.

The fact that MC herself does not respond in threads like these, really does not help.

An extension to the anomalies I encounter myself regarding this, is skipping (hence apply a return) all the bars/calls which are beyond the current date and time. Pseudo code :

Code: Select all

if (Bars.DateTime < DateTimeOfInput) // DateTimeOfInput = ** return;

**): an Input of the time today which is e.g. 3 minutes past when you start the Strategy, allowing for all the bars in the cache to be skipped up to the current point in time.

I can't tell how this cooperates with your situation of necessary preloaded bars for calculating averages etc. which may require x minutes as well, and which must be allowed to calculate.
Again I realize how vague this all is to explain. But it is MC who needs to have their act together in the first place. I can only hope this helps you.

The fact that MC herself does not respond in threads like these, really does not help.

An extension to the anomalies I encounter myself regarding this, is skipping (hence apply a return) all the bars/calls which are beyond the current date and time. Pseudo code :

Code: Select all

if (Bars.DateTime < DateTimeOfInput) // DateTimeOfInput = ** return;

**): an Input of the time today which is e.g. 3 minutes past when you start the Strategy, allowing for all the bars in the cache to be skipped up to the current point in time.

I can't tell how this cooperates with your situation of necessary preloaded bars for calculating averages etc. which may require x minutes as well, and which must be allowed to calculate.
Again I realize how vague this all is to explain. But it is MC who needs to have their act together in the first place. I can only hope this helps you.

I agree that Multicharts needs to get its act together. This is the third issue on their end that needs fixing and its quite frustrating having to deal with such issues, especially for the price that they charge. It seems the current state of Multicharts does not work for crypto trading.