Re: paper account and live account on same machine but different user

Thank you for your inputs, I will try them because the answer from IB is this one:

Thank you for contacting IBKR Client Services.

To be able to have market in both live and paper account, you need to log in to these accounts on the same Windows user profile.
If you use another Windows user, for the TWS it is like you're using a different device.
Unfortunately, there is no way to change this.

Thank you for your understanding!

Show quoted text

El mié, 1 mar 2023 a las 16:07, Hartmut Bischoff (<topofocus@...>) escribió:

the simplest solution: connect your client to both machines. One connection is used for data gathering, the other for ordering.

More complex, but easier to manage: connect your client to the production system and use it for data-processing. Generate orders, but transmit them via a remote-client to the paper-trading account.
We are using rabbitMQ for data-transmission. Works like a charm.

Linde PLC, what am I doing wrong?

#50771

I'm pretty sure that there must be a simple explanation for this but I can't find it.
I am downloading historical data for Linde PLC daily from NYSE. IB symbol LIN, conid 338719530. Since the last few days does this result in an error message, saying that this instrument is unknown. The last time that this was successful was at the end of the February 27 trading day (OHLC data received). I looked in IB's contract database and there it is present: both the symbol and conid are correct. Checking the newspapers I found that Linde recently stopped their listing at the Frankfurt stock exchange, but that their listing at NYSE is unaffected.
Instruments details provided: IB symbol LIN, conid 338719530, exchange NYSE, currency USD. "No contract found" is what I get back from the server.
What am I doing wrong? Or, what has changed a few days ago?

Re: paper account and live account on same machine but different user

#50770

the simplest solution: connect your client to both machines. One connection is used for data gathering, the other for ordering.

More complex, but easier to manage: connect your client to the production system and use it for data-processing. Generate orders, but transmit them via a remote-client to the paper-trading account.
We are using rabbitMQ for data-transmission. Works like a charm.

Re: paper account and live account on same machine but different user

#50769

Something that did work for me, from different machine (with different public IP),never tried on same machine.

Login using Live.
Login again on Live from your other Win user.
It should tell you that you are already in session and suggest procedure to abort the other session,
Bottom right of login window, you should have an option to continue login with the real account but it in "read only" mode.

I don't know if I share same pacing limitations, but I assume so.
Never tried this,? on a paper account or a mix, I don't even know if the option exist on paper login.

BTW: if need both, I always login live before paper.

Not sure that this is not a "miss" from IBKR. In the document Jurgen point it out they suggest to create a 2nd user and to pay for it.
So it maybe that they lock this later. (However it would defy the purpose of this option).

Re: paper account and live account on same machine but different user

#50768

开云体育

I wouldn’t waste your time bothering with a ticket. It won’t get anywhere. This is not a bug, it’s a result of their licensing deals with the data providers. If they allowed two different users to receive the data concurrently on the same physical or virtual computer, it would break the terms of that deal.

?

And it’s no good saying that although the two users are both logged in, only one session can be accessed at a time, because that’s not true on Windows Server: I run two different sessions under different user most of the time, and those two sessions can be remotely accessed by two different people at the same time from different client computers. Besides, even on non-server Windows or Linux two sessions running under different users can both be running programs that use the data simultaneously.

?

Richard

?

Show quoted text

From: [email protected] <[email protected]> On Behalf Of joanmarcel119
Sent: 01 March 2023 09:30
To: [email protected]
Subject: Re: [TWS API] paper account and live account on same machine but different user

?

Thank you 闯ü谤驳别苍, I've just opened a ticket to API on IB's Message center. If I get a solution then I will post it here.

?

Best regards

?

El mar, 28 feb 2023 a las 18:45, 闯ü谤驳别苍 Reinold via (<TwsApiOnGroupsIo=[email protected]>) escribió:

The only documentation that I am aware of is and the second row of the "Case 1" table seems to describe your situation.
However, they do not go into detail of how "location of device 1" is determined under Windows. It could very well be that two different Windows users on the same machine are considered two different locations. Probably a question directly to IBKR.
闯ü谤驳别苍

Re: paper account and live account on same machine but different user

#50767

Thank you 闯ü谤驳别苍, I've just opened a ticket to API on IB's Message center. If I get a solution then I will post it here.

Best regards

El mar, 28 feb 2023 a las 18:45, 闯ü谤驳别苍 Reinold via (<TwsApiOnGroupsIo=[email protected]>) escribió:

Show quoted text

The only documentation that I am aware of is and the second row of the "Case 1" table seems to describe your situation.

