I have 2 clients connecting to the same ibgateway and both of them subscribe to some market data. The 2nd connected client has error - "Code: 10197, Msg: No market data during competing live session".

Is this normal? I kinda remember api clients of the same ibgateway can share market data before...maybe ib changed policy?

Does anyone happen to know??

I use the Gateway API for placing orders using my python script. In?the gateway settings there are a few options to set specific order conditions, However in the settings of the Regular Desktop TWS, there are far more options to set specific order conditions. My question is, will the order settings in my TWS apply to orders I place using the gateway API? Assuming I'm using the same instrument and the same account??

Thank you for any help
Adam

This took me forever to diagnose, but here is the glitch.? When request PNL message is sent there is no PNL response if you've already asked before.? Let me explain.

This only happens under certain conditions:

• PNL is 0.0, no trades have been made
• TWS only this does not happen with IB gateway

So basically if I start TWS turn on my program it request PNL and receives response just fine.? However, if I turn off my program and restart it, I will never get a PNL response again.? So my code will just freeze waiting for PNL response.? When I restart TWS it resets, so I can request PNL and will receive a response once and not again.

This does not happen with IB gateway, I can request PNL as often as I'd like.? Also this does not happen if my PNL is not zero, so if I've made or lost money it will send my my daily PNL over and over again.

I'm using TWS version 10.15

--

No problem, Ed.

If you follow the call path in the Java API source code you will find that either option (null or "") is fine and yields the same result. The Order class uses Order.EMPTY_STR to initialize manualOrderTime and you could use that, since it is a public constant. It happens to be defined as "".

闯ü谤驳别苍

On Fri, Jul 8, 2022 at 10:40 PM, Edward wrote:

--

闯ü谤驳别苍,

?I'd first like to thank you for the time and effort you put into this site, we are very fortunate to have you.
?
?Secondly, I like to especially thank you for the same time and effort you put into this particular problem I had on this topic.

Your technical knowledge is so immense it sometimes can overwhelm me.? I have 35 years professional IT experience, but I started with Mainframe IBM/Cobol.? Anything else has be self taught.
?
Having said that, I re-booted the computer, bought up TWS (Prod and Test with the same port that gave me trouble) and successfully connected.? I ran "netstat -ano -p tcp " and the port showed up, as it should.? Your " lsof -iTCP -n" and "cat /proc/nettcp" would not run on Win7, though thanks for the info.

?Somewhere in the cobwebs of my aging mind I seem to remember encountering this problem before? ...
.
?I have no reason to doubt your expertise so I will pay close attention to the ports that are in use and see if there is a conflict.
?
?Thanks, as always, and Be Well,
?Lou Dudka

Just guessing here, Edward, but this is probably related to the new field and feels like a regulatory thing for brokers and advisors. So I guess unless you are a broker or advisor, pass the empty string.

闯ü谤驳别苍

From:

Limit Order With Manual Order Time

The Limit Order With Manual Order Time is a with ManualOrderTime property.

Order order = OrderSamples.LimitOrder(action, quantity, limitPrice);

Placing a Limit Order With Manual Order Time
The Manual Order Time field is required for, and becomes editable for, "manual" orders, which are orders that originate from a client (whether by phone, email, chat, verbally from the floor, from another desk, etc.) and are then entered into the system. The Manual Order Time field is not used for client orders received electronically, nor for orders that originate from the account manager (with discretion) in the client's accounts, or when an order is allocated to ALL accounts or among multiple accounts using an account group or model portfolio.

client.placeOrder(nextOrderId++, ContractSamples.USStockAtSmart(), OrderSamples.LimitOrderWithManualOrderTime("BUY", Util.StringToDecimal("100"), 111.11, "20220314 13:00:00"));

Canceling a Limit Order With Manual Order Time
The Manual Order Cancel Time field is required for, and becomes editable for, "manual" order cancelations, which are order cancelations that originate from a client (whether by phone, email, chat, verbally from the floor, from another desk, etc.) and are then entered into the system. The Manual Order Cancel Time field is not used for client orders cancelations received electronically, nor for orders that originate from the account manager (with discretion) in the client's accounts, or when an order is allocated to ALL accounts or among multiple accounts using an account group or model portfolio.

client.cancelOrder(nextOrderId - 1, "20220314 19:00:00");

Any answers to this? I've replaced my 9.x API with the 10.16 and, naturally I had to add this parameter. Having added it as just DateTime.Now led to a problem that the submitted orders are not always cancelled... Should it be the time when the order was submitted?

开云体育

开云体育

