Using range bars could be the problem.
Mark - can you post your entry and exit code ?
Have you been able to read the log of the API calls to the broker ?
MultiCharts Automated trading
- Thread starter MarkBrown
- Start date
Have you been able to read the log of the API calls to the broker ?
I would suggest trade on the daily timeframe. Once a day you can find some time to have quick look into for a trade or not. If one cannot do decent money on daily timeframe then it is much more difficult to do it on the intraday timeframe. So first master daily timeframe before you go to smaller ones. My two cents.
this sample system is always in the market long or short
// AMA System
Input: Price(Close), Period(10), Damp(0), LimSlope(0.01), delay(1);
Vars: Ave(Price), Slope(0);
Ave = KaufmanAMA(Price, Period, Damp);
Slope = AbsValue(Ave - Ave[1]);
if Slope > LimSlope then begin
if Ave < Ave[delay]
then Sell Short This Bar
else Buy This Bar ;
end;
Hi MB,
I use what amounts to MIT method. I hold the data and conditions in MC and only transmit the MKT order when the conditions are met.
For me it does not make sense to fight the executions engine of the EL-MC until one moves to the API and eliminates the EL execution engine.
e.g.
Essentially I leave everything as IOC = ON and use barstatus=2 selectively. This way you get the best of both. Intrabar evaluation, but execution based a condition. Of course, this code above evaluates to execute at the open of the next bar, but one could easily call the SetXYZ functions also to get immediate execution.
With range bars or Tick bars, this should work. One can use Close with IOC =ON and it acts as Last in realtime. Or one can pair a Close = XYZ and barstatus= 2 to get an actual closing value. Then set the "if touched" condition.
For now I am using a lot of end of bar evaluation so the realtime and the backtest-forward test match up.
I use what amounts to MIT method. I hold the data and conditions in MC and only transmit the MKT order when the conditions are met.
For me it does not make sense to fight the executions engine of the EL-MC until one moves to the API and eliminates the EL execution engine.
e.g.
Code:
if condition then begin Close_Position = True; Exit_ID = "CLS Condition1 "; end;
if Close_Position then buytocover ( Exit_ID) Trade_Size contracts This Bar;Essentially I leave everything as IOC = ON and use barstatus=2 selectively. This way you get the best of both. Intrabar evaluation, but execution based a condition. Of course, this code above evaluates to execute at the open of the next bar, but one could easily call the SetXYZ functions also to get immediate execution.
With range bars or Tick bars, this should work. One can use Close with IOC =ON and it acts as Last in realtime. Or one can pair a Close = XYZ and barstatus= 2 to get an actual closing value. Then set the "if touched" condition.
For now I am using a lot of end of bar evaluation so the realtime and the backtest-forward test match up.
Last edited:
Did you not hear about the new IOC? JK. Yes I ment IOG. Sorry.
Last edited:
Yes, they match up. But more importantly, if they do not, on occasion, I can track it down and figure out what "other" shenanigans the order-sync engine is doing. A lot of the issues comes down to all the strategies feeding into the a single execution engine instance. So I just keep it simple: One strategy and one account.
The real issue is gathering enough realtime data to verify it. So I run everything on Paper-realtime for a few weeks looking for any differences. Fortunately, I run more than one account in paper mode, and still run live on other accounts.
This is all testbed testing. Once I get it working, I will move to an actual API interface, go with a co-location etc. and eliminate as much of the latency and middleman as I can.
Have you been able to quantify what the slippage, poor fills, and latency has been costing you ?