开云体育

I haven't worked with Windows in a while but I don't think using a library changes too much from platform to platform. So, anyway...

I'd probably give a shot until you decide to dive into the depths of any build system.

@Gonzalo
Yes
IMHO that's same issue (or non issue) a first call reactivate the connection as the message explain it.
Once done and depending upon your TZ/Instrument TZ and RTH and ... your 'live' between ~3 min to ~15 min.
What you show as a 'strange' sequence may not be correlated,
Like you didn't use GW for 10 min (Hence the 2nd message), but in parallel IB did disconnect and reconnect your connection for other reasons (Hence the first message, what is interesting is the previous one too)
Anyway
- If you can spent 10 min doing nothing unlikely you need less than 100 millisecond response time for Historical data. (you can! just setup a heart beat)
- I get this also and it doesn't bother me or have any operational impact, it's just HMDS (Historical)

@Greg
Yes TWS does implicitly a 'heart beat'
As every instrument displayed may require a price update. While GW does only what you ask it (nearly).
But TWS is more hungry in memory and resources, and is not very server friendly.

You should think GW.
If an implementation doesn't work properly with GW, one day it may not work with TWS too.
Or the opposite TWS give you wrong impression that your code is self sufficient.
So that your fix using TWS to keep up tick-by-tick may hide another issue.

Hi,

I am trying to leverage Pytorch's C++ API with the TWS API in a single project. I have an existing project in Visual Studio that uses the TWS API. PyTorch for C++ really only supports a build using Cmake. So, I may be forced to make a new project with Cmake so I can use PyTorch. If that is the case, has anyone successfully built the C++ TWS API in a Cmake project? Because I need both of these APIs, desperately. If so, any tips on how I can go about this? I am a noob at Cmake...

Thanks,
Brendan

1- no need, it happens on first call. Make a dummy APPL historical and 'voila'

2- see above.
Understand that a service provider dislike having open connection doing nothing, so after a certain inactivity time (seems ~10 min) IB server does sever the connection, socket are a precious resources. The penalty to reconnect is very small (a couple of 100ms and on historical it hadrly hurt anything)
IB somewhere give too much, they show this idle state to you (many other platform only state connection status when it fail)

3- there are a lot a talks about this on this forum, with various philosophy and principles and limitations (you need to allow upgrades, you may want to take control of it , etc ...)
Personally I like restart everyday, if IB proceed that way that's because there are a couple of good reasons. So I won't be of help advising pro/con.

"All MOC orders must be received at NYSE markets by 15:50 ET, unless entered to offset a published imbalance. NYSE markets' rules also prohibit the cancellation or reduction in size of any market-on-close (MOC) order after 15:45 ET."

moc.ocaType = 3;
trailingStopLoss.ocaType = 3;

Hi 闯ü谤驳别苍 sorry for the double post, I just re read what you said and looked it up.

"All MOC orders must be received at NYSE markets by 15:50 ET, unless entered to offset a published imbalance. NYSE markets' rules also prohibit the cancellation or reduction in size of any market-on-close (MOC) order after 15:45 ET."

Now I understand what you mean. I probably can't use it in this case then. Thanks for the advice.

Hi 闯ü谤驳别苍, I tried on paper and it rejected the order with time conditions.

However I did this instead without the time condition and it seemed to go through yesterday a few mins before market close, will try it on paper today hopefully it works as intended.

Please let me know if I missed anything out.

1. My opening order should be cancelled at 3:45.

2. If the opening order fills, either the take profit, stop loss or MOC order should execute, any of them should cancel the rest.

