Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
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
Can you help answer these questions from other members on NexusFi?
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.
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.
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 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.
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
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.
