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)
Strategy is sending orders but they’re canceled immediately, why? No broker side prob
I think it seems possible, with the close price changing on every tick in IOG mode, for price to sneak above some arbitrary level, trigger a limit to be sent, and then tick back down while your market position is still flat, causing a cancel before the limit order is filled. And for this same thing to easily happen several times in succession...which is what your order history looked like to me.
Yes exactly, you can set a boolean variable when your price conditions have been met and the limit is first sent. Use this flag as part of your conditions to keep alive the limit order. Remember to clear it once your market postition is no longer flat, or when your reasons for wanting to enter the market are no longer applicable (such as at the end of the bar, you can check that the BarStatus indicates the closing tick of the bar.)
I understand that your strategy uses previous days' levels to choose one very specific condition that happens infrequently...
and you want to make sure you have some code that reliably works with how Multicharts requires it.
So in that case, maybe just for the sake of testing it, you might create a version of your strategy with entry conditions that happen more often, like maybe referencing a price level that occurred within the last 30 minutes instead of something fixed on the previous day. And I'd again advise adding more logging to the entry logic section, even for things you *know* will not change.
I don't mean to reference your specific code here too closely, I'm only generally trying to emphasize the fact that deploying live strategies is not unlike deploying any production software for the first time. The things that go wrong are often those that you'd least expect. From many people's experiences, at least that I've read here, strategy development has it's own psychology, and patience to get things right is a big element of people's success.
You might have to map that to a real symbol like DDM19 to work correctly, I've seen that recommended with other continuous contract scenarios. But if so, I'm just guessing that there would not be any conflict with your live tests.
today I just opened my computer and I've found an unexecuted trade in the paper trading workspace (I left the strategy running with automation with the paper broker). As you can see the strategy has tried to send the order a lot of times...
I had similar problem with CQG (this problem was the first one, before the cancelation problem related to this theread) and I solved it by setting the lookup account in the strategy properties tab and after that it is correctly showing "DAY" under the TIF column.
The paper trading orders are showing GTC under the TIF column... could that be the case?
Ok yesterday I was examinating how to perform this. Of course a boolean would be a solution but before try that I was thinking about a simpler solution and I would like to know your thoughts. This is the piece of code of interest
As you said the fluctuation over and below oYesterdaysTPOVALow could be caused just by this piece of code
because price (of the current bar = price[0] ) can go over/under many times before the 5 minutes bar end. So in order to have the order placed the first time that the price goes over the level I can simply take as reference the HIGH value of the bar instead of the PRICE .... by this way the first time that the price will go OVER the level then the following comparison
will be TRUE during ALL the actual Bar (because H could be higher but now lower then the max value reached inside the bar) and it should keep the order LIVE without cancel it (of course till Price - oYesterdaysTPOVALow <= 10 but there's enough space of time to execute the trade.. and probably Price - oYesterdaysTPOVALow <= 10 would be useless as it will never be false before the order has been filled).
I just quick tried a backtest from december till today and entries and results are the same ( the total difference in 65 trade is 37$ so nothing) so it didn't modified the strategy behaviour.
So could it be a simpler ed effective solution rather than implement a boolean control?
Thanks again in advance for every further reply :-D
this time they are not cancelation but rejections. And this print comes from YESTERDAY afternoon paper trading and the modifications that I've done has bern done TODAYMorning only.
The First time I got something REJECTED was for tr TIF that's why I'm asking what is GTC.
About my other post where I put HIGH value insted of Price value do you think it's a good solution to avoid the order cancelatin?
I did not see that on the image. The rejections are usually not caused by the code and you should be able to find an explanation on the logs or alert tab.
Nice idea, definitely simpler and that is always a good thing.
What I'd recommended is just an idea to possibly generalize things. It could be a re-usable if you were planning on writing other very different strategies that use limit orders to enter.
is using High for Price really a fix and more important doing what you want your code to do or will this just reduce the cancellations while still allowing orders getting cancelled? From the code snippet you will probably still have situations where an order gets triggered and cancelled on the next tick (or before getting filled) as the high moves higher. The order would then not get re-issued again for that bar as the bar's high can only move higher.
If you want the order to remain uncancelled a flag would be the way to go.
