开云体育

The error message tells me, that TWS/IBGW was (most likely) reading the conditionsIgnoreRth order field from the message it received from your client for (what I assume was) a placeOrder request. The value present in the message was the string "o" while TWS/IBGW did expect a binary bye 1 or 0.

The "o" is probably legit and is the conjunctionConnection for one (your only?) OrderCondition. OrderCondition conjunctions are encoded as "o" for OR? and "a" for AND.

There are several other fields between conjunctionConnection? and conditionsIgnoreRth, in the message so it is not immediately clear why your client and TWS/IBGW were able to get so far out of sync. Is there any chance you had the TWS/IBGW API log enabled and could post a copy of the offending placeOrder message? Alternatively, could you run the placeOrder request again with TWS/IBGW API log enabled?

I can think of several reasons why your issue can happen, but a copy of the message would likely provide clarity. One reason could be a case, where your client and TWS/IBGW had a mismatch of API versions. Which TWS/IBGW version are you using and what the MaxVersionf is for the TWS API library your client is using?? You should be able to simply print MaxVersionf since it is a public field in the IBApi.Constants class..

Also interesting would be the value of serverVersion from class EClient after your client connected to TWS/IBGW. that contains the negotiated API version both sides should be using (well, technically more correct the TWS/IBGW dictated version).

闯ü谤驳别苍