TWS Link and REQ_BAR_DATA Problem

[joe_k]

Hello,

I would like to get bar data from TWS into Matlab7 using TWS Link and its functions REQ_BAR_DATA and GET_BAR_DATA. All instaled under Vista system.

Everything works ok until I try to request bar data with: calllib
('twslink', 'REQ_BAR_DATA',uid,1,10,4,1); Available return values,
described on the TWS Link web page are
1 = Number of requested Bars.
-1 = Contract Not found (if #1 > 0).
-2 = Value read only.
I get always 0. If it is not possible to request bar data, it will
not be possible to get data later with GET_BAR_DATA.

Could somebody approve my observations? (other platforms as well). Does have somebody same problem or probably already solution?

Thanks giuseppe

 

[syswizard]

Quote from joe_k:

Hello,
Everything works ok until I try to request bar data with: calllib
('twslink', 'REQ_BAR_DATA',uid,1,10,4,1); Available return values,
described on the TWS Link web page are
1 = Number of requested Bars.
-1 = Contract Not found (if #1 > 0).
-2 = Value read only.
I get always 0. If it is not possible to request bar data, it will
not be possible to get data later with GET_BAR_DATA.
Could somebody approve my observations? (other platforms as well). Does have somebody same problem or probably already solution?

Try using zero for the 4th parameter ("Trades").
You should expect to receive a return value of 2 from this since you specified 10 seconds as the duration.
If the above does not work, try putting in 5 seconds.
Also note: there were bugs in the API release 9.40 regarding this particular function....and TWSLink was most likely generated using that release. I believe it was fixed in the 9.41 release of the API. If that is the case, then you'll have to wait for a new updated release of TWSlink.

 

[joe_k]

Try using zero for the 4th parameter ("Trades").
You should expect to receive a return value of 2 from this since you specified 10 seconds as the duration.
If the above does not work, try putting in 5 seconds.
Also note: there were bugs in the API release 9.40 regarding this particular function....and TWSLink was most likely generated using that release. I believe it was fixed in the 9.41 release of the API. If that is the case, then you'll have to wait for a new updated release of TWSlink.

Hello

I tryed your suggestions: 5 seconds bars, API 9.41. It doesn't worked. Than I contact the Support of TWSLink. They found some bugs and fixed them. I had to install new 1.1.0.0 Beta Version.

It was not able to get bar data using GET_BAR_DATA function but it worked with construction of WAIT_FOR_EVENT and GET_EVENT_VALUE (you will find an example in Samples Folder after installation).

The next problem I have is that sometimes (4 of 10 runs) bar data (1 min) are not updated at the end of actual minute, but within the bar(30,90,150,...)

Could somebody approve this manner? or even some solution?

 

[syswizard]

Quote from joe_k:

Hello

I tryed your suggestions: 5 seconds bars, API 9.41. It doesn't worked. Than I contact the Support of TWSLink. They found some bugs and fixed them. I had to install new 1.1.0.0 Beta Version.

It was not able to get bar data using GET_BAR_DATA function but it worked with construction of WAIT_FOR_EVENT and GET_EVENT_VALUE (you will find an example in Samples Folder after installation).

The next problem I have is that sometimes (4 of 10 runs) bar data (1 min) are not updated at the end of actual minute, but within the bar(30,90,150,...)

Could somebody approve this manner? or even some solution?

Joe - you are a bit confused...re: 9.41 of the API is NOT embedded in TWSLINK according to the documentation. IOW, you can install API 9.41 on your machine and it would not matter.
There is a timestamp provided in the callback. You'll have to use that time instead of the actual time. It will require a modulus calculation to convert to hh:mm:ss based on your time zone. Also, be sure your machine's actual time is synchronized properly with a good NTP time server. I was shocked recently to discover many of the servers are off by 30-60 seconds. I found clock.nyc.he.net to be reliable.