Serious Issue with Exits - Automated trading - no workaround  [SOLVED]

Questions about MultiCharts and user contributed studies.
vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Serious Issue with Exits - Automated trading - no workaround

Postby vking » 23 Jun 2011

Hello MC team,

As demonstrated in the remote session - orders submitted at the same tick - always gets submitted as OCO mode and in the event like - first target getting filled - it would cancel Second and third targets in the queue - though the conditions for them to stay in the queue are "Still" valid - they would first gets cancelled and re-submitted again as brand "new" orders. This is NOT the case with DOM based manual entries with Master strategy attached. in DOM based manual entries - everything works fine as expected.

Based on demonstration and further discussion with Dave/Katrin - I was asked to create a PM request on this.

https://www.multicharts.com/pm/viewissu ... _no=MC-454

Would you please review and see - if you can provide an option to customers - not to submit the orders as "OCO" orders - in addition to what you have currently - sync/async.

In it's current state - it's practically not usable for me for quick automated strategies -with multiple targets - where the targets are very close to each other.

PS: Tried with IOG=true as well allow multiple orders in same direction etc.

Thanks.
Last edited by vking on 27 Dec 2011, edited 1 time in total.

User avatar
Stan Bokov
Posts: 963
Joined: 18 Dec 2009
Has thanked: 367 times
Been thanked: 302 times

Re: Orders are always submitted as OCO in automated trading

Postby Stan Bokov » 24 Jun 2011

Thanks, we will review it.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 25 Aug 2011

Stan/MC Team - Was there any further status update on this request? It's been under review for sometime.

Thanks

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 30 Aug 2011

Stan/MC team - Any update on this?

Thanks.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 02 Sep 2011

Wanted to check this one more time to see - If I can get a reply on this.

Thanks.

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 489 times

Re: Orders are always submitted as OCO in automated trading

Postby Dave Masalov » 06 Sep 2011

vking,

Please describe how do you want this feature to be implemented, i.e. should it be implemented separately for entry and exit orders?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 06 Sep 2011

I am not sure - all I wanted is to have the behavior of the orders to be same whether the multiple target orders are submitted through strategy or through the DOM using master exit strategy.

With DOM:
- using multi target master strategy attached - When prior target orders are filled - the current target orders remain in the queue rather than first cancel and resubmit the order at the same target price.

With Auto trading:
- When multi-target orders are submitted at the same tick - with certain conditions - when the first target is filled - it also cancels the other higher target orders in queue(though the entry condition for those orders still being valid) and then resubmits again

All I want is to have some way of keeping the order active - if the condition for it is still valid ( should be treated an independent exit ) and the other events like lower target being filled shouldn't have an impact on this order.

If this would cause any issues with current way of handling the orders - if you can provide a flag or something to get the desired behavior - it should solve my problem. This is the only thing stopping me from using automated strategies in MC ( as manual DOM based exits - I can't mimic in automated strategies).

Thanks

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 06 Sep 2011

To clarify further - if you can ensure - the condition for the order to be in the queue - is preserved - as long as the condition for it to enter remains the same - it should solve this problem.

Looks like - for whatever reason - if the orders are submitted at the same tick( though different conditions) - if there are any position changes( could be due to any reason ) - they are first cancelled - conditions are evaluated again - and then resubmitted.

If this done the other way - if the order is in the queue - evaluate the condition first whether it can stay in the queue - if the conditions are no longer valid - cancel the order.

This would solve my problem - but not sure - whether it would introduce any issues to the internal core order handling functionality of MC or not.

Thanks

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 07 Sep 2011

Update: Discussed further on this with Dave and he is going to check with development about potential solutions on this.

For me any way of allowing the "exits" to be handled efficiently - based on the contracts/position at broker (even better - if this is possible if the contracts are entered either manually or through an en entry only based strategy - if this is too much to ask - let's stick to automated entry based strategy only for now) and not cancelling/resubmitting the orders again as long as the conditions to stay in the queue are still valid - this would be a great solution.

This is the only thing for me to stop using the automated strategies in MC at this point of time.

Thanks.

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 489 times

Re: Orders are always submitted as OCO in automated trading

Postby Dave Masalov » 13 Sep 2011

vking,

We have some additional questions:

1) What broker do you use?

2) Do you use a single signal for auto trading or several signals combined in one strategy?

