MultiCharts: Trading Software for Automated Trading and Backtesting

[Issue Description]

If:

1).your signal uses RecalcLastBarAfter & AllowSendOrdersAlways & IOG
and
2).your signal generates same limit order on each recalculation
and
3).your signal is applied to a 1-tick based chart

The limit order is supposed to be issued to broker only once and kept there unchanged until filled. However in real test, it will be cancelled and resent very frequently, almost on every tick.

You can use the following simple signal to reproduce the issue. Just set the Price to a price that will not be filled and RecalcDur to some value shorter than the tick incoming interval of your instrument.
You will see the limit order of same price and quantity get cancelled and resent in the order tracker window:



I am using the latest MC x64 v9.1.12587.400 with the following settings:



This is a big trouble to me because most instruments I am dealing with are in slow market. They usually have one tick incoming longer than ten minutes and sometimes even hours, but my strategy need to buy/sell them realtime based on other dataN. Therefore I need to enable RecalcLastBarAfter & AllowSendOrdersAlways & IOG in my signal.

If a limit order is generated and sent it will be cancelled if on a subsequent tick conditions are no longer valid for that order to be generated. If you had for example a condition to buy if var1 = close then when true, a limit order would be generated. But if on a future tick var1 <> close, the limit order would be cancelled. You either need to hold values so orders are not cancelled or use market on entry.

If a limit order is generated and sent it will be cancelled if on a subsequent tick conditions are no longer valid for that order to be generated. If you had for example a condition to buy if var1 = close then when true, a limit order would be generated. But if on a future tick var1 <> close, the limit order would be cancelled. You either need to hold values so orders are not cancelled or use market on entry.

Yes, I understand what you mean. But the problem I encountered is that the limit order is cancelled and resent even if it is generated every time when the signal is recalculated.

In my example signal, the "buy("Test8") 1 contracts next bar Price limit" command has no condition and will always be executed.

Hello howg0924,

This case is being studied by our development team.

Hello howg0924,

This case is being studied by our development team.

This is indeed a serious issue. I will now have to check if a similar issue occurs with stop orders. Henry please also pass this to the development team to check if it's OK with you. I will try to check myself when the markets are open in a couple or so days. I haven't yet upgraded to the latest release of MC - still on the one before it. I will attempt to check before the upgrade then after on my test machine.

I'm curious to hear what happened with this issue/problem after investigation. Is there an update on it?

The issue has been acknowledged and forwarded to the development team. As this is an architectural limitation and the fix is not trivial - it has not been yet targeted to any specific version.

I tried a test as follows: buy 1 contract then place a sell stop well below the entry.

With RecalcLastBarAfter(1) the Order and Position Tracker displays the stop order as stable when there is no activity (ie, no update tick). As soon as an update tick arrives the stop order is cancelled and a new one sent to the broker.

Without the RecalcLastBarAfter(1) the stop order remains stable regardless of whether there is an update tick or not.

So I also have confirmed there's a bug; a serious one at that and it needs to be fixed ASAP please!

If anyone can't wait for the fix, you can work around it to some degree at least by adding an instrument that's very liquid, and place it as data series 2 (or more if you are already using more than 1. I'm using the e-mini futures contract on GLOBEX as the secondary driver. A Forex instrument probably may be as good if not better. If you like you could add several to increase the frequency. Now my orders can be sent and checked more frequently than otherwise when the primary instrument is very quiet. Oh, don't forget to include [AllowSendOrdersAlways = True] in your study.

Update: Another thing. You have to reference the secondary driver even if you don't need it for computations. Otherwise the study won't update for some reason. I use:

value1 = barstatus;
value2 = barstatus(2);