Keyboard Shortcuts
Likes
- Twsapi
- Messages
Search
Locked
No documentation for new manualCancelOrderTime in cancelOrder?
Joel Gross
I saw this has been added, but did not see documentation for it (in client.py):
def cancelOrder(self, orderId:OrderId, manualCancelOrderTime:str):
? ? ? ? """Call this function to cancel an order.
? ? ? ? orderId:OrderId - The order ID that was specified previously in the call
? ? ? ? ? ? to placeOrder()"""
? ? ? ? self.logRequest(current_fn_name(), vars())
? ? ? ? if not self.isConnected():
? ? ? ? ? ? self.wrapper.error(NO_VALID_ID, NOT_CONNECTED.code(), NOT_CONNECTED.msg())
? ? ? ? ? ? return
? ? ? ? if self.serverVersion() < MIN_SERVER_VER_MANUAL_ORDER_TIME and manualCancelOrderTime:
? ? ? ? ? ? self.wrapper.error(orderId, UPDATE_TWS.code(), UPDATE_TWS.msg() + " ?It does not support manual order cancel time attribute")
? ? ? ? ? ? return
? ? ? ? VERSION = 1
? ? ? ? flds = []
? ? ? ? flds += [make_field(OUT.CANCEL_ORDER)]
? ? ? ? flds += [make_field(VERSION)]
? ? ? ? flds += [make_field(orderId)]
? ? ? ? if self.serverVersion() >= MIN_SERVER_VER_MANUAL_ORDER_TIME:
? ? ? ? ? ? flds += [make_field(manualCancelOrderTime)]
? ? ? ? msg = "".join(flds)
? ? ? ? self.sendMsg(msg)
|
Re: TypeError: TestApp.error() takes 4 positional arguments but 5 were given
Well, if your code was written against a version 9 API, you might want to stay with the stable API? 9.81 track for now. You can still run your code against all (even the latest and beta) TWS and IBGW versions. It's a good practice to lock the API version in and to avoid automatic and uncontrolled version changes. But by its nature, the stable track is a couple years old and is lacking the latest features version 10 provides. So you might want to start the development, unit, system, and regression testing cycles so that you can eventually move to the version 10 API. 闯ü谤驳别苍 On Thu, Aug 11, 2022 at 08:44 PM, Joel Gross wrote:Wow, thanks guys! Tons of major changes it looks like.? |
Re: TypeError: TestApp.error() takes 4 positional arguments but 5 were given
Nope. The advancedOrderRejectJson field was introduced in API version 10.14.01 in January 2022 and went through beta and is, obviously, in the current "latest" version 10.17.01. Version 10 has many and large changes compared with the current stable version 9.81 and is still rapidly getting new features. 闯ü谤驳别苍 On Thu, Aug 11, 2022 at 06:20 PM, @sbank wrote:
|
Re: TypeError: TestApp.error() takes 4 positional arguments but 5 were given
On Thu, Aug 11, 2022 at 06:28 PM, Joel Gross wrote:
My guess is you are using a new api version where error takes an extra param (advancedOrderRejectJson) Either change back to an older api version or change the app.error method in your code to accept an extra string. |
Re: TypeError: TestApp.error() takes 4 positional arguments but 5 were given
I came across this the other day.? I believe that IB has been making major changes to the API (in minor patch releases). Look for your definition of error().? It now takes 5 arguments and not 4. So something like this: ??? def error(self, ????????????? reqId: TickerId, ????????????? errorCode: int, ????????????? errorString: str):? Needs to be changed to: ??? def error(self, ????????????? reqId: TickerId, ????????????? errorCode: int, ????????????? errorString: str, ????????????? advancedOrderRejectJson=""): Take a look at the API Docs.? They have some boilerplate code around using that new advancedOrderRejectionJson parameter. -s On Thu, Aug 11, 2022, at 6:27 PM, Joel Gross wrote:
|
TypeError: TestApp.error() takes 4 positional arguments but 5 were given
Joel Gross
I have been running TWS API with Python for years without many issues. Suddenly my code that worked yesterday is no longer working. Any file I run, I get an error like this:
Traceback (most recent call last):
? File "c:\Users\joel\joelvscode\ib\ibapp\ibapi\value_stock_picker\11_get_tws_fundamental_data.py", line 296, in <module>
? ? main()
? File "c:\Users\joel\joelvscode\ib\ibapp\ibapi\value_stock_picker\11_get_tws_fundamental_data.py", line 287, in main
? ? app.run()
? File "c:\users\joel\joelvscode\ib\ibapp\ibapi\launchLoop.py", line 409, in run
? ? self.decoder.interpret(fields)
? File "c:\Users\joel\joelvscode\.venv\lib\site-packages\ibapi\decoder.py", line 1377, in interpret
? ? self.interpretWithSignature(fields, handleInfo)
? File "c:\Users\joel\joelvscode\.venv\lib\site-packages\ibapi\decoder.py", line 1358, in interpretWithSignature
? ? method(*args)
? File "c:\users\joel\joelvscode\ib\ibapp\ibapi\launchLoop.py", line 515, in nextValidId
? ? self.start()
? File "c:\Users\joel\joelvscode\ib\ibapp\ibapi\value_stock_picker\11_get_tws_fundamental_data.py", line 137, in start
? ? self.runWithoutSchedule()
? File "c:\users\joel\joelvscode\ib\ibapp\ibapi\launchLoop.py", line 466, in runWithoutSchedule
? ? self.decoder.interpret(fields)
? File "c:\Users\joel\joelvscode\.venv\lib\site-packages\ibapi\decoder.py", line 1379, in interpret
? ? handleInfo.processMeth(self, iter(fields))
? File "c:\Users\joel\joelvscode\.venv\lib\site-packages\ibapi\decoder.py", line 1273, in processErrorMsg
? ? self.wrapper.error(reqId, errorCode, errorString, advancedOrderRejectJson)
TypeError: TestApp.error() takes 4 positional arguments but 5 were given I am running Windows 10, TWS Latest, API Latest. About the time this error started, I had to switch from Visual Studio Code to Visual Studio Code Insiders. Python files run regularly under VS Code Insiders just fine. What could cause this to happen?? |
Re: Tick-by-tick data is coming in bursts
Please keep in mind that time stamps in TickByTick callbacks have a resolution of 1 second. Therefore, liquid instruments can have many trades per second, each trade would be reported as a separate callback, and all trades that took place within the same second will have the same time stamp. The same is true, and for many instruments more visible, for BidAsk updates. The instruments we subscribe to often have 10 BidAsk updates for each trade. Your log is from pre-market trading but I am sure AAPL is good for seven trades in one second an hour before market open. Hope that helps, 闯ü谤驳别苍 PS. If you tag each callback with your own local higher resolution arrival time stamp you will see that callbacks with identical time stamps do not happen in one block. What I mean is you will see that they take place over approximately one second but not equally spaced nor all together. There is also a separate thread about millisecond resolution of TickByTick data. |
Tick-by-tick data is coming in bursts
3ryancarty@gmail.com
Hi everyone,
I've recently started messing around with the Java API, specifically the?'reqTickByTickData'?method. But I noticed some unexpected behavior and would like to know why this is and if there's something I can do to resolve it. In my program I request tick by tick data twice. Once with tickType of?'Last'?and once with a tickType of?'BidAsk'. On their respective callback methods being called I log the time parameter of the callback. The below lines are the logs, where 'LAST' indicates a log from the 'Last' callback method and 'BIDASK' indicates a log from the 'BidAsk' callback method. You will notice that some of the data comes in clumps for example, the 4th line to the 10th line all indicate the exact same time. I find this likely to be inaccurate as this was ran premarket when I wouldn't expect a lot of activity occurring at the exact same time. I'm of the thinking that for whatever reason I'm getting slightly delayed data, that is pushed together with other data generated roughly around the same time. Has anyone else ran into this. would upgrading subscription help I wonder? Thanks for any input you can offer. BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220588| BidPrice: 170.04| AskPrice: 170.08| AskSize: 300| TickAttributeBidAsk:? BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220588| BidPrice: 170.04| AskPrice: 170.09| AskSize: 300| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220588| BidPrice: 170.07| AskPrice: 170.09| AskSize: 2600| TickAttributeBidAsk:?
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 161| TickAttributeLast: | Exchange: ARCA| SpecialConditions: T
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 100| TickAttributeLast: | Exchange: ARCA| SpecialConditions: T
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 100| TickAttributeLast: | Exchange: ARCA| SpecialConditions: T
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 100| TickAttributeLast: | Exchange: ARCA| SpecialConditions: T
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 100| TickAttributeLast: | Exchange: ARCA| SpecialConditions: T
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 4000| TickAttributeLast: | Exchange: FINRA| SpecialConditions: T
LAST: RequestId: 1| Ticker: AAPL| tickType: 1| Time: 1660220606| Price: 170.09| Size: 139| TickAttributeLast: | Exchange: FINRA| SpecialConditions: T
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220606| BidPrice: 170.07| AskPrice: 170.1| AskSize: 100| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220606| BidPrice: 170.08| AskPrice: 170.1| AskSize: 100| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220606| BidPrice: 170.08| AskPrice: 170.09| AskSize: 100| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220606| BidPrice: 170.07| AskPrice: 170.09| AskSize: 200| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220608| BidPrice: 170.07| AskPrice: 170.1| AskSize: 300| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220608| BidPrice: 170.07| AskPrice: 170.09| AskSize: 300| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220608| BidPrice: 170.05| AskPrice: 170.09| AskSize: 100| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220608| BidPrice: 170.07| AskPrice: 170.09| AskSize: 100| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220608| BidPrice: 170.06| AskPrice: 170.09| AskSize: 100| TickAttributeBidAsk:?
BIDASK: RequestId: 2| Ticker: AAPL| Time: 1660220608| BidPrice: 170.05| AskPrice: 170.09| AskSize: 100| TickAttributeBidAsk:?
|
Re: Timestamp is missing milliseconds in tickByTickAllLast
It does take a bit of time for the server to take a snapshot of the time to the closest millisecond, compose the message, send it down the pipe to your computer. By the time is does all of this, time has passed by.
On Wednesday, August 10, 2022 at 07:37:25 p.m. PDT, Millie Joyner <mdavis00@...> wrote:
I'm comparing the ms timestamp that IB sends in RT_TRD_VOLUME (presumably exchange time) to the time my computer receives that message from the API.? IB's timestamp is always earlier than my computer's time but the difference varies systematically from approx 50ms to 1000ms, which makes me very suspicious of the accuracy of that timestamp. Here's an example of some typical timing observations from this evening Local=21:53:14.690? RT_TRD_VOLUME=21:53:14.569? Delay=0.121 sec
Local=21:53:37.439? RT_TRD_VOLUME=21:53:37.310? Delay=0.130 sec
Local=21:53:55.157? RT_TRD_VOLUME=21:53:54.935? Delay=0.223 sec
Local=21:54:32.918? RT_TRD_VOLUME=21:54:32.598? Delay=0.321 sec
Local=21:55:12.783? RT_TRD_VOLUME=21:55:12.355? Delay=0.429 sec
Local=21:55:44.538? RT_TRD_VOLUME=21:55:44.003? Delay=0.536 sec
Local=21:56:33.214? RT_TRD_VOLUME=21:56:32.559? Delay=0.655 sec
Local=21:56:33.222? RT_TRD_VOLUME=21:56:32.559? Delay=0.663 sec
Local=21:57:17.301? RT_TRD_VOLUME=21:57:16.536? Delay=0.765 sec
Local=21:57:53.561? RT_TRD_VOLUME=21:57:52.696? Delay=0.865 sec
Local=21:58:52.949? RT_TRD_VOLUME=21:58:51.983? Delay=0.966 sec
Local=21:59:10.079? RT_TRD_VOLUME=21:59:09.106? Delay=0.973 sec?
Local=21:59:44.829? RT_TRD_VOLUME=21:59:44.753? Delay=0.076 sec? <-- resets back to 76ms
Local=21:59:51.043? RT_TRD_VOLUME=21:59:50.963? Delay=0.080 sec
Local=21:59:59.960? RT_TRD_VOLUME=21:59:59.779? Delay=0.181 sec
Local=22:00:04.979? RT_TRD_VOLUME=22:00:04.789? Delay=0.190 sec
Local=22:00:21.766? RT_TRD_VOLUME=22:00:21.517? Delay=0.249 sec |
Re: Timestamp is missing milliseconds in tickByTickAllLast
I'm comparing the ms timestamp that IB sends in RT_TRD_VOLUME (presumably exchange time) to the time my computer receives that message from the API.? IB's timestamp is always earlier than my computer's time but the difference varies systematically from approx 50ms to 1000ms, which makes me very suspicious of the accuracy of that timestamp.
Here's an example of some typical timing observations from this evening Local=21:53:14.690? RT_TRD_VOLUME=21:53:14.569? Delay=0.121 sec
Local=21:53:37.439? RT_TRD_VOLUME=21:53:37.310? Delay=0.130 sec
Local=21:53:55.157? RT_TRD_VOLUME=21:53:54.935? Delay=0.223 sec
Local=21:54:32.918? RT_TRD_VOLUME=21:54:32.598? Delay=0.321 sec
Local=21:55:12.783? RT_TRD_VOLUME=21:55:12.355? Delay=0.429 sec
Local=21:55:44.538? RT_TRD_VOLUME=21:55:44.003? Delay=0.536 sec
Local=21:56:33.214? RT_TRD_VOLUME=21:56:32.559? Delay=0.655 sec
Local=21:56:33.222? RT_TRD_VOLUME=21:56:32.559? Delay=0.663 sec
Local=21:57:17.301? RT_TRD_VOLUME=21:57:16.536? Delay=0.765 sec
Local=21:57:53.561? RT_TRD_VOLUME=21:57:52.696? Delay=0.865 sec
Local=21:58:52.949? RT_TRD_VOLUME=21:58:51.983? Delay=0.966 sec
Local=21:59:10.079? RT_TRD_VOLUME=21:59:09.106? Delay=0.973 sec?
Local=21:59:44.829? RT_TRD_VOLUME=21:59:44.753? Delay=0.076 sec? <-- resets back to 76ms
Local=21:59:51.043? RT_TRD_VOLUME=21:59:50.963? Delay=0.080 sec
Local=21:59:59.960? RT_TRD_VOLUME=21:59:59.779? Delay=0.181 sec
Local=22:00:04.979? RT_TRD_VOLUME=22:00:04.789? Delay=0.190 sec
Local=22:00:21.766? RT_TRD_VOLUME=22:00:21.517? Delay=0.249 sec |
Re: How to check connection to TWS?
开云体育The specific issue in your code below is that nextValidID() is a function called by EWrapper with the next valid orderId as a parameter – it is not a variable that holds the orderId, and it is not a function that your code should ever need to directly call.? You trigger the nextValidId() function (and therefore can retrieve the orderId it contains as a parameter) by using the reqIds() function.? It’s in the documentation here: ? On the bigger question of checking connections there are several issues to consider, covered in various questions in the archive. ?Some quick (incomplete) thoughts are:
? ? Dave ? ? ? ? From: twsapi@groups.io <twsapi@groups.io> On Behalf Of GreenGreen via groups.io
Sent: Wednesday, 10 August 2022 12:51 AM To: twsapi@groups.io Subject: [TWS API] How to check connection to TWS? ? Since TWS restarts daily, I assume we need to reconnect our API clients or at least check for connection. Here is my code to check for connection (Python): from ibapi.client import EClient from ibapi.wrapper import EWrapper import threading ? class TestApp(EWrapper, EClient): ? ? def __init__(self): ? ? ? ? EClient.__init__(self, self) ? ? ? ?? ? ? ? def error(self, reqId, errorCode, errorString): ? ? ? ? print("Error: ", reqId, " ", errorCode, " ", errorString) ? app = TestApp() app.connect("127.0.0.1", 4002, 0) api_thread = threading.Thread(target=app.run) api_thread.start() -------------------------------------------------------------------------- AttributeError? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call last) Input In [2], in <cell line: 1>() ----> 1 app.nextValidID ? AttributeError: 'TestApp' object has no attribute 'nextValidID' --------------------------------------------------------------------------- AttributeError? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call last) Input In [3], in <cell line: 1>() ----> 1 app.nextorderId ? AttributeError: 'TestApp' object has no attribute 'nextorderId'
|
Re: Invalid value in field # 541
TWS talks with IBKR with the Financial Information Exchange protocol (FIX). Field #541 in that protocol is defined as "MaturityDate" and needs to have the format "yyyymmdd". Any chance you are placing an order for a Future, Option, or Warrant? In that case, make sure the in the Contact object is formed correctly. 闯ü谤驳别苍
|
Re: How do I run my code on while closing TWS application?
Hello, Tws is the most common interface to IB, and most people will use it or the gateway (no UI version) for connecting. You'll need something running to connect to IB from. As for jupyter I expect you'll want to run that code every now and then and you'll probably find that easier in a script rather than a work book.? IBC is a method for controlling the tws instances and helping navigate past the bits that usually require human intervention. Lastly, you may want to think about running a dockerised container solution if your objective is to not be running on your own machine, this would make it much easier to use someone else's hardware like aws. Best of luck with it, M On Tue, 9 Aug 2022, 18:45 , <taikilazos@...> wrote: Hello. I am new to this field and I wrote my code in jupyter notebook (for better readability for myself). The code is working but I want to run my code while I am sleeping/closing my computer. I see that IBController by Richard L King is recommended by Dmitry but I wonder whether there are other methods to run my code 24/7 without starting my computer or TWS app. |
Re: Software version upgrade, recommendations?
While we use the direct links for automated downloads of TWS and IBGW installers, we check this site for the current official version numbers for the "stable", "latest", and "beta" tracks: The "stable" version recently changed from the 981 to the 10.12 series and is, at this very moment, 10.12.2q, as you experienced. I am not aware of an official link for prior versions of TWS/IBGW. Significant changes took place between the 981 and 10.12 versions in support of crypto currency trading, for UI feature updates in TWS (JxBrowser with Google Chromium integration), and others. We have problems with certain market data items in TWS 10.12 in our (remote Linux) environment and I was a little surprised that 10.12 became the "stable track". We had filed tickets for those issues a while back but they still exist in 10.12.2q. But is looks like they are gone in 10.16.1n, which was the "latest" version just a couple weeks ago. 闯ü谤驳别苍 |