Hi, thank you for your replies, but I am still confused on what to do next with my code after reading all the posts. I dont understand what to do.

How do I send a new placeOrder() to amend an existing order using permID?

Oups !
Looks like Jurgen Reinold did answered you while I was writing also an answer.
Sorry Jurgen

If nobody gives you exact answer, my suggestion is to learn and try.
Most likely everyone has methods of their own for placing /managing orders? and may not be exactly as you asked for it.
So your relatively on your own to master that.
And it is not a waist of time to try and experiments.

The API is pretty powerful. The price you pay is that you should do your own gradual experiments.

?

Suggestion for learning it:

#1 Become familiar with OrderID

Read carefully this one (twice)

Read it also with other language like Java or C++ aside of Python (your language). because this may help you getting a better understanding of how crude examples are :

In C++? exemple:

m_pClient->placeOrder(m_orderId++, ContractSamples::USStock(), OrderSamples::LimitOrder("SELL", stringToDecimal("1"), 50));

I read IB intent for training , using the “++” in m_orderId++ as a way to say “be sure to never reuse same ID for next order, so here we force a new one, that can be as simple as +1 of previous”

?

also C++: m_pClient->cancelOrder(m_orderId-1, "");

Same thing with “-1” to be understood as meaning: ?“here we cancel last order, could be any other, but please be sure to use a freshly brewed orderId for next 辫濒补肠别翱谤诲别谤(…).”

Java: IB exemple use a “cancelID” which I don’t know about but seems to me more an implementation method, I don't see what else it could be aside of the Orderid you use for the 辫濒补肠别翱谤诲别谤(…).

?

#2 Become familiar with the Order object
This object is a major one and is returned once you 辫濒补肠别翱谤诲别谤(…)? when call back fires up.
This bring to you the order.permId and order.orderRef

?

• Client 0
• Master Client - configured in the API section of TWS/IBGW global configuration.
  NOTE: Master Client can be set to "0" to make the client with id 0 a "super client" that has the "powers" of both the "Master Client" and "Client 0"
• The API configuration "Use negative numbers to bind automatic orders" and the tooltip

Clients can request the ability to control existing or future open orders that were placed by the same clientId, all other clientIds, or even via the TWS GIU. This is done by "binding" those orders (that you you currently see with an orderId of 0) to an orderId the client can use.

We find it most convenient to enable the "Use negative numbers ..." option since that nicely separates ids for orders placed by the client from "bind" orders that the client did not create but may wish to control.

Order binding works even after TWS or your client restarts. You will receive openOrder callbacks with (negative) orderIds other than 0 after your client makes one or more of the open orders requests mentioned above.

闯ü谤驳别苍

Where I am now confused is how to modify an existing order using permID and not orderID.

I have been modifying orders within a running instance of TWS using an Order() object, eg to change a stoploss:

stopLoss = Order()
stopLoss.orderId = 99
stopLoss.action = "SELL"
stopLoss.orderType = "STP"
stopLoss.auxPrice = 100.01
stopLoss.tif = "GTC"
stopLoss.totalQuantity = 1
stopLoss.parentId = 98                  # Parent ID
stopLoss.transmit = True
stopLoss.eTradeOnly = ""
stopLoss.firmQuoteOnly = ""
self.placeOrder(99, IBContract, stoploss)

Where does permID get put in here?

And once TWS is closed, all of this information becomes redundant (eg- "parentId" because this is the stop loss in an OCA Buy order) - so how do I modify an order now? (I use python).

Thanks.

You are correct that there are a few responses that return no reqId and I agree with your assessment that those really don't need to be called several times in parallel.

But the corresponding requests do not require reqId either. Here the request call signatures for the response example you gave:

Yes very useful indeed
Just a grain of salt about request ID: Some request (just a few) does use a request ID but do not send it in the call back.
like ? that deliver back mktDepthExchanges(const std::vector<DepthMktDataDescription> &depthMktDataDescriptions)? without reqID.

In never saw this as an issue because these kinds of requests are far less critical, they are either:
- part of what should be called only once on init. (and are serviced back very quickly)
- are far less critical, the only one I take some care about is reqAccountUpdates (if you use it, this is not so critical as it's serviced rather quickly)
- does return OrderId (or Order.orderId) which is enough to collate results (but still do not deliver the reqId that trigger the call);

I don't see any reason to handle that from that place.

From an individual account generally you find access to data package in the web page once you login
account->Settings->MarketData subscriptions->"Configure" (gear icon)

Thank you Dave, very useful reply.

On Thu, Dec 22, 2022 at 07:52 PM, dent wrote:

This whole issue was caused by my laziness and sheer luck.

Lol, you're so lazy apparently that it's not enough someone tell you so... but you actually need to have each and every detail of just how lazy you're being spelt out.

Glad you got the answer you were looking for :-) Happy holidays.