3) Could you send us an example of your script for testing purposes?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 16 Sep 2011

Dave - Please see my reply below:

1) What broker do you use?
- I would assume the solution won't be broker specific but for argument sake - you can pick OEC.

2) Do you use a single signal for auto trading or several signals combined in one strategy?
- I would have multiple "entry" based signals - they would control ONLY the entries.
- One exit based strategy would be running on the chart - it's job is to check the position and close out the positions and nothing more than that.

3) Could you send us an example of your script for testing purposes?
- This is the simple example code I could think of : with properties set to : "Allow unlimited entries and exits per bar" to take care of the multiple exits.

As demonstrated - though the exits enter the queue as mentioned - as soon as the first target is filled second/third target contract orders gets cancelled and resubmitted again though the condition for them to stay in the queue are still valid.

Thanks.

Code: Select all

[IntrabarOrderGeneration = true]

Vars: intrabarpersist MktPosition(0);
Vars: intrabarpersist AEP(0);
Vars: intrabarpersist CC(0);
Vars: OneTick(MinMove/PriceScale);


MktPosition=Marketposition;

if LastBarOnChart_s and barstatus(1)=2 and MktPosition=0 then begin
buy 3 contracts next bar market;
end else begin
CC=CurrentContracts;
AEP=AvgEntryPrice;
if CC>=1 then sell 1 contract next bar at AEP+(6*OneTick) limit; // Third Target
if CC>=2 then sell 1 contract next bar at AEP+(4*OneTick) limit; // Second Target
if CC>=3 then sell 1 contract next bar at AEP+(2*OneTick) limit; // First Target
end;

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 16 Sep 2011

Updated Code - to show the entry/exit order tags and the order manager log:

Code: Select all

[IntrabarOrderGeneration = true]

Vars: intrabarpersist MktPosition(0);
Vars: intrabarpersist AEP(0);
Vars: intrabarpersist CC(0);
Vars: OneTick(MinMove/PriceScale);


MktPosition=Marketposition;

if LastBarOnChart_s and barstatus(1)=2 and MktPosition=0 then begin
buy ("LE") 3 contracts next bar market;
end else begin
CC=CurrentContracts;
AEP=AvgEntryPrice;
if CC>=1 then sell ("TT") 1 contract next bar at AEP+(6*OneTick) limit; // Third Target
if CC>=2 then sell ("ST") 1 contract next bar at AEP+(4*OneTick) limit; // Second Target
if CC>=3 then sell ("FT") 1 contract next bar at AEP+(2*OneTick) limit; // First Target
end;
Attachments
OrderExitIssue.jpg
As you can issue as soon as the first target is filled at 1212.75 - orders at 1213.25 & 1213.75 gets cancelled first and then resumitted again. I am unable to replicate the functionality of DOM with master exit strategy using EL.
(118.55 KiB) Downloaded 9431 times

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 16 Sep 2011

FYI: I have tried all possible options I could think of sync/async enabling broker events/real time position from broker etc - whatever I could think of - but so far unsuccesful to let the second/third target orders to stay in the queue when the first target order is filled.

Thanks

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 489 times

Re: Orders are always submitted as OCO in automated trading

Postby Dave Masalov » 16 Sep 2011

vking,

Thank you for the info. I have discussed it with the developers and here is their verdict: we will most likely implement this feature in the future, however there is no ETA at the moment.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 16 Sep 2011

Dave - Thanks for the reply. It's unfortunate that this feature (legitimate request as far as I see) - being post-poned.

Would you please let me know - when should I check back?

Thanks

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 489 times

Re: Orders are always submitted as OCO in automated trading

Postby Dave Masalov » 20 Sep 2011

vking,

As I wrote you above there is no ETA at the moment. We will most likely implement this feature in the future versions of MultiCharts.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 20 Sep 2011

Thanks Dave. Waiting mode at present..

FYI: until this feature is implemented - also requesting other members to see - if there is any alternate way to get this functionality :)

viewtopic.php?f=1&t=9222

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Orders are always submitted as OCO in automated trading

Postby waveslider » 22 Nov 2011

