Re: Target order in bracket order not being placed!
Without a lot of research into your code what jumps at me is that you assign the same orderId to the profitTaker and trailStop orders. Both are set to "parent.orderId + 1'.
Using this incremental orderId assignment is a very bad idea (yes, I know even IBKR uses it in code examples - still bad idea). You should implement a small orderId manager that increments the orderId each time you call it. Something like this:
parentOrder = nextOrderId()
...
takeProfit.orderId = nextOrderId()
...
trailstop.orderId = nextOrderid()
´³¨¹°ù²µ±ð²Ô
On Thu, Nov 30, 2023 at 04:08 PM, nesbitcrab wrote:
I am at my wits end here, and have pulled out what his left of my hair trying to resolve this. The code below is basically to place two identical orders, but one with take profit and the other without. No errors are generated when I run the code, and both orders are placed (qty, stp lmt, trail etc.) but not the take profit for some reason. What am I doing wrong. Image of orders on TWS, and code below. Thank you.?
wb = xw.Book("SendOrders.xlsm")
ws1 = wb.sheets["Main"]
def BracketStopLimitOrder(parentOrderId: int, action: str, quantity: int,
limitPrice: float, stopPrice: float, takeProfitLimitPrice: float, trailingPercent: float, trailStopPrice: float):
parent = Order()
parent.orderId = parentOrderId
parent.action = action
parent.orderType = "STP LMT"
parent.totalQuantity = quantity
parent.lmtPrice = limitPrice
parent.auxPrice = stopPrice
parent.transmit = False
takeProfit = Order()
takeProfit.orderId = parent.orderId + 1
takeProfit.action = "SELL" if action == "BUY" else "BUY"
takeProfit.orderType = "LMT"
takeProfit.totalQuantity = quantity
takeProfit.lmtPrice = takeProfitLimitPrice
takeProfit.parentId = parentOrderId
takeProfit.transmit = False
# [trailingstop]
trailstop = Order()
trailstop.orderId = parent.orderId + 1
trailstop.action = "SELL" if action == "BUY" else "BUY"
trailstop.orderType = "TRAIL"
trailstop.totalQuantity = quantity
trailstop.trailingPercent = trailingPercent
trailstop.trailStopPrice = trailStopPrice
trailstop.parentId = parentOrderId
trailstop.outsideRth = True # I added this additionally
trailstop.transmit = True
bracketOrder = [parent, takeProfit, trailstop]
return bracketOrder
def BracketStopLimitOrder2(parentOrderId: int, action: str, quantity: int,
limitPrice: float, stopPrice: float, trailingPercent: float, trailStopPrice: float):
parent = Order()
parent.orderId = parentOrderId
parent.action = action
parent.orderType = "STP LMT"
parent.totalQuantity = quantity
parent.lmtPrice = limitPrice
parent.auxPrice = stopPrice
parent.transmit = False
#[trailingstop]
trailstop= Order()
trailstop.orderId = parent.orderId + 1
trailstop.action = "SELL" if action == "BUY" else "BUY"
trailstop.orderType = "TRAIL"
trailstop.totalQuantity = quantity
trailstop.trailingPercent = trailingPercent
trailstop.trailStopPrice = trailStopPrice
trailstop.parentId = parentOrderId
trailstop.outsideRth = True # I added this additionally
trailstop.transmit = True
bracketOrder = [parent, trailstop]
return bracketOrder
order_placed = ws1['J2']
ticker_symbol = ws1['B2'].value
order_qty = ws1['C2'].value
order_lmt_Prc = ws1['D2'].value
order_lmt_Prc = round(order_lmt_Prc, 2) # this was needed to prevent the error "The price does not conform to the minimum price variation for this contract"
aux_stop_prc = ws1['E2'].value
aux_stop_prc = round(aux_stop_prc, 2) # this was needed to prevent the error "The price does not conform to the minimum price variation for this contract"
target_profit = ws1["H2"].value
target_profit = round(target_profit, 2)
submit_it = ws1['I2'].value
trailing_percent = ws1["F2"].value
trailing_percent = round(trailing_percent, 2)
trailstpprc = ws1["G2"].value
trailStpprc = round(trailstpprc, 2)
# note for above code. for 'round' not to return error, values in corresponding excel cells cannot be blank
if submit_it == 1:
# create contract
ticker_contract = Stock(ticker_symbol, 'SMART', 'USD')
ib.qualifyContracts(ticker_contract)
# create bracket order
bracket = BracketStopLimitOrder(ib.client.getReqId(), action='BUY', quantity=order_qty, limitPrice=order_lmt_Prc,
stopPrice=aux_stop_prc, takeProfitLimitPrice=target_profit, trailingPercent=trailing_percent, trailStopPrice=trailStpprc)
# place bracket order
for ord in bracket:
ib.placeOrder(ticker_contract, ord)
ib.sleep(1)
# create contract
ticker_contract = Stock(ticker_symbol,'SMART', 'USD')
ib.qualifyContracts(ticker_contract)
# create bracket order
bracket2 = BracketStopLimitOrder2(ib.client.getReqId(), action='BUY', quantity=order_qty, limitPrice=order_lmt_Prc,
stopPrice=aux_stop_prc, trailingPercent=trailing_percent, trailStopPrice=trailStpprc)
#place bracket order
for ord in bracket2:
ib.placeOrder(ticker_contract, ord)
ib.sleep(1)
order_placed.value = "Yes"
|
Target order in bracket order not being placed!
I am at my wits end here, and have pulled out what his left of my hair trying to resolve this. The code below is basically to place two identical orders, but one with take profit and the other without. No errors are generated when I run the code, and both orders are placed (qty, stp lmt, trail etc.) but not the take profit for some reason. What am I doing wrong. Image of orders on TWS, and code below. Thank you.?
toggle quoted message
Show quoted text
wb = xw.Book("SendOrders.xlsm")
ws1 = wb.sheets["Main"]
def BracketStopLimitOrder(parentOrderId: int, action: str, quantity: int,
limitPrice: float, stopPrice: float, takeProfitLimitPrice: float, trailingPercent: float, trailStopPrice: float):
parent = Order()
parent.orderId = parentOrderId
parent.action = action
parent.orderType = "STP LMT"
parent.totalQuantity = quantity
parent.lmtPrice = limitPrice
parent.auxPrice = stopPrice
parent.transmit = False
takeProfit = Order()
takeProfit.orderId = parent.orderId + 1
takeProfit.action = "SELL" if action == "BUY" else "BUY"
takeProfit.orderType = "LMT"
takeProfit.totalQuantity = quantity
takeProfit.lmtPrice = takeProfitLimitPrice
takeProfit.parentId = parentOrderId
takeProfit.transmit = False
# [trailingstop]
trailstop = Order()
trailstop.orderId = parent.orderId + 1
trailstop.action = "SELL" if action == "BUY" else "BUY"
trailstop.orderType = "TRAIL"
trailstop.totalQuantity = quantity
trailstop.trailingPercent = trailingPercent
trailstop.trailStopPrice = trailStopPrice
trailstop.parentId = parentOrderId
trailstop.outsideRth = True # I added this additionally
trailstop.transmit = True
bracketOrder = [parent, takeProfit, trailstop]
return bracketOrder
def BracketStopLimitOrder2(parentOrderId: int, action: str, quantity: int,
limitPrice: float, stopPrice: float, trailingPercent: float, trailStopPrice: float):
parent = Order()
parent.orderId = parentOrderId
parent.action = action
parent.orderType = "STP LMT"
parent.totalQuantity = quantity
parent.lmtPrice = limitPrice
parent.auxPrice = stopPrice
parent.transmit = False
#[trailingstop]
trailstop= Order()
trailstop.orderId = parent.orderId + 1
trailstop.action = "SELL" if action == "BUY" else "BUY"
trailstop.orderType = "TRAIL"
trailstop.totalQuantity = quantity
trailstop.trailingPercent = trailingPercent
trailstop.trailStopPrice = trailStopPrice
trailstop.parentId = parentOrderId
trailstop.outsideRth = True # I added this additionally
trailstop.transmit = True
bracketOrder = [parent, trailstop]
return bracketOrder
order_placed = ws1['J2']
ticker_symbol = ws1['B2'].value
order_qty = ws1['C2'].value
order_lmt_Prc = ws1['D2'].value
order_lmt_Prc = round(order_lmt_Prc, 2) # this was needed to prevent the error "The price does not conform to the minimum price variation for this contract"
aux_stop_prc = ws1['E2'].value
aux_stop_prc = round(aux_stop_prc, 2) # this was needed to prevent the error "The price does not conform to the minimum price variation for this contract"
target_profit = ws1["H2"].value
target_profit = round(target_profit, 2)
submit_it = ws1['I2'].value
trailing_percent = ws1["F2"].value
trailing_percent = round(trailing_percent, 2)
trailstpprc = ws1["G2"].value
trailStpprc = round(trailstpprc, 2)
# note for above code. for 'round' not to return error, values in corresponding excel cells cannot be blank
if submit_it == 1:
# create contract
ticker_contract = Stock(ticker_symbol, 'SMART', 'USD')
ib.qualifyContracts(ticker_contract)
# create bracket order
bracket = BracketStopLimitOrder(ib.client.getReqId(), action='BUY', quantity=order_qty, limitPrice=order_lmt_Prc,
stopPrice=aux_stop_prc, takeProfitLimitPrice=target_profit, trailingPercent=trailing_percent, trailStopPrice=trailStpprc)
# place bracket order
for ord in bracket:
ib.placeOrder(ticker_contract, ord)
ib.sleep(1)
# create contract
ticker_contract = Stock(ticker_symbol,'SMART', 'USD')
ib.qualifyContracts(ticker_contract)
# create bracket order
bracket2 = BracketStopLimitOrder2(ib.client.getReqId(), action='BUY', quantity=order_qty, limitPrice=order_lmt_Prc,
stopPrice=aux_stop_prc, trailingPercent=trailing_percent, trailStopPrice=trailStpprc)
#place bracket order
for ord in bracket2:
ib.placeOrder(ticker_contract, ord)
ib.sleep(1)
order_placed.value = "Yes"
|
Re: Market depth data has been RESET. Error Code: 317, C++ Program
Any clue you can give on which instrument generate it ? At what time ?
How many rows did you look for ?
What did you choose for isSmartDepth ?
I would be very interested to know if you still see updateMktDepth messages arriving after your 317 for the same reqid. This is a sine qua non condition to avoid re-doing a request
I don't see any rationalized method to avoid it as I see this as a message from IB that should be implemented (many errors are to be seen as message).
Nothing I foresee that can be done from client side, but if I have to guess I would say that isSmartDepth? may influence this.
The full message is "Market depth data has been RESET. Please empty deep book contents before applying any new entries."
As I can't reproduce at will, I can only tell you what I implemented as a provision: If I receive a 317 then I do what IB asks:
I purge my bank, and de-facto expect to only receive types 2, or 1 only after I received a first set of new insert (0).? At least I assert that next new message will be an insert.
Note:
I have a counter averaging the number of entries I should expect and restart the algo only once I reach this threshold/2? (to avoid taking decision on too few entries) this of course depend upon your algo.
What I didn't do and probably should, is to call again to update the exch mapping. It may have changed (unlikely that it did change a lot, hence lack of motivation to finish this part, also this require a new request) Anyway at least a mapping to an unknown exchange throw an exception.
Unless mistaken this approach doesn't need to restart a new request (as opposed to error like the 316) hence can stay in same processing thread, but again it's a provision and I have/had no method to QA it
|
Market depth data has been RESET. Error Code: 317, C++ Program
Hi All,
Lately, I have been seeing the error code: 317 periodically appear when streaming reqMktDepth() repeatedly, in my main trade logic loop. Currently, I am building the order book through the updateMktDepth() callback one reception at a time and storing it in a pair of sorted vectors for bid/ask. Why might this message pop up? How can I avoid it (different designs, etc.)? If it does continue to pop up, how can I empty the deep book contents before applying new entries? Right now, I am trying to avoid using another thread to stream this separately, so I can get a simple application up and running before going to a multi-threaded design. How would someone recommend avoiding this error message in a simple 1 thread design?
Thank you,
Brendan
|
|
|
Hi all,
?
Have a newbie question here. I've gone through the notebooks and code recipes on the ib-insync page but needing more example code. Where can I find more extensive code samples based on ib-insync?
?
Below is an outline of what I'm trying to achieve:
?
A) Update bar every minute
?
B) Separately:
1) request reqMktData
2) on event receiving ask/bid price, perform calculations using these as well as latest data from bars. Based on calculations, decide whether to send order
3) Continue receving ask/bid prices
4) If order sent in 2) above did not fill after 5 minutes, cancel order
?
I'm coding in Spyder/VS Code
|
Jurgen, I will perform this check from now on.
|
Richard, I think you're spot on,? can now remember I have had a power failure when testing over the weekend, this is probably when it messed up. Thank you for the insights, good to know!
|
The latest order ids for each client id are stored, on the client computer, in the xml settings files for TWS and Gateway For example my tws.xml has this: ? ??????????? <MapOfStrings varName="ddeIdMap"> ????????????????? <Entry key="123" val="2"/> ????????????????? <Entry key="906564398" val="268435468"/> ????????????????? <Entry key="4739156" val="268435456"/> ????????????????? <Entry key="69744289" val="268565542"/> ????????????????? <Entry key="49723415" val="268575547"/> ????????????????? <Entry key="11344589" val="268435456"/> ????????????????? <Entry key="938945948" val="268435462"/> ????????????????? <Entry key="537090480" val="268435472"/> ??????????? </MapOfStrings> ? I placed an order using clientId 49723415 a few minutes ago, and you can see that the order id was 268575547. ? So when an API connection is made, the value for the chosen clientId is retrieved from the settings file and incremented, and sent via the nextValidId() callback. ? But the thing is, my recent order id is only visible because the settings file has been saved since the order was placed: I saved it manually using the ¡®File | Layout Settings | Save settings¡¯ menu entry. ? Thus the question is, when is this file actually saved? Certainly it is saved when you do a tidy exit from TWS/Gateway but certainly not immediately after the placeOrder() call. (The settings file is also uploaded to the IB servers at this point, unless otherwise configured) ? So there is a period, and it may be long, after an order is filled, where closing TWS untidily might mean that the settings file doesn¡¯t get saved. And so next time you connect to the API, the nextValidId() will be incorrect. Killing the process rather than using the normal exit method would do it. ? Of course one doesn¡¯t normally close down TWS/Gateway in this undisciplined fashion (I hope!), but I¡¯ve hit this problem a couple of times with the paper-trading TWS due to carelessness, power failures etc. My protection when connecting is to round up the nextValidId() to a number that couldn¡¯t conceivably have been reached in the previous session: I add 10000 to it, because I¡¯m very certain I will never exceed 10000 orders in a single day. ? By the way, the settings file also contains a mass of other stuff, for example layouts, open charts etc, and if the program is shut down untidily any such changes during the session are lost. That¡¯s why IBC can be configured to automatically save the settings on a user-specified schedule. ? Richard ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of bespalex
Sent: Tuesday, November 28, 2023 4:02 PM
To: [email protected]
Subject: [TWS API] Duplicate OrderID? IB doesn't cease to amuse. I am baffled.
Yesterday, the last executed orderId was 161178.
Today,??ibapi.wrapper: ANSWER nextValidId {'orderId': 161044}
No need to say, this caused a major headache today, as orderIds eventually started to coincide with already executed yesterday's ones that are still in my open position.
How is this possible? What can be done to prevent this?
|
Re: Order rejected - reason:Message must contain field # 44
Yes I can see now LMT BUY 100.000000@0?zero price somehow. Thank you!
|
Re: Order rejected - reason:Message must contain field # 44
"" in the error message refers to the FIX protocol TWS/IBGW use when they communicate with IBKR. It's a "price" field, so you need to check your order objects for any missing or malformed price value.
´³¨¹°ù²µ±ð²Ô
On Tue, Nov 28, 2023 at 10:31 AM, bespalex wrote:
Got multiple errors like this lately:
ibapi.wrapper: ANSWER error {'reqId': 161494, 'errorCode': 201, 'errorString': 'Order rejected - reason:Message must contain field # 44', 'advancedOrderRejectJson': ''}
How is it possible to determine which field is #44 that is causing this error?
Corresponding request:
ibapi.client: REQUEST placeOrder {'orderId': 161494, 'contract': 1695173701456: 0,UVXY,STK,,0,,,SMART,,USD,,,False,,,,combo:, 'order': 1697515523088: 161494,0,0: LMT BUY 100.000000@0 }
ibapi.client: SENDING placeOrder b'\x00\x00\x01Z3\x00161494\x000\x00UVXY\x00STK\x00\x000.0\x00\x00\x00SMART\x00\x00USD\x00\x00\x00\x00\x00BUY\x00100.0\x00LMT\x000.0\x00\x00\x00\x00\x00\x000\x00\x001\x000\x000\x000\x000\x000\x000\x000\x00\x000\x00\x00\x00\x00\x00\x00\x00\x000\x00\x00-1\x000\x00\x00\x001\x00\x00\x000\x000\x00\x000\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x000\x00\x00\x000\x000\x00\x00\x000\x00\x000\x000\x000\x000\x00\x001.7976931348623157e+308\x001.7976931348623157e+308\x001.7976931348623157e+308\x001.7976931348623157e+308\x001.7976931348623157e+308\x000\x00\x00\x00\x001.7976931348623157e+308\x00\x00\x00\x00\x000\x000\x000\x00\x002147483647\x002147483647\x000\x00\x00\x00'
?
|
We don't have enough detail about your setup to give you a definitive answer, but my best guess is that your client does not properly manage the next valid orderId. It is not sufficient that you simply start at the "nextValidId" you receive during connection and increment from there. That is necessary but not sufficient.
Take another look at the "", especially the second paragraph where the other (and often overlooked) condition is described as:
When your client connects to TWS/IBKR, TWS API sends you the next valid orderId based upon the client ID you use. If that clientId has previously been used (does not matter how long ago), nextValidId will be one larger than the orderId of the last order that clientId has placed (whenever that was). If the clientId has never been used or no orders have been placed with that clientId, nextValidId will likely be 1.
You can now place orders by keeping an internal nextOrderId that you increment for each order you place. Until you receive an openOrder or orderStatus callback for an order that was placed by a different client or manually in TWS. At that point in time you have to set your internal nextOrderId counter to:
- MAX( internalNextValidOrderId, orderId from openOrder or orderStatus + 1 )
So your next orderId must be higher than the id for any order your client has placed or has been related to.
´³¨¹°ù²µ±ð²Ô
On Tue, Nov 28, 2023 at 10:02 AM, bespalex wrote:
IB doesn't cease to amuse. I am baffled.
Yesterday, the last executed orderId was 161178.
Today,??ibapi.wrapper: ANSWER nextValidId {'orderId': 161044}
No need to say, this caused a major headache today, as orderIds eventually started to coincide with already executed yesterday's ones that are still in my open position.
How is this possible? What can be done to prevent this?
|
Yes, next valid is requested first thing in the morning.
Sorry can you elaborate, why a week?
|
Order rejected - reason:Message must contain field # 44
Got multiple errors like this lately:
ibapi.wrapper: ANSWER error {'reqId': 161494, 'errorCode': 201, 'errorString': 'Order rejected - reason:Message must contain field # 44', 'advancedOrderRejectJson': ''}
How is it possible to determine which field is #44 that is causing this error?
Corresponding request:
ibapi.client: REQUEST placeOrder {'orderId': 161494, 'contract': 1695173701456: 0,UVXY,STK,,0,,,SMART,,USD,,,False,,,,combo:, 'order': 1697515523088: 161494,0,0: LMT BUY 100.000000@0 }
ibapi.client: SENDING placeOrder b'\x00\x00\x01Z3\x00161494\x000\x00UVXY\x00STK\x00\x000.0\x00\x00\x00SMART\x00\x00USD\x00\x00\x00\x00\x00BUY\x00100.0\x00LMT\x000.0\x00\x00\x00\x00\x00\x000\x00\x001\x000\x000\x000\x000\x000\x000\x000\x00\x000\x00\x00\x00\x00\x00\x00\x00\x000\x00\x00-1\x000\x00\x00\x001\x00\x00\x000\x000\x00\x000\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x000\x00\x00\x000\x000\x00\x00\x000\x00\x000\x000\x000\x000\x00\x001.7976931348623157e+308\x001.7976931348623157e+308\x001.7976931348623157e+308\x001.7976931348623157e+308\x001.7976931348623157e+308\x000\x00\x00\x00\x001.7976931348623157e+308\x00\x00\x00\x00\x000\x000\x000\x00\x002147483647\x002147483647\x000\x00\x00\x00'
?
|
First of all this is really weird case. I never seen this type of issue. Are you waiting for next valid order id event before starting with other things? ? But if you really want to Hack it then use Different Client ID every day, so that they can never collide for a week. ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of bespalex Sent: Wednesday, November 29, 2023 12:02 AM To: [email protected]Subject: [TWS API] Duplicate OrderID ? IB doesn't cease to amuse. I am baffled.
Yesterday, the last executed orderId was 161178.
Today,??ibapi.wrapper: ANSWER nextValidId {'orderId': 161044}
No need to say, this caused a major headache today, as orderIds eventually started to coincide with already executed yesterday's ones that are still in my open position.
How is this possible? What can be done to prevent this?
|
IB doesn't cease to amuse. I am baffled.
Yesterday, the last executed orderId was 161178.
Today,??ibapi.wrapper: ANSWER nextValidId {'orderId': 161044}
No need to say, this caused a major headache today, as orderIds eventually started to coincide with already executed yesterday's ones that are still in my open position.
How is this possible? What can be done to prevent this?
|
Re: Delay up to 5 minutes after FX order is filled for balance to be updated in TWS
Thanks for your insights re: the position changes, and I'll look into the delays further.
|
interested in your experience migrating to .NET
I ran unattended for a few years to 2020 and I am interested in doing so again with a different algorithm and substantially different code-base. I used to use Linode, Ubuntu + ubuntu desktop, vnc4server, and Java. As you can see my costs were low. This arrangement was suitable but a little unsatisfactory. To list some disadvantages, I would say that this arrangement seemed risky to me since Linode didn¡¯t offer the GUI desktop for Ubuntu by default and if I recall correctly, IB Gateway and IB TWS didn¡¯t work without them. Defaults are important to me since defaults are better supported and I know I am making a generalization but sometimes generalizations are a guide to risk. The other disadvantage, and I only say this from a personal point of view, is that I like the Visual Studio C# combination better than the Eclipse Java combination. One of the positives is that Linode pricing seemed easier to understand than AWS and Azure.
I am researching a switch to .NET. If the community has any experience with making a change like this, I would appreciate comments from the community on how much your costs increased on a percentage basis. Linode has some general cost guidance but of course a community that uses TWS/Gateway unattended would have more specific knowledge that would help me.
|
Re: Delay up to 5 minutes after FX order is filled for balance to be updated in TWS
In my experience position changes are coming even sooner than execution details. But this is stocks, not sure about FX, but anyway make sure the delay is not on your side, as 5mins sounds like too much.
|
Delay up to 5 minutes after FX order is filled for balance to be updated in TWS
I'm used to TWS reporting the position sizes and position lists in a delayed manner, say 2-3 seconds after reporting that an entry or exit order was filled, but recently it's been more like 5 minutes when trading FX in a paper trading account. Does it normally take up to 5 minutes for TWS to report changes to FX balances?
|