However, they do not go into detail of how "location of device 1" is determined under Windows. It could very well be that two different Windows users on the same machine are considered two different locations. Probably a question directly to IBKR.

闯ü谤驳别苍

Re: paper account and live account on same machine but different user

#50766

The only documentation that I am aware of is and the second row of the "Case 1" table seems to describe your situation.

However, they do not go into detail of how "location of device 1" is determined under Windows. It could very well be that two different Windows users on the same machine are considered two different locations. Probably a question directly to IBKR.

闯ü谤驳别苍

paper account and live account on same machine but different user

#50765

Hi there,

I've been searching for info about this but with?no luck.?

I can use paper & live from the same machine and same user but I didn't know that changing the Windows user could run into?problems. After creating a new user on the same Windows laptop to run the TWS paper account from it and at the same time opening the TWS live account (different port) on the other user account I get the error?message :

(10197) No market data during competing live session on the paper trading account?and I can't get to solve this?problem.

Any?suggestions?

Thank you!

Re: Get option strategy type

#50764

Just add all con_id's of your bag, multiply it with -1 and use this? number as con_id for your bags.

You get well designed contracts in your own? database and? can even implement some sort of quality management, in case something happened to one leg-component.

That's how its solved in ib-ruby.

hartmut

Re: Get option strategy type

#50763

开云体育

As you suspected, the API doesn’t support it. You need to implement any option strategy detection on your client.?

On Feb 26, 2023 at 12:48 PM -0800, Simon Steiner via groups.io <steinersimon@...>, wrote:

Show quoted text

Hi,

I trade option strategies in TWS, and I make great use of the predefined strategies (Spreads, Butterfly, etc.) of the Strategy Builder:

<dummyfile.0.part>

After executing a strategy, TWS shows the strategy name under 'Financial Instrument' in the portfolio app. If I open the instrument description, it also shows the strategy like this for example:
<dummyfile.1.part>

When I pull information from the API I haven't seen this information anywhere (not in execDetails, openOrders, positions, etc.)
Am I missing something, or is there simply no way to either extract the strategy type information from the executions, nor to alternatively request the information somehow through the API?

When I manually create an option strategy through a combo contract and pass that contract to the reqContractDetails request, I get an error: "'BAG' isn't supported for contract data request. Please enter a valid security type".?
Is the only way to assign a strategy type to my execution by creating some sort of reverse logic on the client side? For instance what I could extract every leg of a combo order and see if they match any pre-defined strategy. I had hoped I wouldn't have to implement that, but that the API makes this easier somehow.

Curious what approach others may have, since this must be a common issue.

Thanks,
Simon

Get option strategy type

#50762

Hi,

I trade option strategies in TWS, and I make great use of the predefined strategies (Spreads, Butterfly, etc.) of the Strategy Builder:

After executing a strategy, TWS shows the strategy name under 'Financial Instrument' in the portfolio app. If I open the instrument description, it also shows the strategy like this for example:

When I pull information from the API I haven't seen this information anywhere (not in execDetails, openOrders, positions, etc.)
Am I missing something, or is there simply no way to either extract the strategy type information from the executions, nor to alternatively request the information somehow through the API?

When I manually create an option strategy through a combo contract and pass that contract to the reqContractDetails request, I get an error: "'BAG' isn't supported for contract data request. Please enter a valid security type".?
Is the only way to assign a strategy type to my execution by creating some sort of reverse logic on the client side? For instance what I could extract every leg of a combo order and see if they match any pre-defined strategy. I had hoped I wouldn't have to implement that, but that the API makes this easier somehow.

Curious what approach others may have, since this must be a common issue.

Thanks,
Simon

Re: Historical Data Download : Compare Experiences

#50761

The error reported when making a reqHeadTimestamp() to VICI (or the other 3 stocks I mentioned from the SP500 - I am sure there are others as well) is interesting and gives some insight to the way the API command works internally. Clearly the code calls its own 'reqHistoricalData()-like' function to find the earliest date which then fails in exactly the same way that a call to reqHistoricalData() does with a period longer than available data. I suspect this internal call is the source of the eventual pacing problem that never responds.

Try calling reqHeadTimestamp() on 500+ symbols in a row with the 20ms gap (i.e. 50 API calls per second) and your code will eventually hang with no error reported.

I agree with Richard that a call to reqHeadTimestamp() is useless since usually setting a duration that goes before the head timestamp will not cause any error. In the case it does, reqHeadTImestamp() doesn't help either due to the internal way it calls its own reqHistoricalData().

