开云体育

It seems this was brought up here too.

I am facing the issue that I can not create a child order to an parent order using different quantities.

?

For example:

?

Parent order: 4901383488: 117,0,0: LMT SELL 1.000000@... DAY

Child order: 4901387616: 118,0,0: TRAIL SELL 49.000000@... DAY

?

When sending it to TWS the? total quantity of the child order will be set to 1 (the value from the parent order).

?

This was already a question on this topic here:

/g/twsapi/topic/94355322?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3A%2C%2C%2C0%2C0%2C0%2C94355322#?

But with no result.

So I am wondering if there are any news on this topic?

?

Is somebody else facing the same issue?

?

THX

I have the following bracket order,

ENTRY -> aapl limit buy GTC, conditionsCancelOrder=True, conditionsIgnoreRth = True -> $192.00 -> time conditional isMore=True, expires at 3:30pm
TAKEPROFIT -> aapl MIT sell GTC -> $200 
STOPLOSS -> aapl STOP sell GTC -> $190
CLOSE AT TIME -> aapl mkt sell GTC, conditionsCancelOrder=False, conditionsIgnoreRth=True, OutsideRth = True -> time conditional isMore=True, activates at 3:35pm

I wish to change my takeprofit into 2 parts and leave the rest of it intact, I want to do a LIT, LMT or darkice, order at 200 dollars. Then if it doesn't fill within 5 mins, I want to push the rest into a market or MIT order at 200. But if it happens at 3:30-3:34, the close at time should cover it and it should just market exit at 3:35.

So something like this,

ENTRY -> aapl limit buy GTC, conditionsCancelOrder=True, conditionsIgnoreRth = True -> $192.00 -> time conditional isMore=True, expires at 3:30pm
TAKEPROFITLIMIT -> aapl LMT/LIT sell GTC -> $200 
TAKEPROFITMKT -> aapl MKT sell GTC -> 5 mins later
STOPLOSS -> aapl STOP sell GTC -> $190
CLOSE AT TIME -> aapl mkt sell GTC, conditionsCancelOrder=False, conditionsIgnoreRth=True, OutsideRth = True -> time conditional isMore=True, activates at 3:35pm

Is something like this possible with ib/twsapi?

h future individually, also there is a lot more liquidity, than buying/selling the spread outright.

Well, weight in the fact that I am not a fan of Excel for handling fast pace data. (and here you deal with 'ticks' which is rated 2nd fastest data set of the API) Maybe other members have better experience.
Typically what seems an easy start may end up pretty painful, spending precious hours tweaking and 'workarounding' Excel limitations that will eventually fail to your expectations.

IMHO and without understanding if your purpose is to get an Excel spreasheet to look at, or to use Excel to compute and takje decision. Anyway you better organize "rendez-vous" in your code and get ride of "loop".
In short: you need a multi-thread method. yours seems single threaded. C# have good provision for it.

Assuming you never stop the 4th loop. Look to me that you need a 5th 'loop' (a thread in real), this is probably the most important for you within your current architecture, and it must be in a separate thread, this one only handle saving data.
Using SQL could be a simple solution as this will allow you to save faster (maybe) and more important collecting data from a central repository that by itself have all provision to handle concurrency of data access. This would preserve most of your existing code.

However depending upon how serious is your project you should use more of an appropriate language like Java or C# (in full) or C++ , it's not so hard to get some fundamental and it pay.
The API allows you to start any request you mention asynchronously and ASAP, Scanner answers are pretty slow, can be done at this moment. Be careful with contractdetails you may hit many pacing limitations.
IB have a pretty efficient and fast API, you can't keep up using Excel as the orchestrator.

Seems you use C#, keep the effort, if you don't know how to do multi-threading, start learning how to launch a thread, then either connect to a MySQL or learn how to share data between thread using a mutex, then ... many many details but later.

That sounds like a standard answer from a tier 1 support person. I would consider the counterpoints..

It's true there's a global interpreter lock, which may be in Python 3. It's also true that async code is single threaded, but in this circumstance you still need to be careful where you await. Finally, neither you nor IB mentioned anything about how many different instances of this program you may be running... if it's more than one you could certainly have a problem.

So again, since you haven't provided a picture of the whole system, there's no great point in speculation.

Of course testing is worthwhile, but static code analysis and formal verification are different beasts altogether. And, this is why I simply said "You might have problems but I won't conjecture on their likelihood."

I know my reply was somewhat esoteric. Therefore, to make up for that a tiny bit, I'd suggest that you use the "+= 1" idiom instead of adding constants to your order ID. In addition, you'll want to learn about different methods of doing an atomic increment in Python as well as how to leverage critical sections. You should be able to significantly "future proof" your code when and if necessary with those two things.

Still, these are all Python related (and concurrent programming) issues in general which the API can't address for you. Although I greatly enjoy the subject, it's a bit off-topic for this email group.

I contacted IB, they told me the following:

Concurrency assumes that two task may overlap each other in execution. In python GIL(Global Interpreter Lock) prevents multiple threads from accessing the same python object. Only one thread can hold the GIL at a time and one thread must wait for another thread to release the GIL before running.

If i understand everything right - your code will run one thread that will asynchronously place bracket orders.In this case this task is still single-threaded but asynchronous and you should not encounter any issues with order id's if they are incremented during the execution of run_loop().

So anyway, I tested my code yesterday on paper like 20 times and it seems to work fine, I checked there were no order id clashes.

I also made another version where there was a second queue inside the function for the orders themselves, meaning if 2 api calls for price came back at the same time, the orders will be queued up, but it works exactly the same as the first version I described. Will try it again on paper today.

On Sun, Aug 20, 2023 at 10:26 AM, omgwtfsalty@... wrote:

I am worried that I will place to orders at the exact same time and the order id's will get messed up.

You might have problems but I won't conjecture on their likelihood. They may not be exactly as you've described either, but there's no way to know much more from just a snippet of code. Details of the rest of the system need to be provided and considered... e.g. is this running in wsgi?

On Sun, Aug 20, 2023 at 10:26 AM, omgwtfsalty@... wrote:

Is there a way around this

Yes... of course. Potential solutions, however, have much more to do with Python and concurrent programming in general than they do with the IBKR API.

Check out my profile and follow the link to MIT's 6.031 class if you want to learn more about those topics. There's also a video by David Beasley in my profile... it's really great! But before you check those out, I suggest you sit through the 1986 videos of SICP and work through the book at the same time.... it's a masterpiece IMHO.

On Sun, Aug 20, 2023 at 10:26 AM, omgwtfsalty@... wrote:

does twsapi automatically mitigate this

Not really, this kind of thing is the responsibility of the end user. With a little work I'm sure you'll be able to come with something. Good luck!