Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Twsapi
- Messages
Search
|
Re: next valid id on initial connection
It depends on your definition of good. The solution uses sleep for synchronization, so I would not call it a good solution. It does not address the mismatch between synchronous and asynchronous processing and only addresses one of the many API callback scenarios. On the other hand, it will probably work reliably since the loop blocks your client until the nextValidId callback has taken place (as long as the sleep does not interfere with proper API background message processing). 闯ü谤驳别苍 |
|
Re: next valid id on initial connection
thank you for the fast reply.
honesty I got lost in i I'm a?junior so my?knowledge is?quite?limited for now, so I'm not sure how to wait for a callback in python. but i did find an example online?related to this?matter is that a good solution? ? ? def nextValidId(self, orderId: int):
? ? ? ? super().nextValidId(orderId)
? ? ? ? self._next_order_id = orderId
def main():
? ? testApp = IBApi()
? ? #connect on separet thred
? ? testApp.connect("127.0.0.1", 7496,1)
? ? t = threading.Thread(target=testApp.run, daemon=True)
? ? t.start()
? ? #if connection is done continue
? ? while True:
? ? ? ? if isinstance(testApp._next_order_id, int):
? ? ? ? ? ? print("connected")
? ? ? ? ? ? break
? ? ? ? else:
? ? ? ? ? ? print("waiting for connection")
? ? ? ? ? ? time.sleep(1)
thank you so much, Cohav |
|
Re: historical market data pacing violations are back?!
My software downloads once per day historical data for about 200 stock tickers. It does so sequentially: one at a time. I have not noticed any change in time it takes for all data to get downloaded: it takes about 6 minutes and 30 seconds to complete this task. So, if there is any pacing in place at IB's side, I'm not getting close to that limit.
|
|
Re: Converging Trailing Stop via API
Nick
If you are going to be monitoring the position yourself you just have to change the price on the stop order - you don't have to cancel and submit a new one.
toggle quoted message
Show quoted text
Just send another PlaceOrder with everything the same as the original stop order except the new price. This will adjust the stop price. You might look into IB's algo order types, they might have something that would work and then it would be handled on IB's end. On 3/4/2022 12:05 AM, David Walker wrote:
Does anyone have experience in the mechanics of maintaining a converging trailing stop via the API? |
|
Converging Trailing Stop via API
Does anyone have experience in the mechanics of maintaining a converging trailing stop via the API??
I mean a stop where the trailing amount is wide at the start (to give a trade space to take hold) but then progressively reduces the trailing amount once the position becomes profitable, in order to protect the profit.? So, for example, a 25% trailing stop allows the trade to established, but then is reduced to, say, 20%, 15% and a minimum (say) 10% once the trade reaches certain profitability levels.? I think some people call it a tangential trailing stop. Theoretically, I would guess the mechanics via the API would be something like this (but looking for comment/correction!):
However, I'm not 100% sure of these mechanics and have these questions in my head:
I would love any comments from anyone with experience, or even just views, on this. |
|
Re: historical market data pacing violations are back?!
Nick
Isn't it just adding a function HistPacing() before each request?
toggle quoted message
Show quoted text
Inside HistPacing you can use a fixed delay to test things out, then move to keeping a list of the last 60 requests when you're back alive with the simple version. It's like 5 lines of code altogether. On 3/3/2022 7:31 PM, skee__bum via groups.io wrote:
or if I need to completely rewrite my code how it was previously. |
|
Re: historical market data pacing violations are back?!
> Did your violations ever go away?
I have not been pulling continuously today.? I completely restructured my code years ago when they implemented the throttling on their end.? With their changes today, my new code is totally fubar'd. So I'm left waiting to hear if this is a change they are reversing tomorrow...or if I need to completely rewrite my code how it was previously.? Thank you so much IB!!!! |
|
historical market data pacing violations are back?!
skee__bum, I'm OK but I'll try to keep an eye on it.? My logs show occasional data fetches that a taking a bit long, maybe one every 10 mins or so.? I'll try to check back in an hour or so.
Did your violations ever go away? Thanks, as always, and Be Well, Lou Dudka |
|
Re: historical market data pacing violations are back?!
Glad it's working again, Lou. We don't use historical data requests that often (pretty much never) and our code implements self-pacing. So we have not experienced any changes. Just checked our real-time data processor and no issues there. It received 210 million ticks since Sunday afternoon and shows no unusual behavior or errors. 闯ü谤驳别苍 |
|
Re: historical market data pacing violations are back?!
After getting passed around amongst various IB desks, they said they weren't aware of any changes, but they were seeing the errors on their end.? I provided them with log files and they are going to look into it.
So it doesn't SEEM like it was intentional...but how this gets re-introduced accidentally, I have no idea. IB is sometimes (frequently?) so bad at basic things.... |
|
historical market data pacing violations are back?!
Years ago, IB expected API users to pace their requests for HMD.? They then moved to a model whereby they paced their responses, and the API users didn't need to pace their calls.
But they seem to be back to requiring us to pace our requests.? Ugggghhhh.... Is everyone else seeing the same? |
to navigate to use esc to dismiss