NexusFi: Find Your Edge


Home Menu

 





Is it possible to use Stop orders in Range bars ?


Discussion in EasyLanguage Programming

Updated
      Top Posters
    1. looks_one JoeDee with 3 posts (0 thanks)
    2. looks_two spikoloco with 2 posts (2 thanks)
    3. looks_3 Darshiit with 2 posts (0 thanks)
    4. looks_4 Big Mike with 1 posts (1 thanks)
    1. trending_up 4,538 views
    2. thumb_up 3 thanks given
    3. group 3 followers
    1. forum 8 posts
    2. attach_file 0 attachments




 
Search this Thread

Is it possible to use Stop orders in Range bars ?

  #1 (permalink)
Darshiit
India
 
Posts: 29 since Oct 2009
Thanks Given: 32
Thanks Received: 22

Hi ,

I have been using range bars with discretionary method so far with multicharts. But when i tried to code entries and exits with stop orders , it didnt show me any results.

Using range bars I am able to place market orders but i m really getting frustrated while trying stop orders. Is there anyone who faced same problem ? Or any solution to it ? As MC can not be used for discretionary trading as of now, till they dont introduce DOM into it.

Will be thankful if experienced programmers throw some light on it.

Darshiit

Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Trade idea based off three indicators.
Traders Hideout
MC PL editor upgrade
MultiCharts
ZombieSqueeze
Platforms and Indicators
NexusFi Journal Challenge - May 2024
Feedback and Announcements
REcommedations for programming help
Sierra Chart
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Spoo-nalysis ES e-mini futures S&P 500
45 thanks
Just another trading journal: PA, Wyckoff & Trends
31 thanks
Bigger Wins or Fewer Losses?
24 thanks
Tao te Trade: way of the WLD
24 thanks
GFIs1 1 DAX trade per day journal
22 thanks
  #3 (permalink)
 
Big Mike's Avatar
 Big Mike 
Manta, Ecuador
Site Administrator
Developer
Swing Trader
 
Experience: Advanced
Platform: Custom solution
Broker: IBKR
Trading: Stocks & Futures
Frequency: Every few days
Duration: Weeks
Posts: 50,446 since Jun 2009
Thanks Given: 33,217
Thanks Received: 101,608


It's not hard, just do

 
Code
                            
