开云体育

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?

You're not using wifi by any chance, are you?

Anyway, if you're ever wondering which end of your system can't keep up I suggest playing with dd progress=status for a few minutes.

Good luck!

Yes
No need to upgrade, especially this have nothing to do (or not enough) with GPU. It's only CPU based computation. Better invest in SSD than GPU
I guess your testing method (Still unclear to me how you proceed)? is not suited to what you want to check, and as @buddy suggest it, write a dumb CSV and check it later to get confidence.
'rogers'

I don't know how. Generally manual and automated are not very easy to run simultaneously. Trend is to add Manual capabilities UI directly on your automate so that your automate DB can store info
If this is for auditing and not millisecond oriented, maybe take a look at info that would match your desire using