Vking -
If I understand your problem correctly - your limit orders are being cancelled and replaced each bar?
I am just beginning to run automated and noticed a similar thing. The limits are cancelled and replaced each bar. This is not good for order queuing - very very bad.
I think what we are looking for is being able to check the open orders at the broker, right?

TS used macros to do this type of stuff.

by the way does any one know a way to set a "show only" type of order (iceberg) with powerlanguage?

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Re: Orders are always submitted as OCO in automated trading

Postby TJ » 22 Nov 2011

With IOG off, the limit orders should stay if the order price is not changed.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 22 Nov 2011

waveslider - Yes, the issue is with multi-leg exit orders.

- They all go to queue as expected and can see them with the broker as well
- however when the first target order is filled - it would first cancel all the other limit orders in the queue( though the condition for them to stay in the queue are still valid) and then again resubmitted at the same price.
- MC team as well has accepted it as a limitation with power language but for whatever reason this issue is not being prioritized. There is no work-around for this issue.
- For further details - please see this PM request - which has the image explaining the issue.
https://www.multicharts.com/pm/viewissu ... _no=MC-454

Thanks
Vking -
If I understand your problem correctly - your limit orders are being cancelled and replaced each bar?
I am just beginning to run automated and noticed a similar thing. The limits are cancelled and replaced each bar. This is not good for order queuing - very very bad.
I think what we are looking for is being able to check the open orders at the broker, right?

TS used macros to do this type of stuff.

by the way does any one know a way to set a "show only" type of order (iceberg) with powerlanguage?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 22 Nov 2011

Thanks TJ. Unfortunately - with IOG on/off doesn't makes a difference to this issue at hand as the exit orders gets submitted as OCO and the very nature of OCO - it would cancel the other orders in queue when the first target order is filled and then resubmits the order at the same price again.
With IOG off, the limit orders should stay if the order price is not changed.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Orders are always submitted as OCO in automated trading

Postby waveslider » 22 Nov 2011

Even when limit price is constant, I have limit orders cancelled/replaced every bar... IOG is not enabled. Any other reasons this might happen?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 22 Nov 2011

waveslider - your issue seems to be different( and I don't have this issue with entries) and could be related to the way entries are coded.

if you can post the sample code - can comment on it.
Even when limit price is constant, I have limit orders cancelled/replaced every bar... IOG is not enabled. Any other reasons this might happen?

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Orders are always submitted as OCO in automated trading

Postby waveslider » 22 Nov 2011

ok. I need to see the signal trade real time some more to understand the order issuing. It is different from TS, but probably in a good way.

Have you learned a way to access the current orders with the broker ?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Orders are always submitted as OCO in automated trading

Postby vking » 27 Dec 2011

MC Team - Are you going to review this PM request any time soon? It's been close to 6 months this issue has been raised and there are no workarounds for this issue.

This is a critical core trading functionality and absolutely no work-arounds.

PM Request:

https://www.multicharts.com/pm/viewissu ... _no=MC-454

Thanks.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 03 Jan 2012

MC Team - Any update on this?

thanks.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 04 Jan 2012

Hello Vking.
We are considering your request.
Indeed it is an important functionality.
However we are currently focused on developing other features.
We will get back to you with an update as soon as there are any news regarding this feature.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 01 Feb 2012

Checking to see - if there are any signs to fix this issue any time soon.

Thanks.

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 489 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Dave Masalov » 02 Feb 2012

Hello vking,

Your feature request has been confirmed. The feature is planned to be implemented in one of the future versions. It is in the works at the moment.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 02 Feb 2012

Thanks Dave. "hope" to have this included in version 8 worst case :)

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 02 Feb 2012

Thought I had a fix on this, but that fix does not work: I can create separate exit orders for new bars (in one strat or in separate strats), but even with that, once the first exit is filled, the rest of the exits cancel forever.

Right now with Mirus/Zen-Fire, exit orders basically do NOT work in MC, so far as I can tell.
//---------------------------------------------------------------------------------------------------------
Additional Comment:

