¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Twsapi
  2. Messages
Expanded Topics Messages Polls
Date
Re: questions about the two thread design (TWS c++ api)

 

Oh, so I don't need to worry about race conditions at all do I? I'm just going through TestCppClient::processMessages() over and over again? Do something based on m_state, then receive information from callbacks. Got it.
Re: Avoiding time.sleep while waiting for openOrder / orderStatus callback after placeOrder

 

The issue you are having is an old one in programming.? You have two basic choices: polling and interrupting.? Polling means you check a status, usually in a loop with a sleep or yield call.? Interrupting means you wait on an event from the server, usually received as a callback in IB's API.? The interrupting is better but harder to write.? You usually have to add extra logic to implement a timeout in case the server doesn't respond at all.

For what you are doing, polling is likely far better unless you are a pretty good professional programmer with years of experience.? Just wrap a loop around your logic and you are there.? Probably best to make the loop run at most a set number of times.? The max total wait time will be the number of times the loop can run times the length of the sleep.? You probably want to make the max total wait time to be about 15 seconds (5sec to a minute is reasonable).? I hope this helps.

Hunter

On Sunday, October 8, 2023 at 07:21:29 AM PDT, fran <fchiesadoc@...> wrote:



Check this out.

El 8 oct. 2023, a la(s) 11:02, Lipp F. <flipp31a@...> escribi¨®:

?All code?examples I can see are like this:

placeOrder(orderId, contract, order)
time.sleep(10)
Is there a better way of doing this? Maybe using?threading.Lock() with release() in callback functions? Looking for an example. TIA.
?

Re: strange execution price for a stop loss

 

I experienced this with the sim account as well, it¡¯s not accurate. Frustrated me for awhile, but many people I have talked with said while the sim account is good to make sure your algorithm submits orders properly as well as get live data, and other api functionality, price execution of the simulated account is not feasible to use for tracking results. Forced me to make my own simulated account hooked to a local database and adjusted my fills according to liquidity on the order book. I experienced the same issues and went this route to solve. I may have been doing something wrong but didn¡¯t want to take the chance before going live as price execution clearly did not match order liquidity for market and other orders at times in IB¡¯s sim.

On Sun, Oct 8, 2023 at 5:57 AM FrenchFlorent <fcourtin@...> wrote:
Thank you for your answers.
I totally agree that the stop order is a MKT type order and offer no garanty on the price effectively executed.
But I've checked order book at this time (8:31:57 ECT), via reqhistoricalTicks and?whatToShow=BID_ASK, and it seems to have great activity (not surprising, at the market opening). So I am quite sceptical that there were such a huge gap on the priceBid between?14908.50 and?14893.75.

I'd like to go further in the analyze, what is?Level II data and how I can I get it ?

Thank's a lot?

Re: Avoiding time.sleep while waiting for openOrder / orderStatus callback after placeOrder

fran
 

¿ªÔÆÌåÓý


Check this out.

El 8 oct. 2023, a la(s) 11:02, Lipp F. <flipp31a@...> escribi¨®:

?All code?examples I can see are like this:

placeOrder(orderId, contract, order)
time.sleep(10)
Is there a better way of doing this? Maybe using?threading.Lock() with release() in callback functions? Looking for an example. TIA.
?

Avoiding time.sleep while waiting for openOrder / orderStatus callback after placeOrder

 

All code?examples I can see are like this:

placeOrder(orderId, contract, order)
time.sleep(10)
Is there a better way of doing this? Maybe using?threading.Lock() with release() in callback functions? Looking for an example. TIA.
?

Re: strange execution price for a stop loss

 

Thank you for your answers.
I totally agree that the stop order is a MKT type order and offer no garanty on the price effectively executed.
But I've checked order book at this time (8:31:57 ECT), via reqhistoricalTicks and?whatToShow=BID_ASK, and it seems to have great activity (not surprising, at the market opening). So I am quite sceptical that there were such a huge gap on the priceBid between?14908.50 and?14893.75.

I'd like to go further in the analyze, what is?Level II data and how I can I get it ?

Thank's a lot?

HistoTicks_NASDAQ-mini-Ech202312_Q2023-10-05.xlsx
HistoTicks_NASDAQ-mini-Ech202312_Q2023-10-05.xlsx

Re: questions about the two thread design (TWS c++ api)

 

... I should add that the clientS octet which sends messages to TWS will be in your main thread. Could be your GUI thread if you have a GUI app. Those calls are immediate and don't have overhead.