Not sure if the tif for the MOC order should be "DAY" or "GTC" in this case.

    #1st part Opening
    opening = Order()
    opening.orderId = parentOrderId
    opening.action = "BUY" if quantity > 0 else "SELL"
    opening.orderType = "LMT"
    ....
    opening.conditionsCancelOrder = True 
    opening.conditionsIgnoreRth = True
    algo.FillAdaptiveParams(opening, adaptive_type)

    timeCondition = TimeCondition()
    timeCondition.time = timeCancel #15:40:00 cancel order
    timeCondition.isMore = True
    opening.conditions.append(timeCondition)

    #2nd part take profit or stoploss, if order filled above.
    takeProfit = Order()
    takeProfit.orderId = opening.orderId + 2
    takeProfit.action =  "SELL" if quantity > 0 else "BUY"
    takeProfit.orderType = "MIT"
    .....
    takeProfit.parentId = parentOrderId
    takeProfit.tif = "GTC"
    takeProfit.transmit = False

    stopLoss = Order()
    stopLoss.orderId = opening.orderId + 3
    stopLoss.action =  "SELL" if quantity > 0 else "BUY"
    stopLoss.orderType = "STP"
    .....
    stopLoss.parentId = parentOrderId
    stopLoss.tif = "GTC"
    stopLoss.transmit = False

    # Exit at closing time if take profit or stop loss not hit
    closing = Order()
    closing.orderId = opening.orderId + 4
    closing.action = "SELL" if quantity > 0 else "BUY"
    closing.orderType = "MOC"
    closing.totalQuantity = abs(quantity)
    closing.parentId = parentOrderId
    closing.tif = "DAY" 

    closing.transmit = True
    closing.conditionsCancelOrder = False
    closing.conditionsIgnoreRth = True
    closing.OutsideRth = True

    bracketOrder = [opening, takeProfit, stopLoss, closing]

You probably can't, but why don't you give it a quick try in TWS or via the API to get a better feel for how things work?

When you place a bracket order, IBKR wraps the attached orders (profit, loss, others) into a group for you. Only one of those attached orders should ever execute in case the parent fills.

MOC orders (and MOO for that matter) are not compatible with groups since they cannot be cancelled after a certain point in time before market close (MOC) or market open (MOO)..

• the order has more than one attached order (profit, loss, others)
• and one or more attached orders is of type MOC or MOO

闯ü谤驳别苍

Thanks for the suggestion, how would I put this MOC order within my bracket order, would this work?

Or do I not need to add a timecondition to an MOC order within this bracket?

# previous code replacing last part in bracket
# 3rd part: Sell Market order
moc = Order()
moc.orderId = opening.orderId + 3
moc.action = "SELL" if quantity > 0 else "BUY"
moc.orderType = "MOC"
moc.totalQuantity = abs(quantity)
moc.parentId = parentOrderId
moc.tif = "DAY" 

timeCondition = TimeCondition()
timeCondition.time = timeswitch
timeCondition.isMore = True
moc.conditions.append(timeCondition)

bracketOrder = [opening, trailingStopLoss, moc]
return bracketOrder

I guess the name of your subscription gives it away. Your market data permissions for CME futures is "for Display on Trading Platform" not for consumption in machine readable form via TWS API.

Market data is owned by the exchanges and licensed to companies such as IBKR so that they can offer subscriptions to their customers. Subscriptions for non-professional traders are generally less expensive than those for professionals, and subscriptions for "display to humans only" (raw, in the form of charts, for order entry, etc) is less expensive than subscriptions that provide access to raw real-time or historical data.

You'll need a market data subscription that permits access from a client application via TWS API.

闯ü谤驳别苍

order.HedgeType = "P";
order.HedgeParam = quantityRatio.ToString("F3", CultureInfo.InvariantCulture);

Thanks again for the very informative message.

This highlights a couple of points of confusion with the TWS API.

• The API doc describes the order attaching mechanism of bracket and hedge orders. It's implied they are just two order types that happen to make use of the parent-child relationship made available through attaching.
• When an order is marked as a hedge order quantity must be 0. However, as you say a bracket order also should default to 0 since it matches the parent quantity, so specifying the quantity is irrelevant. Yet they do not show any errors or warnings about setting quantity like they do with hedging.

This implies there's a mechanism by which an order can just be "attached" without being a bracket or a hedge order, and without having its quantities automatically modified.

Maybe there's some way to tell the TWS API that an order is not a bracket order but rather an attached order that should simply execute when the parent executes.

Edit: Actually, I originally misread your screenshot, I mistook different prices on each order to be quantities but now see that the quantity on all child orders is the same, 10 units.

That's too bad anyway if that really is the case. Back to building a function that responds appropriately to incoming events.

contract vs eurusd_contract

Could that be a possibility or did you copy and paste incorrectly? Have you considered using a more strongly typed language?