TO add color to this issue:
1). when using the vking code posted above, which he says cancels and re-ques so that the worst that happens is that you lose your earlier spot in the exit que at the same exit price (over and over again), which is bad enough; for me with this code (and an iteration that created a new exit on each new bar) with Mirus/Zen-Fire, once the first exit got filled, all of the remaining exit orders canceled and did not reappear: they died, gone forever.
2). using my own entry code and exit code strategies (and in separate exit code strat documents - new bar, new exit from separate exit strat), the same thing happens. the EVEN WHEN the exit code was manipulated so that there was only one exit created for each new bar, once again, as soon as the first exit was filled, all of the other exits died forever.

Willing to find a new way to do this or glad to be corrected, but as MultiCharts is right now on Mirus/Zen-Fire, Exits basically do not work according to conventional EasyLanguage coding standards - you get one exit only.

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 13 Feb 2012

Not fixed in 8.0. First exit fills, the rest disappear, but may reappear and SOMETIMES if price goes through the secondary exit(s), the exit is filled; other times not. Erratic, unpredictable behavior. See screenshot.

There is also a very serious issue when using separate, multiple STOP orders, non-IBOG (separate strat documents that use STOP and/or SetStopLoss): after the entry bar, all orders continuously cancel and re-que, which means you cannot use the system to trade.
Attachments
Limit Sell Order Not Filled..png
(73.1 KiB) Downloaded 9394 times

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 15 Feb 2012

Update: My Original PM request has been updated and this is planned for 8 beta 2. Eager to see this release to try out.

Thanks.

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 20 Feb 2012

There is also a very serious issue when using separate, multiple STOP orders, non-IBOG (separate strat documents that use STOP and/or SetStopLoss): after the entry bar, all orders continuously cancel and re-que, which means you cannot use the system to trade.
Have worked with Henry and Roman on this. And Tech Support with my code tried to duplicate the problem and could not. Thanks for the support. On further conversation with Roman and checking the Log entries in Order and Position Tracker, it appears that the problem is related to this:

[sidenote: since I had previously viewed the logs, I am a bit remiss that I did not make a connection regarding what the logs said and the apparent relation to the problem, but it would hardly be the first time that I did not catch something in EL/PL/TS/MC that, in hindsight, I should have/wished I had].

The problem happens with a SIM account, account balance say $50,000 - it is not a run to zero balance SIM account. I can place an Entry (Buy or SellShort) order for one (or more but one will do it) futures contract - the Entry is fine, but, as stated, after the close of the entry bar, I get repeated Send/Cancel/Re-issue of Stop or/and Exit orders.

Apparently the Stops and Exits are being applied against account margin, causing the account equity to be exceeded and the orders rejected. SO for instance, - SIM account - Long one FDAX contract in the overnight session (whatever the actual margin is I do not know, but presumably relatively high) - with one SetStopLoss Strat and and one Exit Strat with THREE (3) Exits caused Send/Cancel/Repeat (see screenshot - the SIM position was manually closed).

[Live account, other platform, I have never had a problem with the Exits - but I cannot provide any color beyond that.]

Live account this would be very bad. Very much appreciate it if you can tell me how to avoid having Send/Cancel/Repeat of Stop and Exit orders.
Canceled orders on FDAX.png
(147.91 KiB) Downloaded 9388 times

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 21 Feb 2012

Please come to our live chat 6.30 am – 10 am EST to investigate these problems with our engineers.
We will do our best to help you.

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 20 Mar 2012

Update: My Original PM request has been updated and this is planned for 8 beta 2. Eager to see this release to try out.

Thanks.
So are your Exits still getting put to the end of the que on every new bar or is it different with 8.0 beta2? Curious what you or others (particularly on Rithmic/Zen-Fire) are seeing.
Last edited by escamillo on 30 Mar 2012, edited 1 time in total.

SUPER
Posts: 646
Joined: 03 Mar 2007
Has thanked: 106 times
Been thanked: 84 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby SUPER » 21 Mar 2012

Update: My Original PM request has been updated and this is planned for 8 beta 2. Eager to see this release to try out.

Thanks.

vking,

Just wondering if multi-exits are working well with the new beta.

Will appreciate your feedback.

Regards
Super

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 03 Apr 2012

No different with Beta 2

This morning I have a open limit exit.

As soon as a stop order is issued (next bar), the open limit exit order is cancelled (for no reason) and re-issued.