Re: questions about the two thread design (TWS c++ api)

 

The call to EReader->start() creates a thread that listens for messages coming in from TWS. When a message comes in it is added to a queue. That is all that thread does.

In your application you create a thread that loops waiting for the signal that something is on the queue. It is this thread that dispatches to your EWrapperImpl callbacks.?

So in C++ the message reading and the callbacks are on separate threads.?

questions about the two thread design (TWS c++ api)

 

I'm trying to reason about the c++ TWS API, and according to the documentation

One thread is used for sending messages to TWS, and another thread is used for reading returned messages. The second thread uses the API EReader class to read from the socket and add messages to a queue. Everytime a new message is added to the message queue, a notification flag is triggered to let other threads now that there is a message waiting to be processed. In the two-thread design of an API program, the message queue is also processed by the first thread.
I'm trying to modify variables in callbacks that read information, and read them to send messages in other methods. Here are my questions:

1. Each callback is only controlled by one and only one thread, I hope. Is that right?
2. std::unique_ptr<EReader> m_pReader is the subordinate thread that triggers all these pure virtual methods that report information from TWS, right? The main thread calls methods explicitly in TestCppClient's definition, and I can see those.
3.? EClientSocket * const m_pClient sends information *to* TWS, but uses the same shared data structure as m_pReader (they both look at EReaderOSSignal m_osSignal, for example)? Is all the shared stuff written by IBKR thread safe? I think I would've heard about it by now they weren't. That would be pretty crazy.

Re: Install TWS or IB gateway on Ubuntu and ARM64 bit processor

 

I still don't have an ARM64 with Linux, so I cannot try this myself.

You may be able to get a little farther (and make IBGW run more stable) by making the JVM11 look more like a JVM8 to TWS/IBGW. Java11 implements "Modules" with "Strong Encapsulation" so that access to resources between packages is much more restrictive than what Java 8 allows. You might find error messages in the early (unencrypted) logs or the console stderr where IBGW complains about something like:
  • error: package XYZ is not visible
  • java.lang.IllegalAccessError: class ABC cannot access class XYZ (in module SomeModule)

  • or similar sounding messages

JVM11 and above provide command line options "-add-exports" and "--add-opens" that you can use to create the more permissive environment Java 8 based IBGW expects. "" explains how to do that.

Hope that helps,

´³¨¹°ù²µ±ð²Ô



On Fri, Oct 6, 2023 at 07:32 PM, ykrasik wrote:
I got it working on ARM64. Posted it on github, relevant details are in this commit:

The UI doesn't work and shows up as a blue square, but I'm able to connect to it with my app and send trades.


Re: Install TWS or IB gateway on Ubuntu and ARM64 bit processor

fran
 

¿ªÔÆÌåÓý

Cool. Thanks. Will try it today.

El 6 oct. 2023, a la(s) 21:32, ykrasik <ykrasik@...> escribi¨®:

?I got it working on ARM64. Posted it on github, relevant details are in this commit:

The UI doesn't work and shows up as a blue square, but I'm able to connect to it with my app and send trades.

<dummyfile.0.part>

Re: Incorrect margin in whatif order

 

"order.whatIf" was the issue. thank you.

Re: strange execution price for a stop loss

 

forgot to add one more thing that is related to this case, and that is the way the price is verified. if the chart displays mid price, it does not really display the lowest bid price but just the average of the ask and bid price (= mid price). i guess for simulated trading charting trades might not be very relevant. so it would be good to check the ask price and the bid price to verify the simulated execution. also, if ask price is the trigger in this case, the price is not triggered by the mid price, the mid price gets lower before the ask price triggers the stop order. and then the bid price for the simulated execution is even lower.

Re: strange execution price for a stop loss

 

i'd just add that the trigger method also determines what will happen during simulated trading. that is, the order might get triggered when ask price reaches the stop price, but for simulated trading the order then gets executed at the bid price, if there is someone willing to buy sufficient quantity at the real market(s). as the simulated algorithm (imo) works the same for mostly all assets, there is a very low chance that it would from time to time behave in a different way. they take the orders, the market data flowing in, and based on that they simulate the executions.

Re: Incorrect margin in whatif order

 

Your code sets several fields in the order object that do not exist. Most languages would complain about something like that but Python does not:
  • Fields eTradeOnly? and firmQuoteOnly? have been deprecated years ago and have been removed from the Order class entirely in TWS API V9.85 (three years ago)
  • The "whatIf" field in Python is spelled with a lower case "w" but your code has an upper case "W". So you are actually placing orders instead of asking for margin information.