In case anyone is interested in the workaround I implemented, for those 4 stocks (AAL, LIN, MNST, VICI) I used the TWS Daily Chart to go back to the earliest date I could get and used this as my reference point for an exception table in my database. As long as you do not ask for data before that point in time then there will be no error in the call to reqHistoricalData(). It is interesting to note that the same error will appear on the top left of the TWS Chart if you try to get monthly bars that go back before this reference date so there is a clear bug in their data which goes beyond just the API.

Thanks for everyone's input on this. I have finally found a way to automatically load a long history (25 years tested successfully) of any list of US stocks without failure.

Re: Historical Data Download : Compare Experiences

#50760

开云体育

Contrary to what you say, reqHeadTimestamp for VICI does not ‘never answer’: it returns an error 162:

?

“Historical Market Data Service error message:No historical market data for VICI/STK@VALUE Last 0”

?

Personally, I never use reqHeadTimestamp at all: I see no value in it.

?

Richard

Re: Problem retrieving option strings with TWS API

#50759

Sorry in last past I was too quick and slip on that.
I now understand how you qualify Bid/Ask,
You interpret the tickType in call back. That's ligit, Just that I am not sure would it that way,
This means that you probably don't have hang on a missing handler but just that no event happens during the sleep.

Try to use reqTickByTickData

Re: Problem retrieving option strings with TWS API

#50758

maybe somebody more familiar with Python should help you
In general
I see that:

0- You use "global" parameters as way to transmit information from proc to proc (or main)
That is very dangerous, global are the worst thing on earth when the language allow object programming, it should simply not exist!!

in particular you should at least do
??? prixtick =0
??? bid= 0
??? ask =0
in your
for i in range(j)
Loop

1- you use time.sleep(1)
That's a very bad habit, because IBK use an 'asynchronous mode' (Subscribing to events) and nothing guaranty that you will get any answer within your sleep.
asynchronous? is a good thing because you are sure to catch faster and in time what happens, but bad in the sense that if nothing happens you do some processing anyway and on old or false data.
This is a different philosophy of coding: Unless you use a multithread/multiprocess approach (highly commendable) at least you should put a maximum of your processing in the handler of the callback,? Surely not in a main loop.
IBKR will queue events in case you don't process them fast enough (well... to a certain extent)

2- You only did implement tickPrice
While it maybe enough it is a bad practice, you better implement a default for all tick call back

?>>tickSize(id,...), >>tickGeneric(id,...), >>tickPrice(id,...), >>marketDataType(id,...), >>tickSnapshotEnd(id)

Because it may happens (again not familiar with python) that you hang on next call from IBKR that would be tickSize.
All that are old in my mind, I did wrote an abstraction layer and no longer remember details. But I see a comment in my code that may shade some light on this:
/*??? For bid, ask, and last data, there will always be a IBApi::EWrapper::tickSize callback following each IBApi::EWrapper::tickPrice.
?? ?IBApi::EWrapper::tickSize is also invoked every time there is a change in the size of the last traded price.
?? ?For that reason, there will be duplicate tickSize events when both the price and size of a trade changes.
*/

3- I don't use reqMktData to get tick data, I only use it or rates/RT volumes and alike kind of aggregated data set.
I use reqTickByTickData
you can specify the number of tick to look in past , 1 is a valid value.? and you should listen to tickByTickBidAsk? this is safer!
I am even unable to understand how to qualify as Bid or Ask what you receive back from tickPrice? as your request? didn't specify anything about that.
But again you need to implement 2 handler for historical ticks
From comments in my code:
/*
https://interactivebrokers.github.io/tws-api/tick_data.html
?if a non-zero value is input for the argument numberOfTicks in IBApi::EClient::reqTickByTickData,
?historical tick data is first returned to one of the functions
?IBApi::EWrapper::historicalTicksLast, IBApi::EWrapper::historicalTicksBidAsk, or IBApi::EWrapper::historicalTicks, respectively.
*/

4- Tick Types is an important matter
you didn't specify any. While it give you a default result, you better decide by yourself what you want to listen to.
see:

Re: Historical Data Download : Compare Experiences

#50757

Shared from my desk:
I am unable to catch the rule used by IBKR for pacing reqHeadTimestamp. But there is one!
But I got the feeling that exhaustive scrutation is disliked by IBKR and a batch does worst than interwoven request.I rarely have pacing violation with reqHeadTimestamp, It simply take forever to answer (and for some combination it simply never answer, like VICI/NYSE/CONID)