At this point I am not using "intrabarpersist", which may solve some problems I have heard. Too late to try this morning.

THIS IS A BUG.

Dru
Posts: 107
Joined: 28 Aug 2007
Has thanked: 4 times
Been thanked: 171 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Dru » 05 Apr 2012

No different with Beta 2

This morning I have a open limit exit.

As soon as a stop order is issued (next bar), the open limit exit order is cancelled (for no reason) and re-issued.

At this point I am not using "intrabarpersist", which may solve some problems I have heard. Too late to try this morning.

THIS IS A BUG.
When additional stop exit order was added, the stop and limit orders must be in one OCO group, isn't it? Therefore reissuing was needed.
The feature "optimized orders flow" works for orders with same category (stop/limit) and with same direction (Buy/Sell). Example: multi partial exits by limit orders.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 05 Apr 2012

if the OCO is placed on Rithmic servers then it would be necessary, but Multicharts should be able to replicate an OCO without having to re-issue.

I will try to learn about "optimized order flow"

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 18 Apr 2012

Update on this issue:

I had a chance to test this out today.

- If I only deal with limit orders for exits - it's working as expected (with "Optimize Order Flow" Checked in autotrading tab)

However when "stop" also is introduced into the mix - strategy only submits One set of limit/stop combination rather than 3 sets of limits/stops ( for 3 contracts in hand). After the first target is filled(or stopped out) - it would submit the other set for second target/stop and so on..

Spoke to Andrew on this and he is going to check with development further on this and see how to handle this.

Thanks.


Update: My Original PM request has been updated and this is planned for 8 beta 2. Eager to see this release to try out.

Thanks.

vking,

Just wondering if multi-exits are working well with the new beta.

Will appreciate your feedback.

Regards
Super

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 19 Apr 2012

From WIKI page below:

https://www.multicharts.com/trading-sof ... utoTrading

Looking at the example 2 under Opitmize Order Flow section - This seems to be by design at present when Stop is involved(if only limit is involved - all the 3 limit orders enters the queue at the same time and execution is perfect). However the requirement is to send 3 OCO Orders at the same time to the queue through PL ( which is currently only possible using DOM based master strategy) and hopefully Andrew/MC comes up with some solution to this issue.

Example 2: The position at broker is +3. Strategy generates 3 sell limit orders and 3 sell stop orders. MultiCharts will send to broker 3 OCO group in the following sequence:
MC sends 1 stop order and 1 limit order with the prices most likely to be filled.
When one of these 2 orders is filled, the other is cancelled.
MC sends 1 stop order and 1 limit order with the prices most likely to be filled (among the rest 2 stops and 2 limits).
When one of these 2 orders is filled, the other is cancelled.
MC sends the last 2 orders: 1 stop order and 1 limit order.
When one of these 2 orders is filled, the other is cancelled.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 24 Apr 2012

Update on this issue:

- With current implementation of Optimize Order Flow - it has limitations about unable to submit multiple orders at the same time when stop is involved. As per Andrew - submitted another PM request for this. Please vote if you think this as a critical functionality.

https://www.multicharts.com/pm/viewissu ... _no=MC-930

Thanks

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 06 May 2012

It took a bit of doing, but Henry and Andrew finally some time ago convinced me that, for the Rithmic/Zen-Fire data feed at least, the way MC managing Exits and Stops is different than the way TS manages Exits and Stops, and works the way it is intended to work. Fine. I have re-written code [only have Exits to match the number of contracts filled & only the closest Stop is active] and things are quite good.

Regarding Exits: The issue of canceled and re-issued Exit orders is quite important, and the way it works now is at least sub-optimal and perhaps makes no sense: With 'Optimize Order Flow', you only get the CLOSEST Exit active; without 'Optimize Order Flow', all Exits are active, but after each one fills, the remaining Exits cancel and re-issue. The ES ques in particular fill up amazingly fast, are thick and it is without question an advantage to get your order into the que as quickly as possible and to keep it there and not go to the end of the que every time an earlier Exit gets filled. The preferred way to manage Exits is to keep them active: please give us that option.
Attachments
cancel-reissue exits on each exit fill.png
(63.44 KiB) Downloaded 9373 times
with 'Optimize Order Flow'.png
(48.74 KiB) Downloaded 9362 times

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 10 May 2012

