detection of filled orders
detection of filled orders
Question on how MC processes filled orders. After an order to buy/sell/cover is sent to say IB, does MC constantly force the study to run regardless of whether there was an update tick or not? It appears to do so, sometimes immediately and at other times after a second or so, until the order is filled. It typically takes about 5 cycles to do so, give or take 1 or more. Is this the expected behaviour?
- Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
Re: detection of filled orders
Hello Janus,
Do you refer to pending order or filled order?
If you are using IOG mode for your signal then the signal is recalculated on every tick.
If you are not using IOG mode for your signal then the signal is recalculated on the close of the bar.
If you are using "RecalcLastBarAfter" code word-then your signal is recalculated after defined time value.
The order is sent by the script when the condition is met. When the signal is recalculated - it checks the order presence at the broker if the condition is still met.
If the order is not filled but pending at the broker and the condition is met - the order can be replaced (modified). When the order is replaced, order parameters (for ex. Limit Price) can be changed and order lifetime can be extended until the next script calculation.
If the order is not filled but pending at the broker and the condition is no longer met - the order is cancelled.
If the order is filled then the signal no longer sends it to the broker, the signals executes the code futher taking into account that the order is filled.
Do you refer to pending order or filled order?
If you are using IOG mode for your signal then the signal is recalculated on every tick.
If you are not using IOG mode for your signal then the signal is recalculated on the close of the bar.
If you are using "RecalcLastBarAfter" code word-then your signal is recalculated after defined time value.
The order is sent by the script when the condition is met. When the signal is recalculated - it checks the order presence at the broker if the condition is still met.
If the order is not filled but pending at the broker and the condition is met - the order can be replaced (modified). When the order is replaced, order parameters (for ex. Limit Price) can be changed and order lifetime can be extended until the next script calculation.
If the order is not filled but pending at the broker and the condition is no longer met - the order is cancelled.
If the order is filled then the signal no longer sends it to the broker, the signals executes the code futher taking into account that the order is filled.
Re: detection of filled orders
I'm referring to an order that has been submitted to and received by IB but not yet filled.
Thanks for the list of scenarios. It all makes sense. I'm using IOG with RecalcLastBarAfter sometimes at not at other times. As I suspected the current behaviour is expected.
There's one other scenario, which is a particular race condition where the order that was received by IB is filled but at the same time the study for whatever reason stopped sending the order in an attempt to cancel it but failed because it was too late. This would be a very rare occurrence but not impossible. Do you know what happens in this case?
Thanks for the list of scenarios. It all makes sense. I'm using IOG with RecalcLastBarAfter sometimes at not at other times. As I suspected the current behaviour is expected.
There's one other scenario, which is a particular race condition where the order that was received by IB is filled but at the same time the study for whatever reason stopped sending the order in an attempt to cancel it but failed because it was too late. This would be a very rare occurrence but not impossible. Do you know what happens in this case?
- Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
Re: detection of filled orders
This would be a really rare coincidence. It is hard to predict the behavior in such situation as there are multiple factors that should be taken into account. We cannot imagine what will happen on the broker end, but from MultiCharts end we are doing our best to handle your signals the most appropriate and expected way.
Re: detection of filled orders
Doing your best? In other words you don't know for sure if MC can handle such a race condition. It would be fairly easy for your developers to check and/or test this out by modifying the code if necessary to find out. I feel it's important to know for the benefit of all traders who want to trust MC will do the right thing under all circumstances. It's not too much to ask for such a critical component of trading, especially when large sums of money are involved. I've already added code to check for such a discrepancy and alert me. So far it hasn't happened but I wasn't expecting it to happen so easily because it is such a rare occurrence.This would be a really rare coincidence. It is hard to predict the behavior in such situation as there are multiple factors that should be taken into account. We cannot imagine what will happen on the broker end, but from MultiCharts end we are doing our best to handle your signals the most appropriate and expected way.
- JoshM
- Posts: 2195
- Joined: 20 May 2011
- Location: The Netherlands
- Has thanked: 1544 times
- Been thanked: 1565 times
- Contact:
Re: detection of filled orders
It would be a very rare condition indeed, especially with IOG on, but depending on (internal) latency it's not impossible off course. Thanks for pointing this out Janus, I must honestly say I hadn't thought of this before.There's one other scenario, which is a particular race condition where the order that was received by IB is filled but at the same time the study for whatever reason stopped sending the order in an attempt to cancel it but failed because it was too late. This would be a very rare occurrence but not impossible. Do you know what happens in this case?
Can you share an example in how you measure this? It might be possible to code a workaround for this, but I don't have any clue how one might measure this discrepancy, aside from writing a DLL that connects to TWS and checks the open order status and then compares that with MultiCharts order submitting. (Or is there a PowerLanguage keyword for 'CheckOpenOrder'-something?)I've already added code to check for such a discrepancy and alert me. So far it hasn't happened but I wasn't expecting it to happen so easily because it is such a rare occurrence.
Re: detection of filled orders
True it would be rare but that's not really good enough when one is dealing with serious money. Now I'm not suggesting MC is the only platform that may experience such an issue. It's possible they all do, but it's also possible one or more others have gone the extra distance and built into their platform code to detect such a scenario and at least warn the trader. When I started out to write my own trading platform using IB's api's a few years ago I did think of such a scenario and thought about how to detect it and what to do. I didn't finish the work as I wanted to focus more of my time on trading and less on re-inventing the wheel. That's when I came across MC and never looked back.It would be a very rare condition indeed, especially with IOG on,..
The logic I'm using is fairly simple. It basically computes what the expected position size and direction is suppose to be after placing an order. Thereafter I keep checking the MarketPosition_at_Broker value and if they are not in agreement after a certain time (in my case 20 update ticks) then I close everything out, stop trading, and send out alarms. My next exercise is to adjust everything to be in sync again and keep trading. Note this only applies with "at market" orders, which is what I typically use. Stop orders and the like have to be treated differently, and I haven't gone that far yet. Your idea of writing a DLL and accessing IN's api's did cross my mind too but that meant I had to go back to some heavy programming again, which I didn't like to do as I still want to focus on trading. Perhaps when I do have more time I will do that too. However, I'm not even sure if there is any benefit in doing so. For now I'm happy to use the easier approach I described above, and build on it.Can you share an example in how you measure this? It might be possible to code a workaround for this, but I don't have any clue how one might measure this discrepancy, aside from writing a DLL that connects to TWS and checks the open order status and then compares that with MultiCharts order submitting. (Or is there a PowerLanguage keyword for 'CheckOpenOrder'-something?)
- Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
- Henry MultiСharts
- Posts: 9165
- Joined: 25 Aug 2011
- Has thanked: 1264 times
- Been thanked: 2957 times
Re: detection of filled orders
We have simulated the described behavoiur. MultiCharts knows that the order is filled at the broker, it shows "Filled" order status and continues the trading.There's one other scenario, which is a particular race condition where the order that was received by IB is filled but at the same time the study for whatever reason stopped sending the order in an attempt to cancel it but failed because it was too late. This would be a very rare occurrence but not impossible. Do you know what happens in this case?