After changing "order.WhatIf" to "order.whatIf" you should get proper margin values ... and no additional orders for APPL.

´³¨¹°ù²µ±ð²Ô


On Fri, Oct 6, 2023 at 08:04 AM, Lipp F. wrote:
The code is like this:
? ? ? ? contract = Contract()
? ? ? ? contract.symbol = "AAPL"
? ? ? ? contract.secType = "STK"
? ? ? ? contract.exchange = "SMART"
? ? ? ? contract.currency = "USD"
?
? ? ? ? order = Order()
? ? ? ? order.orderId = orderId
? ? ? ? order.orderType = "LMT"
? ? ? ? order.lmtPrice = 200
? ? ? ? order.action = "SELL"
? ? ? ? order.totalQuantity = 10
? ? ? ? order.transmit = False
?
? ? ? ? order.eTradeOnly = False
? ? ? ? order.firmQuoteOnly = False
?
? ? ? ? # you need to transmit to get whatif response. In this case, it does NOT transmit the order to the market!
? ? ? ? order.transmit = True
? ? ? ? order.WhatIf = True? ??
?
? ? ? ? self.placeOrder(order.orderId, contract, order)
and it returns Maintenance Margin: 1.7976931348623157E308:
openOrder: 3, contract: 265598,AAPL,STK,,0.0,?,,SMART,,USD,AAPL,NMS,False,,combo:, order: 3,1000,984843980: LMT SELL 10@... DAY, Maintenance Margin: 1.7976931348623157E308
orderStatus. orderId: 3, status:? PreSubmitted, filled: 0.0, remaining: 10.0, avgFillPrice: 0.0, permId: 984843980, parentId: 0, lastFillPrice: 0.0, clientId: 1000, whyHeld: , mktCapPrice: 0.0
openOrder: 3, contract: 265598,AAPL,STK,,0.0,?,,SMART,,USD,AAPL,NMS,False,,combo:, order: 3,1000,984843980: LMT SELL 10@... DAY, Maintenance Margin: 1.7976931348623157E308
orderStatus. orderId: 3, status:? PreSubmitted, filled: 0.0, remaining: 10.0, avgFillPrice: 0.0, permId: 984843980, parentId: 0, lastFillPrice: 0.0, clientId: 1000, whyHeld: , mktCapPrice: 0.0
?

Re: strange execution price for a stop loss

 

Results from simulated trading in the paper account will be different from trading in a live account, but the basic principles tend to be correct and quite accurate. I think what you have experienced is expected behavior for the regular STOP order. s you will see that, once the STOP trigger is reached, IBKR places a order for you. For market orders, they say:

A market order may increase the likelihood of a fill and the speed of execution, but unlike the Limit order a Market order provides no price protection and may fill at a price far lower/higher than the current displayed bid/ask.

I don't have access to Level II data for NQZ3 to know for sure, but TickByTick BidAsk data shows very small BidSizes (mostly 1 or 2) for the 10 seconds before 08:32 (US/Central, NQ trades in Chicago). So it is quite likely that some market orders could? briefly have filled well below the prices you would expect. Live trading may not have gone all the way down to 14893.75, but that price was reached less than a minute later, so the order book was probably pretty empty.

You need to decide how important it is for you to close the position (partially and completely) and what you are willing to pay for it. You may decide to make the STOP order so that the STOP only triggers when real trading took place at or beyond the trigger price. Or you may use a so that you are not exposed to the unlimited risk of the market order. If you set the limit too tight to the trigger price, though, you run the risk that the stop only closes a portion of your position or nothing at all.

´³¨¹°ù²µ±ð²Ô

On Fri, Oct 6, 2023 at 07:18 AM, FrenchFlorent wrote:
Hello

Yesterday, my bot was running in a paper trading environnement. It interacts with IB API and TWS.
The bot bot 3 contracts NQ at 09:31:45 (15:31:45 in my french local time) at 14916.25 , and placed a Stop order at 14909.?
Then the price went down and the stop loss has benn executed in two partials orders :
- the first at 09:31:57? with 2 contracts for an average price of 14908.50 => OK
- the second also et 09:31:57, with 1 contract for a price of 14893.75 !!! => how strange, since the price has always benn above 14907.75 at this time. Il effectively touched this price at 09:32:44 ??!!?

I've checked in TWS interface, and I have the same times / prices / orders...