if C[1then Buy 1 Contract Next Bar At H[1Stop
In other words, just change the last word from Limit to Stop and it will be fine. If your order trigger criteria changes but you want to keep your stop order in place, then probably just set the variable once and test for that variable each new bar, then once in a position reset the variable back to null.

Mike

We're here to help: just ask the community or contact our Help Desk

Quick Links: Change your Username or Register as a Vendor
Searching for trading reviews? Review this list
Lifetime Elite Membership: Sign-up for only $149 USD
Exclusive money saving offers from our Site Sponsors: Browse Offers
Report problems with the site: Using the NexusFi changelog thread
Follow me on Twitter Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #4 (permalink)
Darshiit
India
 
Posts: 29 since Oct 2009
Thanks Given: 32
Thanks Received: 22


Big Mike View Post
It's not hard, just do

 
Code
                            
if C[1then Buy 1 Contract Next Bar At H[1Stop
In other words, just change the last word from Limit to Stop and it will be fine. If your order trigger criteria changes but you want to keep your stop order in place, then probably just set the variable once and test for that variable each new bar, then once in a position reset the variable back to null.

Mike


Thanks Big Mike for reply.

But issue is not with coding. Issue comes in execution of orders.

My bad , this simple code worked while I dont know why my strategy stop orders ain't getting executed. Will check and come back again.

Darshiit

Reply With Quote
  #5 (permalink)
 JoeDee 
London, UK
 
Experience: Intermediate
Platform: Multicharts
Trading: eMini Futures
Posts: 29 since Mar 2012
Thanks Given: 6
Thanks Received: 38


Darshiit View Post
Thanks Big Mike for reply.

But issue is not with coding. Issue comes in execution of orders.

My bad , this simple code worked while I dont know why my strategy stop orders ain't getting executed. Will check and come back again.

Darshiit

I have questions/issues about the same subject. I'm not sure if the strange results that I'm experiencing are due to my code, the order of execution when autotrading - or EasyLanguage itself.

if C > C[1] then Buy 1 Contract Next Bar At H[1] Stop;

The Code above seeks to buy at the High of the previous bar but I often get an error message saying that the 'Modify failed as the Buy order must be above the last trade price'. I'm assuming that's because: by the time the next bar arrives, the bar on which this order was placed has become the previous bar and the order is too slow in getting to the market and the price has already passed it.

e.g. Assuming a downward market
Bar 1. High = 1934.00
Bar2. High = 1932.00 The Order issued on the bar (intrabar using IOG) and it appears as a STOP @ 1934.00
Bar3. Open = 1932.25 An attempt to cancel/replace the Stop Price to the 'new' H[1] value of 1932.00 fails because the order price is not > than the last traded price (1932.25). As a result of the failure, the Stop remains at 1934.00 and the entry at 1932.25 is missed.

I have also tried to calculate ahead of time where the high of the range bar will be (and adjust it if necessary as each tick evolves) by calculating expected closing price (e.g. Buy 1 Contract Next Bar at (Low + Range + 1 tick) Stop.

This works OK on an indicator, backtesting and replay but not in a Sim market. It appears to suffer from the same issue as the first example in that when the bar changes, the Stop is modified using the 'new' Low to calculate the Stop price before the previous order has been filled. In Sim, the order is often not filled at all.

e.g. using 8 tick range bars.
Bar 1. High = 1934.00 The Order is placed to Buy at 1934.25 on a Stop.
Bar2. High = 1932.00 The Order is amended to Buy at 1932.25 on a Stop. (so far so good as a trailing Stop Entry).
Bar3. Open = 1932.25 The Order is not filled on Sim and instead, the Stop order is moved to 1934.50 (Low of Bar 3 (1932.25) +8 ticks +1 tick).

I realise that this probably won't happen in a Live market because the 1932.25 Stop Order will be at the exchange and be filled before the Script tries to modify it. However, on Sim, the order(s) usually remain unfilled. On the odd occasion that it is, another message appears saying that the cancel failed because the order had already been executed - which is what I might expect in a Live market if the price/bar change is received before Fill notification.

Either I'm doing something really dumb (most likely - please feel free to let me know what I'm doing wrong) or nobody else has experienced this (highly unlikely). I have been unable to find any posts relating to this issue. The one above is the closest and even that's 4 years old.

Just to preempt anyone suggesting to 'Buy Next Bar at Market on a Stop' if/when the high of the bar is greater than the previous bar's high. I did think of that. However, that order will only be sent at the close of the bar. Placing the order ahead of time (intrabar), as I am attempting to do, means that the order will already be at the exchange when the bar changes. While both types of order will often suffer from slippage, in a fast market, the difference in slippage between the two could be significant.

Reply With Quote
  #6 (permalink)
 spikoloco 
Queretaro,Qro. Mexico
 
Experience: Intermediate
Platform: Ninja Trader, Multicharts
Broker: Mirus/Zen-Fire
Trading: ES
Posts: 34 since Nov 2009
Thanks Given: 7
Thanks Received: 3

The problem is that you are usin IOG.

Buy/sell NEXT BAR AT... Does not correpond to buy/sell on the next bar.

IOG mode off buys next bar at the price you want

IOG mode On, buys at the next tick.....

From Multicharts help:
""
[IntrabarOrderGeneration = True];
When IntraBarOrderGeneration is turned on, next bar really means next tick . For example:
if (Close > Close[1]) then
Buy ("EL") 1 contracts next bar at market;
Will generate a buy order that is active for the next tick only. As long as the condition remains true, the entry order is submitted for the next tick.""

I hope that can help...

Reply With Quote
Thanked by:
  #7 (permalink)
 spikoloco 
Queretaro,Qro. Mexico
 
Experience: Intermediate
Platform: Ninja Trader, Multicharts
Broker: Mirus/Zen-Fire
Trading: ES
Posts: 34 since Nov 2009
Thanks Given: 7
Thanks Received: 3

Try to use, NEXT BAR AT THE CLOSE OF THIS BAR

I would personally stop using IOG, it is really a mess and the strategy will never behave the way it should when going live. I stopped using IOG and I have gotten better results on my strategies.

Let me know if This was of any help

Reply With Quote
Thanked by:
  #8 (permalink)
 JoeDee 
London, UK
 
Experience: Intermediate
Platform: Multicharts
Trading: eMini Futures
Posts: 29 since Mar 2012
Thanks Given: 6
Thanks Received: 38


spikoloco View Post
The problem is that you are usin IOG.

Buy/sell NEXT BAR AT... Does not correpond to buy/sell on the next bar.

IOG mode off buys next bar at the price you want

IOG mode On, buys at the next tick.....

From Multicharts help:
""
[IntrabarOrderGeneration = True];
When IntraBarOrderGeneration is turned on, next bar really means next tick . For example:
if (Close > Close[1]) then
Buy ("EL") 1 contracts next bar at market;
Will generate a buy order that is active for the next tick only. As long as the condition remains true, the entry order is submitted for the next tick.""

I hope that can help...

Thanks for the reply. Since my original post, I have discovered that OEC's Sim and MC don't always talk to each other in the way that they should.

e.g. I have a Print statement immediately before the 'Buy' statement showing the order details (including price). For some inexplicable reason, the working order is not being moved to the new price. That isn't very helpful when testing. I might try a Rithmic Demo to see if the root cause of this is with MC or OEC's Sim. My instinct is that the problem is with OEC - but leaving that glitch aside for the moment.....

I take your point about IOG and that's fine in Replay. In fact, both methods work OK in Replay. However, with a datafeed the results are hit and miss and the inconsistency is in part due to the glitch mentioned above - but not all of it is due to that.

Leaving IOG off won't meet my requirement to send the order 'before' the close of the bar so that it is at the exchange before the bar closes as is the case with a manually entered trade (and how it should be with automation too - but that's a whole different subject). Without IOG turned on, the order won't be sent until the bar closes which risks even greater slippage than is already present.

Also, and more importantly, I'm not a fan of any of the 'at close of bar', 'at open of bar' methods as they don't actually send anything to the exchange. With an open order, you are effectively 'naked' if you get disconnected whereas an order sent with a price (sent IOG) rests on the book or in the Stop engine queue.

I'm guessing (and it is only a guess) is that with a datafeed (as opposed to testing with Replay), the script is receiving two separate and distinct inputs (i.e. the Order Data and the Price Data).
Which information is received first, determines the order in which the script behaves. One would hope that order information is always processed first but if not, and if there is a bar change before the order is supposed to be sent, Current and Previous Bar information have a whole new meaning to what they were a nanosecond ago.

Does anyone know what happens if the High is at 1200 and the bar would close at 1201 but there is a gap with the next trade going off at say, 1203? Does the script still receive a Close of Bar message or just an Open of Bar message?

My own experience has been that 'sometimes' the Buy 1 Contract Next Bar at (Low + Range + 1 tick) Stop; order is filled and sometimes it is not but is moved further away instead, thereby missing the entry (In a Live Environment, this couldn't happen if the order was placed ahead of time and was sitting at the Exchange as the first tick of the new bar would fill the order first before the price change was sent out).

On other occasions, the attempt to move the order fails because the OEC Sim engine already filled it. In that case, I receive an error message saying that the attempt to cancel failed because the order was already filled (This is what I would expect to happen in a Live environment but as I can turn off those messages, it wouldn't be a problem). A third permutation is that the whole things works, as expected. Same code, three different results.

The language in my house over the last couple of days has been appalling

Reply With Quote
  #9 (permalink)
 JoeDee 
London, UK
 
Experience: Intermediate
Platform: Multicharts
Trading: eMini Futures
Posts: 29 since Mar 2012
Thanks Given: 6
Thanks Received: 38

I think I have found the source of the problem. So this is just an update to the above which may save others some time:

With the markets so quiet in the early hours, I thought it would be a good time to monitor the activity tick-by-tick and I noticed the following:

I sent the following Buy Orders at a Price on a Stop. I noticed that even though the calculated Stop price changed - and the code sent the order, it didn't actually get updated on the OEC DOM on the first tick where there was a new Stop Price calculated. (BTW, Sometimes it was taking more than a few ticks before the Stop was moved to a new price).

This is difficult to spot during RTH as there are so many ticks.

Stp = 1153.80
Stp = 1153.80
Stp = 1153.40 Order on DOM remains @ 1153.80 Should be 1153.40
Stp = 1153.40 Order on DOM changes to 1153.40 Correct
Stp = 1153.30 Order on DOM remains @ 1153.40 Should be 1153.30
Stp = 1153.10 Order on DOM changes to 1153.30 Should be 1153.10
Stp = 1153.10 Order on DOM changes to 1153.10 Correct
Stp = 1153.00 Order on DOM remains @ 1153.10 Should be 1153.00
Stp = 1152.80 Order on DOM changes to 1153.00 Should be 1152.80
Stp = 1152.80 Order on DOM changes to 1152.80 Correct

I sent this to Multicharts and this was their reply:

"Hello, It is expected behavior. NEXT BAR order is formed on the N tick (during strategy calculation). It is sent to the broker when the N+1 tick arrives (you have IOG mode on). Then, on N+1 tick the strategy is recalculated (orders are created/modified/cancelled) When the N+2 tick arrives, messages generated on the N+1 tick calculation are sent to the broker etc. That is why it seems that the right column is lagging compared to the left one."

First of all, it doesn't 'seem' to lag. It lags. The order is not being sent when the price changes and when the code is executed. It's on the subsequent pass that it is actually being sent.

I was not aware of this and, depending on what your strategy is, it should be accounted for in the code when testing on a Sim.

When using IOG, the requirement within Multicharts to repeatedly issue the same order on every single tick (apart from being an incredibly and unnecessarily inefficient design) presents potential problems when testing on a SIM and having this one or more tick delay before the order is actually sent.

If your code relies on the values of 'current bar' and assumes that any order placed one tick above/below the bar will be executed *before* the 'current bar' values change, then the delay in the order actually getting sent gives inconsistent results and this should be catered for in the code.

Reply With Quote




Last Updated on June 20, 2014


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts