Re: are stop orders native ?
Did the events you describe happen in a paper or a live account? Certain order types do not exist at all in paper accounts and others may behave differently from live trading environments. And since paper trading represents a "best guess" on IBKR's part as to how the order would have traded in the live environment, timing especially in challenging situations, will be considerably different.
suggests that no STP order is routed natively to the exchanges. Only certain STP LMT orders may become native exchange orders. That suggests that you cannot construct an order that results in a native "Stop with Protection" order.
I have never looked into this in detail, but anecdotally, from the colored flag in the Monitor -> Orders tab in TWS, I have never seen natively routed futures orders other than LMT orders (e.g. green flag). All other orders have the blue flag that says "Order is being held and monitored".
Below a few quick tests I did in a paper account.
´³¨¹°ù²µ±ð²Ô
?
?
?
?
?
?
On Mon, May 5, 2025 at 10:06 AM, @sv624 wrote:
I thought so too, but seeing them not getting filled as expected made me doubt it.
|
Re: are stop orders native ?
I thought so too, but seeing them not getting filled as expected made me doubt it.
|
Re: are stop orders native ?
Isn't there a rule of thumb -- generally -- that at least with GLOBEX futures, GTC limit and stop-limit orders will be natively routed? And if I'm not mistaken, doesn't this include stop-limit orders with one-time adjustments? On Mon, May 5, 2025 at 8:14?AM sudhin_deshpande via <sudhin_deshpande= [email protected]> wrote:
Just one contract.
Thank you
|
Re: are stop orders native ?
Just one contract.
Thank you
|
Re: are stop orders native ?
One possible explanation could be the "velocity logic" mechanism in CME, then likely the stop orders with protection were not filled if your market moved that much.
In theory you could see that if you look at the generic tick type and try to detect the market state transition (Not Halted -> Halted -> Not Halted) around the time when your order should have filled. Just an idea.
?
Also how many NQ lots did the order have?
?
|
Re: How is everybody plotting their data?
That is because our group focuses on the TWS API interactions of your client applications and discussions about data plotting approaches are out of scope. Particularly, when they are related to just one programming language.
?
´³¨¹°ù²µ±ð²Ô
?
On Sun, May 4, 2025 at 12:13 PM, donye wrote:
However, I'm more interested in how anybody is processing the data they are receiving. I can't find anything about MPL, Plotly, or MPLFinance on this site
|
Re: How is everybody plotting their data?
From the documentation:
?
numberOfTicks: int. If a non-zero value is entered, then historical tick data is first returned via one of the? ? respectively. (Max number of historical Ticks is 1000)
?
I'm not getting an error anymore because I did not have the tick type set to midpoint. But I submitted a ticket for that. However, I'm more interested in how anybody is processing the data they are receiving. I can't find anything about MPL, Plotly, or MPLFinance on this site
|
Re: reqAccountSummary() socket API request unkown extra field (50000001)
Yes, that is what I just found out. Probably the fact that the reqId value was so high fooled me.
Thank you ´³¨¹°ù²µ±ð²Ô for your response.
?
|
Re: reqAccountSummary() socket API request unkown extra field (50000001)
You are missing the message version field in the message you create. The message needs to be "62" + "1" + reqId + group + tags
´³¨¹°ù²µ±ð²Ô
?
On Sun, May 4, 2025 at 09:56 AM, Tradiator wrote:
Hi all,
?
I'm implementing a direct socket connection to IB Gateway (v187) and constructing messages manually according to the low-level TWS API protocol.
I ran into an undocumented (?) issue with the reqAccountSummary (opcode 62). According to all available documentation, the expected fields are:
"62" + reqId + groupName + tags
?
However, when I sent this message:
62?2?All?NetLiquidation,TotalCashValue?
?
IBGW responded with the following error:
Unable to parse field: 'Client Req Id' for input string: 'All'
?
I have to send the following sequence in order to receive a valid response:
62?1?50000001?All?NetLiquidation,TotalCashValue?
?
What is exactly this "50000001" field (accountId? clientKey? something else)?
Is this field always required, or only under certain conditions (e.g., IBGW, multi-account setups, recent protocol versions)?
?
I captured this "50000001" from the data sent by the C# sample code included with TWS API.
?
Thanks in advance for any clarification ¡ª and for all the great help on this list!
?
|
Re: How is everybody plotting their data?
You are not getting TickByTick data since you are requesting real-time live stream data while the markets are closed. You need to call to request historical TickByTick data.
?
´³¨¹°ù²µ±ð²Ô
?
?
On Sun, May 4, 2025 at 10:47 AM, donye wrote:
I've searched if anybody uses mplfinance or plotly and not much comes up. I'm curious how any of you are plotting your data (if you are). I need to in order to see if the indicators I've coded are behaving properly.
?
I'm using this code to request historic and tickbytick.
?
I have to wait for market to open to see if it does receive tickbytick. It's supposed to retrieve the last thousand ticks along with new tickbytick but it's not working this weekend. But I'm wondering what anybody is using to plot the data once it's in. I don't know how to pass it through mplfinance
?
#request data
app.reqTickByTickData(19001, mycontract, "Last", 1000, True)
#receive data
def tickByTickMidPoint(self, reqId: int, time: int, midPoint: float):
print("Midpoint. ReqId:", reqId, "Time:", time, "MidPoint:", floatMaxString(midPoint))
|
How is everybody plotting their data?
I've searched if anybody uses mplfinance or plotly and not much comes up. I'm curious how any of you are plotting your data (if you are). I need to in order to see if the indicators I've coded are behaving properly.
?
I'm using this code to request historic and tickbytick.
?
I have to wait for market to open to see if it does receive tickbytick. It's supposed to retrieve the last thousand ticks along with new tickbytick but it's not working this weekend. But I'm wondering what anybody is using to plot the data once it's in. I don't know how to pass it through mplfinance
?
#request data
app.reqTickByTickData(19001, mycontract, "Last", 1000, True)
#receive data
def tickByTickMidPoint(self, reqId: int, time: int, midPoint: float):
print("Midpoint. ReqId:", reqId, "Time:", time, "MidPoint:", floatMaxString(midPoint))
|
reqAccountSummary() socket API request unkown extra field (50000001)
Hi all,
?
I'm implementing a direct socket connection to IB Gateway (v187) and constructing messages manually according to the low-level TWS API protocol.
I ran into an undocumented (?) issue with the reqAccountSummary (opcode 62). According to all available documentation, the expected fields are:
"62" + reqId + groupName + tags
?
However, when I sent this message:
62?2?All?NetLiquidation,TotalCashValue?
?
IBGW responded with the following error:
Unable to parse field: 'Client Req Id' for input string: 'All'
?
I have to send the following sequence in order to receive a valid response:
62?1?50000001?All?NetLiquidation,TotalCashValue?
?
What is exactly this "50000001" field (accountId? clientKey? something else)?
Is this field always required, or only under certain conditions (e.g., IBGW, multi-account setups, recent protocol versions)?
?
I captured this "50000001" from the data sent by the C# sample code included with TWS API.
?
Thanks in advance for any clarification ¡ª and for all the great help on this list!
?
|
Re: are stop orders native ?
I haven't used stop orders, but I have seen high latency in price updates: I would be submitting a series of price updates for a standing limit order, and the order would fill at a price that was up to one second old. For example, I would update the limit price to $1 at time 0, then update the limit price to $2 at time 1, and the order would execute at time 3 at the "old" price $1. This would happen even when the price updates were being confirmed within tens of milliseconds of their submission.
I don't know why, but one possibility is that the IBKR servers can take as long as a second (after they receive the update) to register the update with the exchange.
Such delays were not frequent, but they happened often enough that their cost was significant.
|
liquidHours and tradingHours format
Just received this in ContractDetails for liquidHours and tradingHours, BTC (PAXOS) market:
?
['', '20250504:0300-20250505:1600', '20250505:1601-20250506:1600', '20250506:1601-20250507:1600', '20250507:1601-20250508:1600', '20250508:1601-20250509:1600']
Does anyone know what's the empty string at the beginning? An error? Or does it mean "ongoing session"? I was trying to parse these data for building a per day opening and closing time, and the first data point is a challenge given they express the overnight trading including a next day date for the end time.
?
Why don't they just use 00:00 and 23:59 and express directly per day? What do you do with the information this way for consistency? Like if I scrape "today", the first data point lacks information to build the full picture. The frustsration whilst dealing with IBKR design choices has no end.
?
Renato
|
Re: are stop orders native ?
Did anyone experience this?
|
Re: are stop orders native ?
The problem I saw was that orders were delayed getting filled when markets were super volatile making big moves like NQ futures.
So this is happening even when orders are natively executed by the exchange as per IB web site as mentioned above and below link
Stop with limit may not get executed at all and slippage too high with market orders.
Thank you
Sam
?
?
|
Re: Live data on multiple contracts - Python
Real-time and historical data work quite differently and historical data downloads have more restrictions than real-time feeds:
- The time frame that you can get data for is shorter for smaller bar sizes
- You for the smallest bar sizes if you ask for too much data too quickly
- IBKR will slow down the data flow if you request too much data simultaneously. So I am not surprised that you see slow down or long delays when you request 72 or more downloads simultaneously
- IBKR has over time gradually relaxed the requirements, but you should be prepared to download data over a longer time (a weekend, a week), store it locally, and feed your program data from your local data store.
- You can find any posts about historical data download strategies in our archive. Some time last year I made a few experiments and found that 25 to 30 outstanding request gave me the best download speed.
As you experienced, reqSecDefOptParams() and reqContractDetails() work differently in that for reqContractDetails() you will receive one callback for each contract a given request will produce. The callback will indicate the end of the list once all contracts have been delivered. You;d want to make a thin "adapter" layer between your application and TWS API that implements the list collection process and returns all contracts to your application.
´³¨¹°ù²µ±ð²Ô
?
On Wed, Apr 30, 2025 at 08:03 PM, @Dan_F wrote:
Hi Jurgen,
?
Your advice. I instantiated only one TestApp() and set up a loop to pass multiple contracts.
?
I have a couple more questions for now:
?
1. I got all expirations and strikes with reqSecDefOptParams() and set up a nested loop to go through every combination. I was trying to pull historical data since I was coding after market hours.
Some combinations worked, some did not, because they simply did not exist. Anyway, I noticed that the terminal stopped dumping data at around reqId 72.
When I try to retrieve so much data, do I need to set up a pause after certain amount of iterations? Is there a limit to how many contracts per second I can request?
?
2. After realizing that I am iterating over contracts that may not exist, I tried retrieving them with reqContractDetails() method. I only specified contract.symbol, contract.secType, contract.exhcnage, and contract.currency. When I ran the code, the terminal gave me all contracts on the chain. Sometimes it took as little
as few seconds, sometimes it would take a minute or more before I saw anything appear in the terminal. When I tried saving conIDs to a list, I was only able to save the very last one. When I compared the code between reqContractDetails() and reqSecDefOptParams() in decoder.py, I realized that the former returns only one value, and the latter returns a set. I guess this is more of a coding question than how the API functions, but is there a way to save all the conIDs returned by reqContractDetails() to a list?
?
3. I will have another question regarding greeks, but I still have a couple methods to explore, so I'll check back in later with that.
?
Thank you!
|
Re: are stop orders native ?
See the list of order types for the CME here: ?
? This shows you exactly which order types are native and which are simulated by IB. ? You might be surprised at some of this¡ ? The same info is available for all the other exchanges. ? Richard ?
|
Re: are stop orders native ?
Unless something has changed in the last few years, the exchange itself does not support any ¡°smart ¡° orders. It is a broker¡¯s responsibility.? In our trading we completely ditched those orders and make exit/entry decisions by ourselves. This also allowed us to be broker-agnostic.?
On Sat, 3 May 2025 at 4:56 sudhin_deshpande via <sudhin_deshpande= [email protected]> wrote: When I place a stop order, does it get placed at the CME Globx exchange natively?
Or does IB manage the trigger and then place LMT or MKT order at the exchange?
Thank you
?
|
When I place a stop order, does it get placed at the CME Globx exchange natively?
Or does IB manage the trigger and then place LMT or MKT order at the exchange?
Thank you
?
|
donye