User settings are stored in a local directory and nothing prevents you from having multiple folders with different settings and layouts.

To set the folder on the command line:

tws -J-DjtsConfigDir=/path/to/folder

Also, it's convenient to uncheck "Use/store settings on server" in the login screen in order to start with a clean slate.

A lot of these differences ("discrepancies"?) come from the variation on the original data set.
- Do you use the RTH session data set or the extended session data set ? (rule does apply individually on each stocks as not every of them have extended hours)

- Are you using full precision data or 2 decimals rounded ?

- How do you involve weekend ? (Usage is to not account it, but then be careful to properly count in 'real trading days' as the X units, you should be careful to skip non trading day, some indicators have kernel that are very quickly shifting)
Be careful that even a decent simple EMA200 require 400 days of data to dampen certain effects. (so that even an EMA200 for an IPO which is 201 days old will be mathematically wrong for 199 more days)

- Vwap involve volume.
Volume is a Pandora box as there are various interpretation of it depending on the number of venues you look at (or IB for you), the rounding on trading blocks, number of odd blocks, RTH, etc ...
The fight is between reporting quickly a partial info , or reporting an extended info but later.
Start using Close (easier to cross check and better ruled), and once fine tuned migrate to vwap if you need it

I never find out precisely how does IB compute their indicators, and how precise they are to an hypothetical absolute. Even their EMA200 is different than most others vendors.
Other vendors maybe wrong also BTW.

So, many people I know (including me) end up doing all indicators by themselves, unable to compare them across vendors (if you want precise analysis) however you may not need that.
Once said and waiting, like you, for somebody with a better answer (I would love that)
I would say that:
Your math is as good as others, BUT you are creating your own realm of indicators and should stay within the laws of your realm.
The life savior is that in general the math used are so much the same that relationship between your indicators are consistent enough, just hard to interpret across platform.
IMHO

I realize I can save and load specific layouts but the default behaviour of exiting and saving the current layout means I need to manually manage the whole process.

?

?

Hello,

I am new here and maybe is not the best place to ask, but I hope that I will get an answer.
In short I have a real account with a paper trading attached to it and NASDAQ subscription.
I have noticed that orders are not executed, even when I try from the TWS GUI.

Yesterday I have tried to buy/sell TSLA, on regular hours with 10k$, using MKT, SMART.
I have noticed that the first trade is executed as expected( entry order ) but the second is not, it takes minutes, around 20 to get filled.
How can I reliable test that the code I write is functioning if I can't even place orders using GUI ?

Any advice would be helpful.

Thanks,
Flaviu

?

It happened again today but this time, only the MIT part of the order was missing from 2 of the orders. Here is a screenshot.

IB got back to me after I sent them the logs, they told me that,

After reviewing your logs further, we saw that almost all of your orders are using the same set of order IDs, 71, 73, 74, 75. Given Interactive Brokers does not allow order IDs to repeat, it means that either all subsequent orders are having an error for duplicate order IDs, or the more likely reason is because there is some other error rejecting the order initially.

I am not sure how to fix, am I advancing through each bracket / new parent order wrongly here???

def nextValidId(self, orderId: int):
    super().nextValidId(orderId)
    self.nextValidOrderId = orderId
    print('The next valid order id is: ', orderId)

def nextOrderId(self):
    oid = self.nextValidOrderId
    self.nextValidOrderId += 1
    return oid



for ticker, orders in new_portfolio.items():
    bracket = app.BracketOrder(.........)
    for o in bracket:
        app.placeOrder(o.orderId, app.EQ_order_MKT(ticker), o)
        app.nextOrderId() 

app.disconnect()

As such, we noticed the average API connection time was no more than about 150ms before you had disconnected. We would ask that you remain connected for at least 1 second before disconnecting. Please try your standard code, with the extended connection time, and let us know if any messages are returned. The increased connection time should allow for order status and error messages to return.

Do they mean I should put a time.sleep(1) after I finish my loops?

You are coming to the wrong conclusions, Greg.

The situation is very different when an existing subscription experiences errors 1100/1102 and when you subscribe to additional instruments. HMDS servers provide more than just “historical data” and are involved during the subscription request, but they do not provide real-time data once the data feed has started. So it is safe for TWS/IBGW to disconnect HMDS farms at any point.

Here a quick overviw (as I understand it):

TWS/IBGW establish a connection to port 4001 of a “primary server” at IBKR which is required to always be active. Primary servers are responsible for everything from login and account management to order processing, order status, and real-time data subscription permissions and management. They are located in several regions around the world, and their names look something like ndc1.ibllc.com.

TWS/IBGW is always prepared to switch over to one or two redundant hot-standby backup primary servers in a different region.

When the connection to the primary server is lost, TWS/IBGW will have very limited functions (or stop functioning all together). Error code 1100 is sent when the connection is lost, and connection restoration is indicated with codes 1101 (data and subscriptions may have been lost) or 1102 (no data or subscriptions have been impacted). Depending on the reason for the disconnection and in case it is brief, existing market data feeds may actually continue while the primary server is disconnected.