I am still having the issue of limit orders being cancelled/re-issued when a stop is introduced or adjusted.

Using optimized order flow.

Suggestions or is this still buggy?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 10 May 2012

waveslider - Please see post #43. At present the Optimize Orderflow is partially implemented(only considering the exits). Not sure how soon the full solution is going to be implemented on this.

Thanks.
I am still having the issue of limit orders being cancelled/re-issued when a stop is introduced or adjusted.

Using optimized order flow.

Suggestions or is this still buggy?
Last edited by vking on 10 May 2012, edited 1 time in total.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 10 May 2012

Thanks. I voted for the improvement.

Positioning in the order queue is critical to me, and when this position is lost because a stop is adjusted - it opens the possibility of not getting filled.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 24 May 2012

I am using the newest version, with optimized order flow enabled.

I have a long position with a limit exit above, and a stop below.

Every time the stop is adjusted, the limit exit above is cancelled and re-sent, losing my original spot in the order queue.

This is unacceptable.

When will it be addressed?

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 24 May 2012

MC Team - Would you "Please" prioritize this issue over other cosmetic changes - as this is really a core trading component.. Optimize Order flow that is implemented is really nice but only half the solution..

Thanks.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 31 May 2012

Can we please have a response on this issue - I know it sounds like a broken record.

Every time I lose my place in the order queue, I potentially lose a fill that could cost me a lot of money.

Laurent
Posts: 159
Joined: 20 Nov 2010
Location: France
Has thanked: 76 times
Been thanked: 34 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Laurent » 31 May 2012

<joke> It's a feature, not a bug :-) </joke>

You can check the status here:
https://www.multicharts.com/pm/viewissu ... _no=MC-454
https://www.multicharts.com/pm/viewissu ... _no=MC-930

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 01 Jun 2012

I am using the newest version, with optimized order flow enabled.
I have a long position with a limit exit above, and a stop below.
Every time the stop is adjusted, the limit exit above is cancelled and re-sent, losing my original spot in the order queue.
This is unacceptable.
When will it be addressed?
Hello Waveslider,

Please let me know which broker do you use.
Also attach the export file (File->Export to Excel) of Order and position Tracker->Orders tab demonstrating the problem orders.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 01 Jun 2012

I am using rithmic.

The log doesn't seem to show the issue since I have had to manually over-ride.

I just upgraded to the 64 bit 8.0 version, as of today am running it. Maybe that will help?

Next time this comes up I will try running the same strat on a sim. so that it can be logged.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 05 Jun 2012

I am using rithmic.

The log doesn't seem to show the issue since I have had to manually over-ride.

I just upgraded to the 64 bit 8.0 version, as of today am running it. Maybe that will help?

Next time this comes up I will try running the same strat on a sim. so that it can be logged.
Update: This feature (modification of only modified (not all) orders in OCO) will be implemented in MultiCharts 8.1

Please send me (support@multicharts.com) a sample code you are using and a workspace to run tests in our environment.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 05 Jun 2012

Henry - Does this also cover the issue posted in PM request? The example code provided in the PM request is complete and functional if you would like to try it in your test environment.

https://www.multicharts.com/pm/viewissu ... _no=MC-930

Thanks.

I am using rithmic.

The log doesn't seem to show the issue since I have had to manually over-ride.

I just upgraded to the 64 bit 8.0 version, as of today am running it. Maybe that will help?

Next time this comes up I will try running the same strat on a sim. so that it can be logged.
Update: This feature (modification of only modified (not all) orders in OCO) will be implemented in MultiCharts 8.1

Please send me (support@multicharts.com) a sample code you are using and a workspace to run tests in our environment.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 11 Jun 2012

Henry - Does this also cover the issue posted in PM request? The example code provided in the PM request is complete and functional if you would like to try it in your test environment.
https://www.multicharts.com/pm/viewissu ... _no=MC-930
Thanks.
Hello Vking,

No, that is not the same functionality. Your Feature Request will be processed separately.

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 11 Jun 2012

Thank you Henry for your attention to this.

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 13 Dec 2012

