The answer is that if the feed would be theorically correct we don't have any kinds of this problems.
Sometime the feed is not accurate, losing tick, lag time etc... could it happened, but this is the tecnology and we should learn hot to survive with this problem.
The best solution should be that from the source the exchange they include this kind of ID tick protocol in the tick information, so also we lose 3, 4 or more tick this never will be a problem because when there are id tick lost multicharts could ask a backfill of this exatly tick.
Is the protocol of the exchange that should be improved, now I am pretty corious how multicharts staff solve this problem, because the source of the problem is diretly the protocol exchange, all other way to solve are a half solution.
There should be final sync check from final data that are load in retail user in quotemanager by tick id and the original id tick of the exchange. This check should be done at ebd of day trading session or afther a scheduled time.
Exchange Tick id 1..2...3...4.---> server id tick (check)--->server---> user tick id 1..2..?..4... multicharts say:" (ops 1 id tick is lost, ok i remember i can waite to reload it when my schedule start or when user want)
Remember that The exchange when you do an order, the order is done from your pc....and that the broker should take all records from you for at least 5 or 10 years....
If they want improve they could do very easy way for them.
In trying to find 'workarounds' for my code in this thread, I have run across another problem. Perhaps someone much smarter than I am can show me how to make this work.
I have 2 data series: The top one is a 2-point Range Bar and all trading is done off of it. The bottom one is also a 2-point Range Bar, but the contract is further out than the top one. The trading signals are derived from this bottom chart.
I have been trying to use InsideBid and InsideAsk in my statements in Data2. After applying some calcs to them, I then want to compare those numbers to a Moving Average in Data1.
However, the Moving Average in Data1 stops being calculated as soon as the bars in Data2 stop trading. Since Data2 deals with a contract that is farther out in time, it isn't traded nearly as much (or as often) as the contract in Data1. So, when Data1 'stops', so do the calcs for the entire program.
Below is the code that I'm using:
As soon as Data2 has no new data bars (and even though Data1 keeps trading), the calcs for MA STOP. [And MA is based on Data1, not Data2.] The code uses IntraBar Order Generation, Bar Magnifier, and Extended Strategy Backtesting Mode (using Bid and Ask data).
And then the same problem occurs when the Bottom data series doesn't trade for awhile (several minutes to an hour). When it finally does trade, signals are inserted back in time on the chart as much as 1 hour in the past !! (And then MultiCharts bases it's backtesting results on these delayed signals.)
I am a bit late to the party... but I hope I can still help.
just a couple of questions to start...
Do you have a flow chart of your trading logic?
You have quite a complex strategy, with 3 data streams of different resolutions.
a flow chart will help you see the logic flows...
and help you code the detail required to execute your orders properly.
Have you tried plotting your orders?
ie. before jumping into a strategy,
try to code the logic as an indicator,
plotting a green dot wherever/whenever there is a buy order,
and a red dot for sell order.
I can see a few hole in your code/method,
some are already addressed,
others will require a bit more explanation.
I will attempt them in the next few days.
The following user says Thank You to Bimi for this post:
I have only 2 data streams (not 3). I don't have a flow chart for my trading logic. (That's seemingly over my head.) The same with coding my logic as an indicator.
If you can make this work, then you should be hired by MultiCharts at whatever price you want. I've come to the conclusion that there is no retail charting platform in existence that can do what I want it to do.
computer/software are dumb,
it can only do what you ask it to do.
EasyLanguage has been around for 30 years, any problem you can think of, probably has been attempted/attacked by someone somewhere.
a flow chart is utmost important in dealing with a complex task, especially when multiple timing is involved.
you might think your logic is simple, and that it does not warrant the trouble of a flow chart.
but I would urge your to give it a try... it does not have to be comprehensive, just make a block diagram to illustrate your thoughts. I am not asking you to post the diagram; it is something you should have on your desk beside the computer keyboard.
an indicator to test the logic is just basic;
you are wasting your precious time coding the strategy if you can't even put a dot at the exact location where you think there should be money to be made.
with multiple resolutions, the key is to line up the logic with the time sequence.
often we might think we have the logic, but in reality they are not aligned.
I will go through your variables step-by-step, to interrogate them and to make sure they are the value you are expecting.
(remember GIGO: your strategy is only as good as the variables you assign them.)
both flow chart and indicator might take some time and effort to create,
but will save you some time (and hair) in the long run.
The following user says Thank You to Bimi for this post:
I not only have a dot to show where I can make money, I have a graph. In one of my 'workarounds' I put a graph in Data2 that tells me to Buy if the CurrentBid of Data2 crosses above it and the CurrentAsk of Data2 crosses below it for Shorting. The only problem is I'm having trouble getting MC to give me correct current calculations of the information from Data1 to apply to this graph in Data2
1) The most important. If your trading strategy features a high trade # to produce your profits, then your netprofit/trade is going to be small.
That is the largest detriment to your system.
A system that trades 3 times in order to garner 30 ticks of profit, is MUCH more correlating sim/backtest/live than a strategy that trades 300 times to garner 30 ticks of profit.
The reason is because as you're discovering, there's enough variability in lag time, order delays, fill executions, etc to overcome very small profit/trade margins.
In essence, if there's a possibility that you can see a +/- 2 tick variation with respect to your roundtrips live (compared to sim) then what does that tell you if you observe 2 ticks of profit (net per trade) in simulation?
2) You can gain SOME measure of price control by using limit orders. But there is still slippage associated with limit orders.
The first type of slippage is inherent and discretionary. It's the "price gap" you set for your strategy in order to ensure that you're order doesn't get "jumped" over passed by in the event the price is moving very quickly. We've all observed this "mouse lag" when trying to enter or modify a trade with a limit order using a mouse. Sometimes, you're just not quick enough on the draw with the trigger finger on your mouse. You go to move your stop limit order and the market races past you as you drag and drop. OR, more commonly, you go to place the order, but by the time you recognize, click, send, and the order is received, the market is already past that point.
In coding, you have to inherently set a pricegap of a tick or 2 to reduce these rejected or passed trade occurences. Depending on your strategy, your tolerance for these order jumps may be little to none or very high. (i.e. how much havoc does it create in your strategy if you miss a trade? I would argue that high trade volume strategies are a little more tolerant of this....there's plenty of trades and essentially "I'll catch the next one").
Having said that, so you know that you're going to set a 1 tick "gap" or cushion in order to gain some fill control. That's good, now you have the first order "slippage" managed.
The second type of slippage with limit orders is what I call "momentum slippage." This is where you place a limit order on the server and it sits there, and price moves to the order and fills it (ideally). SOMETIMES, the price is moving sooooo fast, that you get filled not at the price that you specified in the limit, but at some price a few ticks in the direction of the strong move.
I've personally observed up to 6 ticks of "momentum slippage" during RTH.
Depending on your strategy setup, this can be good, bad or neutral (over the course of many trades).
Let's begin by calling 2 sides of the market during trend....leeward and windward. The leeward side of the market is the side that the price has past and is moving away from. The windward side of the market is the side that the price is moving toward.
So, if your entries are always on the windward side (i.e. the price is at 90.00, your entry limit order is at 90.10 for a long entry and the market moves up, fills, and then continues past), the entries are always going to be PENALIZED by any momentum slippage. That is...if you wanted a long fill at 90.10, depending on how strong the market is moving at your order, you may see a fill of 90.11, or 90.12, etc.
This cuts into your potential trade...as you bought at a higher price than you would like.
IF your orders are on the leeward side of price (i.e. price is at 90.15, you want to buy at 90.10 in anticipation of the market going higher...and your limit order waits for price to retrace a bit, fill and head back the opposite direction). Then your entries are going to experience favorable momentum slippage. Obviously, the market surges in the direction of the general trend more often than in a retracement...so leeward side entries will experience LESS favorable effect than windward side entries will experience adverse effects (wonderful how nature is always working against you).
Noteworthy is that again, life is always a tradeoff...windward side entries give you more "fill assurance" as if you're correct and the market is going a particular direction....it HAS to go past your entry limit order to fulfill your prediction. If it does not, if it partially fills and move BACK the other direction, well then you were spared some loss, as it didn't go in your direction anyway.
Leeward side entries, (on the retracement side of a trend) then your fill isn't always guaranteed (even if the trend goes the way you think). It may retrace, run into your support/resistance, partially fill and head the direction you predict.
Thus, you trade fill certainty for momentum slippage exposure (or vice versa).
Let's now examine exits.....
You can see where this is going. If you're on the leeward side for exits (a typical trailing stop). Again, any momentum slippage you experience will be negative. The comfort is that the market doesn't rage back in a retracement as much as it rages forward in a trend. Nonetheless.....your slippage for a cookie cutter trailing stop will be some number greater than zero. The comforting thing about trailing stops is that you can eliminate the "price gap" cushion outlined above (assuming your trail is a considerable number of ticks away from the bid/ask...if your trail is 1 or 2 ticks, you might see it jumped, but if it's several ticks....usually it holds in place upon a retracement).
If your stops are windward side....you get the benefit of any positive momentum slippage, but you also get the drawback of fill uncertainty. (how many people have experienced the harrowing, nailbiting phenomenon where you're trade is positive...your profit limit is on the matrix and the price is lingering and hovering around your exit. It may even trade AT your exit for a length of time...depending on your order in the que.). In essence, if you're in a long position and you place an exit ABOVE the current ask.......the price may indeed move up to greet you....but it doesn't always totally fill your order immediately or completely (depending on your positionsize).
so once again, you trade price certainty/fill certainty for adverse momentum slippage.
There's no doubt that limit orders can manage slippage better than market orders (in many cases). During RTH, you may consider simply enduring the market order slippage on an instrument like CL (you're not going to see significant slippage until your odersizes are very large).
I recommend a combo....market orders during RTH (when your positionsizes are smallish) and limit orders during non-RTH (regardless of positionsize).
"A dumb man never learns. A smart man learns from his own failure and success. But a wise man learns from the failure and success of others."
The following 2 users say Thank You to RM99 for this post:
Thank you for your input, RM99. But I don't think this will solve my problem.
First, the average number of R.T.'s using ES (which I am concentrating on now) is only around 150 per day. CL was more than double that. Secondly, Limit orders didn't really help. It was the Lag time between WHEN the signal was given to Enter by MultiCharts and when it SHOULD have given the signal.
And speaking of Limit orders, I always thought a limit order was a limit order was a limit order. How can an Entry be made at a price worse than the limit order?? But it has happened. My last attempt at the live trading used only Limit orders. And I was filled at prices much worse than my limits.
Something was either wrong with my code or with MultiCharts. That's why I have this thread here. There have been some small errors in my code, but I think the bulk of the problem is with MC. I'm hoping against hope that Version 7 will eliminate these bugs. But to tell you the truth, I doubt that it will.