I "feel" pacing rule to be partly handled in TWS or GW, as it seems that disconnect/reconnect will improve your chance to retry successfully sooner.
It seems also related to reqHistorical, and all alike data activities, the more data requests you do, the less chance that reqHeadTimestamp run trough. Somewhere that make sense.

I feel an unsound practice to call reqHeadTimestamp at each reqHistorical.
With the caveat that there seems to be a multiplicity of headstamp, they differ for each exchange and also with the Whatoshow.
I default to "SMART" "Trades" to get a worst case situation but doesn't mean IBKR doesn't have more data available on a specific case.

I do caching of it, general update once a month. Seems enough.
Batch size of 150. The first 30 generally come fast, the next 70 are painfully slow, and sometime I am lucky enough to get the last 50.
With a cool down period of 2 hours, take about 10 days to update all US. (may it can be done at faster pace, was fast enough for me and no time to dig more)
I never do parallel calls on reqHeadTimestamp. This seems worst than waiting each answer to trigger next request if you want to improve your chance to get more than 30 headstamp quickly.

?

Re: Problem retrieving option strings with TWS API

GUY

#50756

开云体育

Thank you very much Gordon,

Attached, you have the python code

Here is the result:

------- enregistrement des données -------

0 -C 20230303 bidc 27.95 askc 28.35 strike 118.0 -P bidp 27.95 askp 28.35

1 -C 20230303 bidc 27.95 askc 28.35 strike 119.0 -P bidp 27.95 askp 28.35

2 -C 20230303 bidc 27.95 askc 28.35 strike 120.0 -P bidp 27.95 askp 28.35

3 -C 20230303 bidc 27.95 askc 28.35 strike 121.0 -P bidp 27.95 askp 28.35

4 -C 20230303 bidc 27.95 askc 28.35 strike 122.0 -P bidp 27.95 askp 28.35

5 -C 20230303 bidc 27.95 askc 28.35 strike 123.0 -P bidp 27.95 askp 28.35

6 -C 20230303 bidc 27.95 askc 28.35 strike 124.0 -P bidp 27.95 askp 28.35

7 -C 20230303 bidc 27.95 askc 28.35 strike 125.0 -P bidp 27.95 askp 28.35

8 -C 20230303 bidc 27.95 askc 28.35 strike 126.0 -P bidp 27.95 askp 28.35

For the first row (0), I get ask ,bid for strike 118 . the result is correct and compliant with the TWS platform. But for rows >0 , bid and ask are the same because MktData is not updated

maybe it is necessary to send a parameter to reqMktData to force the update

Thank you again for your help

Cordially

guy

Show quoted text

envoyé : 24 février 2023 à 15:50
de : "Gordon Eldest via groups.io" <hymagik@...>
à : [email protected]
objet : Re: [TWS API] Problem retrieving option strings with TWS API

You should include the code of your request as is in your code, including the parameters you used, especially the "tick types" you used? and bool flags.
This feature work.

1- What do you mean by "the function don't be triggered and I keep the bid and the Ask of the first Strike"
If the function doesn't come back, it doesn't deliver anything. you bid and ask is probably remnant of your last call.

2- What do you mean by "change the strike" ?
IBKR work using Contract to identify the instrument, the strike price is part of the contract.
I interpret what you wrote as: "I change the contract." please confirm.

TEST_option6.py

Re: Connectivity issue.

#50755

I see the same issue on the IBGateway.? Not sure how long its been with us, but certainly since late Feb.?? For me most days, it does this once:? The first API program to connect, will be instantly disconnected from the IBGateway.? Mostly just once a day, but early on it was several times in a row.

Now the IBGateway comes with lots of internal logs to explore and I think it reveals the cause.

Early in the IBGateway log we get these lines about the new client:

2023-02-24 03:00:27.066 [BR] INFO? [JTS-EServerSocketNotifier-86] - Starting async queue thread

2023-02-24 03:00:27.067 [BR] INFO? [JTS-EServerSocket-85] - [2147483647:176:176:1:0:0:0:SYS] Starting new conversation with client on 127.0.0.1

2023-02-24 03:00:27.069 [BR] INFO? [JTS-EServerSocket-85] - [2147483647:176:176:1:0:0:0:SYS] Server version is 176

2023-02-24 03:00:27.069 [BR] INFO? [JTS-EServerSocket-85] - [2147483647:176:176:1:0:0:0:SYS] Client version is 176