8.0 Build5620
This is still an issue. In 8.5 will this be fixed so that multiple Limit Order Exits are persistent intra-bar after the first Exit is reached? As it is now, with "Optimize Order Flow", only one Exit is active at a time, so there is loss of que position; without "Optimize Order Flow", all exits are initially active, but cancel after the first one is filled and will not re-issue until a new bar is formed. Would appreciate 'normal' functioning of Limit Orders.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 07 Jan 2013

Any Update to this functionality?

Thanks

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 14 Jan 2013

Hello vking,

There are no updates on this functionality yet.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 14 Jan 2013

Thanks Henry. As you can see - there is no really work around for this issue and would appreciate if this functionality can be implemented at earliest.

Thanks

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 05 Feb 2013

Reading the ‘What’s New” write-up on the 8.5 Release Candidate interested to see:
Exit strategy behavior was changed. But for this issue no change. All Limit Price Exits are Not active and persistent at all times (the way a Stop is active and persistent at all times) and there is no way to make them active and persistent at all times.

On a Renko bar chart, if you use multiple very close Limit Price Exits, you cannot use coded Limit Price Exits unless ‘Optimize Order Flow’ is checked (active) – otherwise, after each fill you will only fill the next Limit Price Exit at new bar creation (see attached graphic showing code-generated Limit Price Exit levels and actual fill levels). So at best with Renko bars, with ‘Optimize Order Flow’ checked (active), immediately after one Limit Price Exits fills the next closest Limit Price Exit is active, but this is not optimal – not a disaster, but a bad - way to do Limit Price Exits (and not how other platform does Limit Price Exits).

Best to have all Limit Price Exits immediately active and persist so that each Limit Price Exit is:
- always at the correct price level;
- not resetting with each previous to the end of the Exit Queue for the price level on which the Limit Price Exit is set;
- not generated very late in time after the position was entered so the Limit Price Exit is near the end of the Exit queue for that price level.
Plus, I like to See all of my platform-managed Limit Price Exits on the chart. Stops persist: why cannot Limit Price Exits persist? It does not seem that much to ask - I am very surprised that so few have also asked for Limit Price Exits that persist - makes one wonder...


Sidenote: 64 bit is a great product that with a modern computer can do a tremendous amount of work and manage real time data really well. Appreciate that.
Attachments
MultiCharts4.png
(32.26 KiB) Downloaded 9339 times

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 06 Feb 2013

why cannot Limit Price Exits persist?


EXACTLY!

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 08 Feb 2013

I have discussed this functionality with our developers once again and here is what we have.
The exact case described in this feature request can be implemented the following way:
Each level of exits is treated as a separate OCO group: "FT-FTs", "ST-STs", “TT-TTs".
If “FT” order is filled then “FTs” order is cancelled- OCO Reduce Size. At the same moment "ST-STs", “TT-TTs" orders remain unchanged.
If “ST” order is filled then “STs” order is cancelled- OCO Reduce Size. At the same moment “TT-TTs" orders remain unchanged and so on.

This can be implemented only if stops and limits have the same amount of contracts.
This cannot be done if the orders have different amount of contracts, for ex. 10 contracts Limit & 5 contracts limit and 15 contracts stop against them.
What we need to know – is this the exact behavior you would like to have?
Image
Attachments
8810.png
(15.38 KiB) Downloaded 9979 times

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 08 Feb 2013

Henry - Thanks for the reply.

From regular solution point of view - what you have proposed makes sense.

Few points to note:
- If there is any position change due to manual scale-out etc - Do not alter "valid" orders and resubmit them again - as long as from the code point of view - it's handled properly. Only orders that need to be cancelled in that case would TT-TTs ( as per the code) and FT-FTs & ST-STs are supposed to stay in the queue - as they were before.
- from code point of view - manual scale-out can be handled and 3rd OCO order(TT-TTs) might not be submitted as quantity at hand would change - but rest of the orders(FT-FTs & ST-STs) are supposed to stay in the queue.
- As long as you can take care of this and let the other orders stay in the queue - this would be a perfect solution.