TWS/IBGW connect to various data servers (”farms”) as soon as data from those farms is needed. Under certain circumstances, TWS/IBGW will disconnect from those farms when they are no longer needed and indicates that with “is inactive” codes 2107, 2108, and 2159. This has no impact on any subscribed services and connections will be reestablished transparently and instantaneously when the need arises. Your code can safely ignore these codes.

For a variety of reasons, connections to these farms can be lost while they are still in use. That can result in service disruption or delay and is indicated by the “is broken” error codes 2103, 2105, and 2157. While it generally does not impact the subscription itself (data feed will restart and the connection is restored) your code may want to be aware of these codes and flag extended periods of disconnection especially outside of the daily IBKR maintenance/reset windows.

Once a connection is established to a farm (for the first time, after a period of inactivity, or after a broken connection), TWS/IBGW will send “connection is OK” codes 2104, 2106, and 2158.

• Unless already cached, TWS/IBGW makes a query to the sec-def server and retrieves more detailed information about the contract (instrument) you are trying to subscribe to. Only very few fields of the contract object you provide with your request are actually transferred to TWS/IBGW.
• The contract information retrieval from sec-def is followed by a “ContractAdjustment1” query to the HMDS farm for that instrument. Apparently, certain volatile contract fields are maintained by the HMDS farm responsible for that instrument. TWS/IBGW may have to connect to the HMDS farm if it is not connected yet, and you will see an “is connected” code 2106 for, in your case, euhmds.
• Once TWS/IBGW has all contract related information and your permission to subscribe is established, TWS/IBGW establishes a data feed from the market data farm that handles your instrument. If that farm is not connected, you will see an “is connected” code 2104 for, in your case, eufarm.
• At this point, TWS/IBGW does not need the connection to the HMDS farm any longer and you may see “is inactive” code 2107 for, in your case, euhmds. TWS/IBGW seems to review required connections during 1100/1102 reset sequences, unnecessary connections may be closed, and you are informed about such a disconnection in the text of the 1102 code (as you show in your example "The following farms are not connected: euhmds").

While there is an active market data subscription, TWS/IBGW will keep the market data farm connected and there is nothing you need to do. Once the last subscription handled by a farm is cancelled, you may see an “is inactive” code 2108 for that farm.

A few thoughts on next steps for you.

If you experience stalling real-time market data subscriptions after a 1100/1102 sequence, I suggest you enable the “Create API message log file” and the “Include market data in API log file” options in TWS/IBGW for a while. That way you can verify that really no market data is being sent after 1102, or whether data is sent but the callback logic in your client is somehow malfunctioning.

I’d reach out to IBKR for a solution if that log indeed shows that data was sent until 1100 but never restarted after 1102. We have never experienced that.

IBKR generally assigns your primary server based on your location and the kinds of instruments you work most with. But they can, if necessary, permanently assign your account(s) to a specific region. Your primary server defines when your daily server reset times are.

You will have the most stable service if your TWS/IBGW has reliable connections to all IBKR primary servers in the world (since at any point TWS/IBGW might have to switch over), but at least to the one assigned to your account. IBKR provides? a simple tool at you can use to verify that your TWS/IBGW machine can indeed connect to all of these servers.

If you want to learn more about how these things work (and you have some time on your hand) you can enable “Help→Troubleshooting→Enable Verbose Logging” and “Enable HMDS Logging” and follow a subscription and the subsequent data feed yourselves.

Here a quick overview about the "good" and 'bad" codes:

?

闯ü谤驳别苍

On Sun, Jul 16, 2023 at 04:07 PM, John wrote:

Unsure why Ewald chose to isolate the 'Inactive' state rather than adding it to the DoneStates btw.

An "Inactive" order can become active again, so it's not certain that it's done yet.

-- Ewald

Hi, I am looking for a coder to finish a semi functional code in python. This code has been organized and reviewed so it will be easy to work with but it still has a few bugs, needs another asset integration and a tweak in logic. Also it needs to be more reliable and disconnection proof. If interested please contact me directly to my email?Ferreira.helhazar@....

?

Let me know if it works for you!

?

Thanks

?We work in “units” of CME futures trading sessions (17:00 to 16:00 US/Central next day)... TWS API order status events and execution reports are very accurate and timely so that position controllers can adequately model reality based on streams of order state, order status, execution and commission reports, and market price update events.

开云体育

In general, reqMktData feeds seem to be quite stable and timely, too, John. Though we use them only to give context to our TickByTick and Level II data feeds, so we have less analysis for them. Keep in mind that most reqMktData feeds are aggregated over various time periods.

• The minimum delay we experience is 255ms. In other words it takes at least 255ms after the bar is closed for it to arrive in our TWS API client.
• Indeces (SPX, SPW, DJI, ...) and very liquid front month futures had average/median delays around 750ms
• Instruments with very little activity (such as futures expiring in 2024 and specialty instruments such as VXX.IV) had average/median delays around 1,100ms.
• For our mix of instruments, average/median delay for all 2,016,969 five second real time bars in June 20023 was around 960ms.