It looks like your contract object relates to NQU2 futures but on 20220401, NQM2 is still the front future. I just repeated your query and while NQM2 does have trades in pretty much every second in the 1/2 before market open on 20220401, NQU2 (which you are requesting had only very few trades the entire day and non just before market open. Therefore, volume = 0 and count = 0 values are correct.

As a matter of practice, we never create contract objects ourselves. We rather make a reqContraclDetails query (in this case NQM2:FUTURE:GLOBEX or NQU2:FUTURE:GLOBEX if that is what you really want) and use the returned contract object for calls such as reqHistoricalData. This also has the advantage that you do receive trading hour details for the next few days as well as the native time zone for the instrument. That is "US/Central" in this case.

You will get the most stable results if you specify times in the native timezone of the instrument since you do not have to deal with any complex timezone math. And if you are located outside of the US where your daylight saving times do not line up with those in the US (or in Arizona, where daylight saving is not observed, except in the north eastern part in the Navajo Nation) you can get your head spinning in no time and you will make mistakes. Consequently, we would have specified '20220401 08:30:00 US/Central'.

The long form timezone identifiers are much less error prone and IBKR has switched over to them pretty much everywhere. You can find a complete list in the

闯ü谤驳别苍

Hey,

I am trying to pull out some historical data about NQ Future.?

The time frame is 1 sec for the last 30 min (for example) - The thing is that the volume is always returned as 0.0 which is doesn't make sense.

Example:??

ib.reqHistoricalData(contract, endDateTime='20220401 09:30:00 est', barSizeSetting='1 secs',
                                durationStr='1800 S', whatToShow='TRADES', useRTH=False, formatDate=2)

where contract is:?

contract = Future('NQ', '202209', 'GLOBEX', '', '20', 'USD') 

Does anyone faced with this issue??

Another thing is the timezone which I need to understand how to make it aligned with the trading hours.?

?

Thanks for the help :)?

Happy hunting, Lou. My gut tells me that this is not an issue? with IB or TWS. It is sufficient that some defunct process holds on to port 9707 for TWS to be denied access to that port. Those sockets in that state may not show up in netstat listings of established connections. A couple ways to check this are:

• My favorite command "lsof". Try it as " lsof -iTCP -n" so that it only shows you the processes that use TCP resources.
• Or you could go to the horse's mouth with "cat /proc/nettcp" but make sure you convert to numbers from hex to decimal or look for port "25EB"

闯ü谤驳别苍

闯ü谤驳别苍 and joanmarcel119,

Again, thanks for your input.

Firstly, I don't use IB's ports simply because we may (and do) run multiple TWS's on the same machine.

I bought up another TWS on the same machine and tried to assign port 9707.? TWS refused it and said it was in use, which it wasn't.

I ran? netstat -ano -p tcp and port 9707 did not show up.

I think it's an IB problem, not a "network" problem.? It appears IB doesn't think it "let go" of the port.

I'll guarantee you when I re-boot the machine this weekend and assign 9707 to the "offending" TWS it will work.

This is not a big deal (now) to me since I'm up and running.? I consider myself a trader first and a technician second, but it does intrigue me.

I'll keep you posted.

Thanks, as always, Be Well,
Lou Dudka

But that sounds more like a network issue than a TWS issue, Lou.

• As joanmarcel119? said firewall or antivirus related that prevents access to port 9707
• Or even more subtle, a port clash with another service on your machine. If that clash happens on the TWS/IBGW machine, you should get an error message or at least a log entry.

What does your infrastructure between your client and TWS/IBGW look like?

And finally, any specific reason that you do not use the IBKR standard port assignments?

• TWS_Paper_Account 7497
• TWS_Live_Account 7496
• IBG_Paper_Acctount 4002
• IBG_Live_Account 4001

闯ü谤驳别苍

Hi All,

Fixed (cannot say "solved").

Out of desperation I changed the Prod Port from 9707 to 9777 and it connected.

I then changed the Port back to 9707 and received errors.

Put it back to 9777 and will proceed as if nothing happened .... I have backups of TWS from last week and if I really wanted to I could start the TWS with them.? Ah, it's just not worth the trouble ...

Thanks to all, as always, Be Well,
Lou Dudka

joanmarcel119,

Thanks for your input.

It might be that except both Test and Prod are on the same computer using exactly the same code.

Thanks, as always, and Be Well,
Lou Dudka

闯ü谤驳别苍,

Thanks, as always, for your complete and speedy response!

I'm (almost) ready to try replacing 981 with 10.12, simply because I've run out of ideas.

BTW both Prod and Test are running on the same machine, so all libraries, etc are the same.? I've even taken an XLS that's successfully connected to Test and changed the port to Prod and it hangs up. ? Any yes, as you pointed out, I double checked that the Ports are correct.? If I flip between the two (Prod and Test) API setup screens in TWS, they're exactly the same, with exception of the Port, as it should be.

The one thing I might try is bringing up another Prod TWS on the same machine and see if I can connect.? If I can, it would seem to point to the TWS connection itself.

I don't know what Richard's "Contract Inspector" is, but if the above fails, I'll spend some time researching it.

Thanks, as always, Be Well,udka
Lou Dudka