The important thing is - Order cancellations should be "intelligent" - rather than cancel first on certain events and then submit the valid orders approach should be reviewed. It needs to review - what orders can stay at the end of the tick and then ONLY cancel the appropriate orders. The position changes shouldn't simply cancel the existing orders ( as long as the validity for them to stay in the queue is still valid - in this case - FT-FTs , ST-STs ). This would allow the code to take care of any scale-ins/scale-outs in an efficient manner. It would be coders responsibility to take care of "positions" in an appropriate manner as long as MC would provide accurate pending order status.

Thanks

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby Henry MultiСharts » 08 Feb 2013

vking, thank you for your suggestions. We will do our best to create the most intelligent solution PowerLanguage architecture allows.

vking
Posts: 235
Joined: 21 May 2009
Has thanked: 51 times
Been thanked: 41 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby vking » 08 Feb 2013

Thinking further on this:

There might have to be few new keywords introduced as well if it makes it easier to have the PL handle this kind of advanced order handling capability.

Say - To tie them into an OCO from PL directly:

if CC=3 then begin
sell ("FT") 1 contract next bar at AEP+(1*OneTick) limit and AEP-(7*OneTick) stop;
end;

Something like this - don't know how easy difficult it would be but certainly one should be able to use any syntax to force an OCO order - whatever PL would allow. Please don't back out just to maintain the backward compatibility of the code. One can always use the existing code as they were using before and anyone wanted to use this new method - can modify their code as needed to support this mode of OCO.

You can also introduce any keywords to "Cancel a specific OCO order" by some means if it makes it easier for PL architecture.

Thanks

waveslider
Posts: 222
Joined: 16 Oct 2011
Has thanked: 66 times
Been thanked: 20 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby waveslider » 08 Feb 2013

It is a great step in the right direction, makes sense the way the developer describes it. Most important thing we are trying to achieve is maintain placement in an order queue, this should be the focus.
On a side note I want to publicly thank Henry for the hard work he puts in day in and day out on and off of the forums.
Thanks!

escamillo
Posts: 203
Joined: 25 Mar 2011
Has thanked: 23 times
Been thanked: 56 times

Re: Serious Issue with Exits - Automated trading - no workar

Postby escamillo » 19 Feb 2013

This can be implemented only if stops and limits have the same amount of contracts.
This cannot be done if the orders have different amount of contracts, for ex. 10 contracts Limit & 5 contracts limit and 15 contracts stop against them.
What we need to know – is this the exact behavior you would like to have?
Henry,
Sidenote#1: Thanks for looking into this, understand it can get complicated for you or any platform provider.
Sidenote#2: Your reply gets into a number of subjects, including the way MC handles Stops.

EXITS: Normally have entry contracts (5) that exceed the total number of planned exits (3). A Stop with CurrentContracts Contracts is active when a position is opened until last of position is closed. So not sure if I can ever get #Exits and #Stops to match.

STOPS: Some of us use a number different Stops that recalculate each bar/with time and move depending on volatility, price, time, etc. [See attached Screenshot for Plots of calculated multiple Stops levels.]
-- In TS, those Stops are (mostly) in Separate Strategy documents because in TS only the closest Stop is active.
-- In MC, when those Stops are in separate Strategy documents, they are ALL active, which from time to time results in multiple ‘CurrentContracts Contracts’ Stops at the same price level (e.g. two Stops of 2 Contracts at one price level against a position of 2 Contracts), which when the Stop price is reached, results in getting stopped PLUS getting Reversed in the amount of the CurrentContracts Contracts Stop – an unwanted reversal.
- So for MC have consolidated the separate Stop Strat documents into one Strat and made it so that only the closest Stop is active. This has disadvantages, including a longer, somewhat unwieldy Strat document and making it harder/unlikely to be able to use a partial fill Stop as a separate Strat (e.g. a Stop for one contract against a position of 5 contracts). But at least it eliminates unwanted reversal.

Multiple exits that persist would be nice; so would having only the closest Stop being active.
Not sure what you do/can do… Thanks.
Screenshot.png
(44.77 KiB) Downloaded 9333 times

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Serious Issue with Exits - Automated trading - no workar  [SOLVED]

Postby Henry MultiСharts » 23 Oct 2013

Please read about this feature scheduled for MC 9.1: https://www.multicharts.com/pm/viewissu ... no=MC-1497


Return to “MultiCharts”