Up to you, is this a TWS bug in paper trading environnement ? Or am I wrong somewhere ??

Thanks a lot

Re: Install TWS or IB gateway on Ubuntu and ARM64 bit processor

 

I got it working on ARM64. Posted it on github, relevant details are in this commit:

The UI doesn't work and shows up as a blue square, but I'm able to connect to it with my app and send trades.

Incorrect margin in whatif order

 

The code is like this:
? ? ? ? contract = Contract()
? ? ? ? contract.symbol = "AAPL"
? ? ? ? contract.secType = "STK"
? ? ? ? contract.exchange = "SMART"
? ? ? ? contract.currency = "USD"
?
? ? ? ? order = Order()
? ? ? ? order.orderId = orderId
? ? ? ? order.orderType = "LMT"
? ? ? ? order.lmtPrice = 200
? ? ? ? order.action = "SELL"
? ? ? ? order.totalQuantity = 10
? ? ? ? order.transmit = False
?
? ? ? ? order.eTradeOnly = False
? ? ? ? order.firmQuoteOnly = False
?
? ? ? ? # you need to transmit to get whatif response. In this case, it does NOT transmit the order to the market!
? ? ? ? order.transmit = True
? ? ? ? order.WhatIf = True? ??
?
? ? ? ? self.placeOrder(order.orderId, contract, order)
and it returns Maintenance Margin: 1.7976931348623157E308:
openOrder: 3, contract: 265598,AAPL,STK,,0.0,?,,SMART,,USD,AAPL,NMS,False,,combo:, order: 3,1000,984843980: LMT SELL 10@... DAY, Maintenance Margin: 1.7976931348623157E308
orderStatus. orderId: 3, status:? PreSubmitted, filled: 0.0, remaining: 10.0, avgFillPrice: 0.0, permId: 984843980, parentId: 0, lastFillPrice: 0.0, clientId: 1000, whyHeld: , mktCapPrice: 0.0
openOrder: 3, contract: 265598,AAPL,STK,,0.0,?,,SMART,,USD,AAPL,NMS,False,,combo:, order: 3,1000,984843980: LMT SELL 10@... DAY, Maintenance Margin: 1.7976931348623157E308
orderStatus. orderId: 3, status:? PreSubmitted, filled: 0.0, remaining: 10.0, avgFillPrice: 0.0, permId: 984843980, parentId: 0, lastFillPrice: 0.0, clientId: 1000, whyHeld: , mktCapPrice: 0.0
?

strange execution price for a stop loss

 

Hello

Yesterday, my bot was running in a paper trading environnement. It interacts with IB API and TWS.
The bot bot 3 contracts NQ at 09:31:45 (15:31:45 in my french local time) at 14916.25 , and placed a Stop order at 14909.?
Then the price went down and the stop loss has benn executed in two partials orders :
- the first at 09:31:57? with 2 contracts for an average price of 14908.50 => OK
- the second also et 09:31:57, with 1 contract for a price of 14893.75 !!! => how strange, since the price has always benn above 14907.75 at this time. Il effectively touched this price at 09:32:44 ??!!?

I've checked in TWS interface, and I have the same times / prices / orders...



Up to you, is this a TWS bug in paper trading environnement ? Or am I wrong somewhere ??

Thanks a lot

Request for Assistance with TWS API-Based Python Trading Algorithm

 

Hello TWS API Group Members,

I am reaching out because I am currently working on a Python trading algorithm using the TWS API, but I lack the necessary programming skills to complete it. I am willing to compensate a group member who can assist me in finishing this project.

Project Description: I have developed a Python script that utilizes the Interactive Brokers TWS API for automated trading. However, I am encountering an issue in my script, specifically at the line "File 'trades.py', line 185." This issue needs to be resolved.

What I Need:

  1. 1. Identify and fix the error at line 185 in my script.
  2. 2. Review and optimize the existing code for better performance.
  3. 3. Ensure that the algorithm correctly executes trades based on technical indicators and other criteria.
  4. 4. Provide guidance on any necessary adjustments or improvements to the algorithm.

Contact Information: If you are interested in helping me with this project, please contact me directly via email at [d116822@...]. Feel free to share your experience with TWS API or similar projects.

Note: Please reply directly to my email rather than via the group.

Your assistance will be greatly appreciated, and I am willing to negotiate fair compensation for your time and expertise.

Thank you for considering my request.

Best regards,

Kendall

2261 - 2280 of 53751