We have experienced flaky position updates in V10 TWS versions (at least in paper accounts) that we had not seen in TWS 981 before. But TWS API is not at fault since the TWS GUI shows the same incorrect positions.

Our API clients are not impacted since we have our own implementation of “Position” and “PNL”. The IBKR implementations may make sense for human traders but never worked for us (even when they are correct). Our biggest problem is that PNL resets around midnight. We work in “units” of CME futures trading sessions (17:00 to 16:00 US/Central next day) and API clients get confused when position PNL suddenly resets “around midnight”.

We have found execution reports, commission reports, and even order status updates to be very reliable and timely. Our (Java) framework is multi-threaded, entirely event driven, broken into many small focused domain classes, models, and controllers/managers. It is completely separate from and unaware of TWS API. A thin adapter layer translates abstract framework operations (such as placing orders) into actual TWS API requests. That layer also converts TWS API responses into framework events that are independent of TWS API.

Certain framework events (such as market price update events) are broadcast so that position controllers can easily maintain their own notion of current PNL. We rarely have partial order fills, but TWS API order status events and execution reports are very accurate and timely so that position controllers can adequately model reality based on streams of order state, order status, execution and commission reports, and market price update events.

The framework uses a domain/class/model hierarchy that looks something like this:

Accounts → [1:*] Account → Positions → [0:*] Position → Trades → [0:*] Trade → Orders → [0:*] Order

Our API clients never have to restart or resubscribe during the trading session in response to TWS API activities. There are, however, controlled automatic daily restarts of TWS and API clients during the one hour per day when Chicago futures markets are closed.

I agree that your order.done and order.done.wait logic is convoluted and I can see many cases where that can lead to lockups or, in case timeouts are too short, cause other issues. You might need to make your clients more event driven and put more distance between your trade decision logic, execution, and order management on one side and the actual operation of TWS API on the other side (design approaches such as “” and “”).

You need to make sure your client does not assume any order or timing of events (order state, order status, execution reports, errors), can tolerate the occasional duplication of updates, takes all events into consideration (not just order status), and does not block the TWS API callback thread.

We make heavy use of the Java built-in concurrency features from , specifically the (a Java language concept, has nothing to do with CME future contracts). I believe some of those concepts are available in Python through the .

Another good source for ideas how you can better structure your Python clients may be Ewald de Wit’s project.

But we are meandering away from the scope of this post and and the group.

闯ü谤驳别苍

Dear all,

I am using ExcelActiveX spreadsheet to connect to TWS and to relay my orders. The spreadsheet is based on IB’s sample ExcelActiveX spreadsheet where I added some VBA code to make it more user-friendly for everyday trading.

?

I've been using TWS version 981.3c for number of years without problems. Communication between ExcelActiveX spreadsheet and TWS worked flawlessly.

Recently IB has announced that they will stop supporting this version and that the minimum supported version will be 1019.2.

Normally, I would first construct an order inside Excel sheet and before sending it for execution to TWS, I would always first send a "What-If" order to get information on the Margin impact of such order. After I updated TWS to 1019.2 version I started experiencing following problem.

When I send a request for "What-If" order I get following error messages from TWS:

Error: 2169 WARNING: The 'FirmQuoteOnly' order attribute is not supported"
Error: 10268 The 'EtradeOnly' order attribute is not supported.

?

To bypass these errors, I specified the 'firmQuoteOnly' and ‘EtradeOnly’ order attributes as false.

?

With the above modification the error message was gone, my order was sent and TWS responded with the message ‘Submitted’. However, my order never arrived at TWS. There was nothing listed under that tab showing active orders.

?

Does anyone knows what are the changes in the TWS version 1019.2 comparing to 981.3c that could cause that my software can not place order any more?

?

How can I find out what went wrong when placing the order?

?

Thank you in advance for you help.

The insync group is generally a better place for ib_insync related issues, but I have the feeling you are correct and there are behavioral differences between TWS/IBGW V9 and V10 versions. Keep in mind the TWS/IBGW 981 track is more than two years old.

I can't recall where I saw it, but there was a comment about requesting market data via SMART in one of the IBKR TWS API or market data documents. It basically said that? you need market data subscriptions for all exchanges that SMART routing works with for a given instrument.

When you call reqContractDetails for SPY/STK/SMART/USD through TWS 981 versus your V10 versions, is there any difference in the list of valid exchanges?

You could try 'ARCA' instead of 'SMART' when you request market data since 'ARCA' is the primary exchange for SPY. But your market data feed would likely be focused on trades that take place only at 'ARCA'.

Also review your market data subscriptions a the error suggests. Adding the missing subscriptions may not be too expensive or may even be cost neutral.

Just a guess,

闯ü谤驳别苍