开云体育

OUTSTANDING thank you so much 闯ü谤驳别苍.

The error callbacks you have encountered over time is something that will save me a lot of time.? The data started flowing again this morning of it's own volition BUT it DID motivate me to go back and harden my approach. Before I was just HOPING that all would go well :-) sheer laziness on my part. One of the excellent things about julia is the modularity that is built into it. I have NO excuses.

Thank you for the guidance as to contract object construction, I like that approach and will adopt it. I completely forgot that IB returns so much in that exchange, VERY useful in the times ahead in 2023.

I get auto updates on the TWS api because I use a laptop with TWS desktop running. I do this to keep an eye on the markets and make sure I track the DATA flow. I also have a raspberry pi tracking the isp just in case of problems.? This takes care of the packing issues as I am on 10.20.

I've had my own version of a data monitor running using arrays which populate dataframes. 2023 will allow me to create a realtime Pluto notebook which gives me control over the data representation using tufte concepts.

This whole issue was caused by my laziness and sheer luck. I've already got logging working ( took 10 minutes) and your error list has stimulated me to create an error handling function so I can standardize all levels of problem.

Thanks again for 2022 and you have done an EXCELLENT job on the forum. Happy holidays to you and all your clan.

dent

The approach you describe sounds reasonable and seems to have worked for you for a while. But there are a few details that come to mind that make the process more robust and tolerant of changes by IBKR. Not sure whether any of these fix your problem, but I am sure they will prevent issues in the future.

We have a data monitor that subscribes to all available reqMktData ticks for about 80 instruments plus 15 TickByTick streams (TickByTickLast, TickByTickBidAsk, and TickByTickMid each for five instruments) plus three Level II market book streams and is rock stable.

During startup, we use to retrieve a contract object for each instrument instead of making our own contract objects. This way you get the most up-to-date instrument details and a contract object that has all fields initialized. You also get the trading hours for the next few days including short-notice changes caused by holidays or issues at the exchange. And any contract related errors (such as de-listed instruments, exchange changes, expired futures contracts, ...) are flagged well before you subscribe to market data.

The loop that runs the reqMktData subscription calls needs to make sure that it does not cause API pacing violations (more than 50 requests per second). Pacing violations will cause disconnects by TWS/IBGW.

• Manage appropriate delays between back-to-back reqMktData calls
• Set the "+PACEAPI" connection option so that TWS/IBGW handle pacing for you

TWS/IBGW V10 have "+PACEAPI" enabled by default so this is less of an issue, but make sure the API global configuration "Reject messages above maximum allowed message rate" in TWS/IBGW is not selected.

• 309??? Max number (3) of market depth requests has been reached
• 321??? Error validating request.-'bX' : cause - Incorrect generic tick list ...
• 354??? Requested market data is not subscribed.Delayed market data is available.
• 2117??? Requested top market data is not subscribed.
• 10090??? Part of requested market data is not subscribed. Subscription-independent ticks are still active.
• 10168??? Requested market data is not subscribed. Delayed market data is not enabled
• 10189??? Failed to request tick-by-tick data:No market data permissions for ...
• 10190??? Max number of tick-by-tick requests has been reached
• 10197??? No market data during competing live session
• 10225??? Bust event occurred, current subscription is deactivated. Please resubscribe real-time bars immediately.

There is a lot that can change without notice or go wrong.

Hope this helps,

闯ü谤驳别苍

On Thu, Dec 22, 2022 at 03:23 PM, dent wrote:

I'm not expecting anything

Either am I, guess that was my point. I would post my C++ solution which works very well for my purposes but that would be inappropriate. Not to mention, at the very core, it's basically just like the example provided by the SDK.

c'est la vie

开云体育

I'm not expecting anything as I can't see any other way to handle it. It's just a basic awaitio loop with tagging. Been around since the late 80's nothing particularly innovative about it. I'm just making sure I didn't miss anything. From the python perspective Ewald did an AMAZING job with insync right from day one by handling the asynchio aspect for us. Good man as is Richard King and Jurgen. Happy xmas to all