2023-02-24 03:00:27.069 [BR] INFO? [JTS-EServerSocket-85] - [2147483647:176:176:1:0:0:0:SYS] is 3rdParty true

2023-02-24 03:00:27.075 [BR] INFO? [JTS-EServerSocket-85] - Ignoring API request 'jextend.b6' since API is not accepted.

2023-02-24 03:00:27.076 [BR] INFO? [JTS-EServerSocketNotifier-86] - Terminating async queue thread

Note that 2 last line: ?? "Ignoring API request 'jextend.b6' since API is not accepted."?? Problem here is the API client never sends that text - it seems to be a left over string within the Gateway...i.e. an uninitialized buffer or string.

Now, when it does connect successfully, that same line above will read:

2023-02-24 03:00:31.054 [BR] INFO? [JTS-EServerSocket-90] - [2147483647:176:176:1:0:0:0:SYS] Starting new conversation with client on 127.0.0.1

2023-02-24 03:00:31.054 [BR] INFO? [JTS-EServerSocketNotifier-91] - Starting async queue thread

2023-02-24 03:00:31.054 [BR] INFO? [JTS-EServerSocket-90] - [2147483647:176:176:1:0:0:0:SYS] Server version is 176

2023-02-24 03:00:31.054 [BR] INFO? [JTS-EServerSocket-90] - [2147483647:176:176:1:0:0:0:SYS] Client version is 176

2023-02-24 03:00:31.054 [BR] INFO? [JTS-EServerSocket-90] - [2147483647:176:176:1:0:0:0:SYS] is 3rdParty true

2023-02-24 03:00:31.057 [BR] INFO? [JTS-EMsgPacer-93] - Can't parse cutoffVersion [null]

... then more lines about connection status

This time the IBGateway thinks the variable of? "cutoffVersion" has been set to null, which is likely a proper value here, and the connection proceeds as normal.

So that I believe the cause of the fault of mysterious failure to connect:? an uninitialaized variable in the IBGateway and possibly the TWS code.

Interactive Brokers... are you reading this?

?

Error 10195 when placing FX hedge

#50754

Hi everyone, been running into a problem recently attempting to place a forex hedge () resulting in the following error:

Error: 10195. Error Msg: Invalid order parameters supplied when trying to set "Use parent trade price at the time of fill" on an order: server: 1 order: 1127 parent: 1126.

I am on the most recent TWS API and TWS/Gateway versions.

The parent order is successfully put through and I can see it in TWS pending transmission to the servers:

? ? ? ? contract = Contract()
? ? ? ? contract.symbol = 'ALK'
? ? ? ? contract.secType = "CFD"
? ? ? ? contract.exchange = "SMART"
? ? ? ? contract.currency = 'USD'

? ? ? ? order=Order()
? ? ? ? order.action='BUY' 
? ? ? ? order.totalQuantity=quantity
? ? ? ? order.orderType = 'MKT' ?
? ? ? ? order.transmit=False ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? order.eTradeOnly = False 
? ? ? ? order.firmQuoteOnly = False? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? self.ib.placeOrder(orderId,contract,order) ? 
 parentOrderId=orderId
 orderId += 1 ?

But when I try to put the forex hedge through as below, it returns the error 10195. I have tried IB API Support and despite them agreeing that my order and contract specifications look good, they are able to replicate the error but are unsure where the problem lies - any fresh eyes able to see where I've gone wrong? Thanks!

? ? ? ? contract=Contract()
? ? ? ? contract.symbol = 'AUD' 
? ? ? ? contract.secType = "CASH" ?
? ? ? ? contract.exchange = "IDEALPRO" 
? ? ? ? contract.currency = 'USD' ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
? ? ? ? order=Order()
? ? ? ? order.action='SELL' 
? ? ? ? order.orderType='MKT'
? ? ? ? order.totalQuantity = 0
? ? ? ? order.parentId = parentOrderId
? ? ? ? order.hedgeType = "F"
? ? ? ? order.eTradeOnly = False 
? ? ? ? order.firmQuoteOnly = False? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? self.ib.placeOrder(orderId,contract,order) ? 

Re: Historical Data Download : Compare Experiences

#50753

> The problem is that when the reqHeadTimestamp() faces a pacing error it hangs and doesn't recover and it doesn't report any error messages
Thank you for posting this, some of my code to download data started hanging a few months ago. I ended up setting alarms and using signal handlers, but it was a pain to deal with and I never bothered tracking down the cause. I may remove the reqHeadTimestamp() or run them in a separate process and cache the results.