开云体育

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.

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.

Yes, I am also experiencing the same issue since yesterday.?

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!):

• Place initial entry order and (say) 25% trailing stop order as a parent/child order
  • specify OCA group/type on the trail stop order.
• After entry, at each new profitability level:
  • Place a new trailing stop order with a new trailing % amount and with same OCA group/type as original trail stop order.
  • Cancel the original (and any other previous) trailing stop orders.

However, I'm not 100% sure of these mechanics and have these questions in my head:

• Can I just keep adding trailing stops (without cancelling previous ones) provided they are all part of the same OCA group, and save the cancelling step above?
• Are there any robustness concerns with regularly cancelling and replacing orders, or having multiple trailing stops sitting in an OCA group?? I don't want any trail stops to inadvertently enter a short position, obviously.
• Or is there a better way that I haven't considered?

I would love any comments from anyone with experience, or even just views, on this.

The most relevant parameter to look at is SMA. If that goes negative you have used too much margin and IB will start to liquidate positions near the end of the US trading day.
Some information is provided here:?

I appreciate you providing a proposed solution, but no...my situation is far from that simple.

Isn't it just adding a function HistPacing() before each request?

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.

> 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!!!!

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

Lou, I am absolutely still seeing the request pacing violations.? Glad for you if they've disappeared for you, but just be on the lookup, because there still seems to be an issue.

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.

闯ü谤驳别苍

@skee__Bum
Thanks for getting a hold of IB - I just don't have the patience anymore, especially with their short staffing, covid, etc.

Whatever tree you shook it seems to be working now (fingers crossed).

Thanks, as always, and Be Well,
Lou Dudka

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....

@skee-bum
YIKES!!!!? Mine started today about 14:35 New York Time.
Anyone else?
Richard/Jurgen - did you guys hear anything about this?

Thanks, as always, and Be Well,
Lou Dudka

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?

The TWS API is asynchronous by design and there is no guarantee as to the time it takes for a response to arrive after the corresponding request has been made. Under no circumstance should you ever use sleep to synchronize requests and responses. And while you are correct that many sample programs (even some from IBKR) frequently use sleep, it is completely wrong and dangerous to do so.

If you do need to block your main thread until a callback for a request comes in (in your case nextOrderId), use one of the "wait/notify" mechanisms your programming language provides.

For an example how you can do this in Python take a look at the i where Ewald de Wit provides both asynchronous as well as and synchronous (blocking) versions for each request. In your case, client.connect() blocks the caller (wait not sleep) until all callbacks related to the client connection request have taken place.

We use Java and our request methods return that give the caller the option to treat the request as asynchronous (caller keeps on working on other tasks while the request is being processed) or synchronous (blocks the caller until the response arrives) or a combination of both.

闯ü谤驳别苍

this is my first topic in this gruop so ill start with something simple.

on the docs of ibapi it says "IBApi.EWrapper.nextValidID?callback is commonly used to indicate that the connection is completed and other messages can be sent from the API client to TWS"
but on the?examples that i saw online after the connection they just use sleep for 1 second.

even though its working I prefer to use the?nextValidID to make?sure the connction is?established but i didnt find any?example on how to?implement it
so instead of :

I'm pretty new to margin trading, and am still trying to wrap my head around how to exactly interpret accountSummary().?



Here's an example. On my paper trading account, I put in about $200K cash, then bought around $330K worth of stock. Here's what I get via accountSummary():

Can someone give me a "dummies guide" on the following questions:

1. Exactly what conditions shown in accountSummary would cause IB to start dumping my stock to meet margin requirements? My best guess is that if?EquityWithLoanValue?goes below MaintMarginReq, that is when the dumping will begin. So basically, I just want to keep an eye on?EquityWithLoanValue?and make sure it stays well above?MaintMarginReq. Is this correct?
2.?AvailableFunds?is the amount of money I can "borrow" right now to purchase more stock, correct?

And you should have no problem figuring that out with the complete example rajeshh_98 provided and after rereading the TWS API Reference on and

闯ü谤驳别苍

ahh this is helpful but I need to use the tws api.?