Новый коннектор к Quik

Продукты Стоимость Блог Разработка Чат
Новый коннектор к Quik
Atom
09.07.2014
Mikhail Sukhov


Мы сделали новый коннектор к Quik. Доступен начиная с версии 4.2.4.0

Коннектор обраладет следующими преимуществами:

1. Быстрее скорость транспортировки данных.
2. Значительно упрощена настройка таблиц в Quik (все колонки по умолчанию, нужно просто открыть таблицы в терминале, без дополнительных каких-либо настроек).
3. Возможность подключаться удаленно к Quik.
4. Робот может быть скомпилирован под 64 бита.

Подробнее, о настроках и миграции.

Коннектор сделан с использование протокола FIX 4.4. Поэтому появилась новая возможность - подключение к Quik не из StockSharp программ. Если у вас есть код или готовая программа, использующая FIX, то вы можете попробовать подключиться к Quik терминалу через FIX протокол.

Давайте попробуем данный тип подключения, и отпишемся здесь о своих замечаниях. А к осени воздадим почет DDE+Trans2Quik как самой старой технологии, и первому коннектору в S#. И отправим на заслуженный покой.

Теги:


Спасибо: Николай_Флёров


<< < 10 11 12 13 14  > >>
longtrades

Фотография
Дата: 19.10.2014
Ответить


У меня вот такая проблема с коннектором Луа, подключаюсь к квику , регистрирую стакан фьюча, все ок, начинаю регистрировать стаканы опционов ( около 20 инструментов), квик зависает на глухо.
квик 6.15.1.17 , стокшарп 4.2.31

По логу такое впечатление что после регистрации стакана идет перезагрузка всех трейдов полностью.
Lua.log.txt 44 KB (303)
Спасибо:
RomSunZ

Фотография
Дата: 20.10.2014
Ответить


В 4.2.30 Security.LastTrade.Time = Security.LastChangeTime, хотя первое должно считаться по последней сделке, а второе по последней сделке или последнему изменению стакана, сейчас оба значения меняются по изменению стакана
Спасибо:
longtrades

Фотография
Дата: 03.11.2014
Ответить


Скажите, пожалуйста, нормальной ли является такай ситуация :

Открыл два квика , с темже аккаунтом для торговли, к одному подключился по ДДЕ и совершаю там сделки , к другому подключился по Луа , в другом вижу сделки что совершаю в первом через ДДе , но вот робот который подключен через Луа этих сделок не видит ? почему ? что нужно изменить в коде что-бы видел ?

trader.SupportManualOrders = true; включено.
Спасибо:
longtrades

Фотография
Дата: 03.11.2014
Ответить


Оказывается через Луа я вообще не видел никаких сделок из квика , после откытия таблицы всех сделок сделки в программе подключенной через луа пошли .
Закрываю таблицу всех сделок , в Луа сделки перестают идти :(

Вопрос : неужели чтобы коннектор луа видел сделки нужно открывать таблицу всех сделок ?

Своих сделок я так и не увидел..
Спасибо:
RomSunZ

Фотография
Дата: 09.11.2014
Ответить


Версия 4.2.35 ошибка при котировании:
Цитата:

17:08:51.865|Error |S_SBER@TQBR_10097|Заявка 61532105 (0x2D61DCD) не была отменена по причине System.InvalidOperationException: Ошибка снятия заявки 703072745. Текст ' ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".'..
17:08:51.865|Debug |S_SBER@TQBR_10097|Правило 'Ошибка снятия заявки 61532105/703072745 (0x3EE6409)'. Активация.
17:08:51.865|Error |PS_SBER@TQBR_10097|Заявка 61532110 (0x152F52F) не была зарегистрирована по причине ' ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".'.
17:08:51.865|Error |S_SBER@TQBR_10097|Заявка 61532110 (0x152F52F) не была зарегистрирована по причине ' ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".'.
17:08:51.865|Debug |S_SBER@TQBR_10097|Правило 'Ошибка регистрации заявки 61532110/ (0x3231231)'. Активация.
17:08:51.865|Error |S_SBER@TQBR_10097|Заявка 61532110 (0x152F52F) не была зарегистрирована по причине ' ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".'.
17:08:51.865| |S_SBER@TQBR_10097|Текущее кол-во ошибок 1. Максимальное 100.


LUA:

Цитата:

2014/11/09 17:08:51.452|Debug |Quik |Out. Execution,T(L)=2014.11.09 17:08:51.452,(Tick),Sec=S#:VTBR@TQBR, Native:,Type:,Ord=0/0/0,Fail=,TId=419465230,Pf=,TPrice=0.041,UId=,OPrice=0,Volume=645
2014/11/09 17:08:51.452|Debug |None |OnAllTrade done
2014/11/09 17:08:51.455|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|From client 8=FIX.4.49=18035=G34=11249=quik52=20141109-11:08:51.87056=StockSharpTS1=1009711=6153211037=70307274538=040=241=6153210544=76.7255=SBER60=20141109-17:08:51.862167=CS207=TQBR461=E10=225
2014/11/09 17:08:51.456| |#=qaBez6xggl2OPiHwxjqwmKg==|From client quik: OrderCancelReplaceRequest
2014/11/09 17:08:51.456|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|From client 8=FIX.4.49=18035=G34=11349=quik52=20141109-11:08:51.87156=StockSharpTS1=1009711=6153211137=70307274638=040=241=6153210744=76.7255=SBER60=20141109-17:08:51.863167=CS207=TQBR461=E10=232
2014/11/09 17:08:51.456| |#=qaBez6xggl2OPiHwxjqwmKg==|From client quik: OrderCancelReplaceRequest
2014/11/09 17:08:51.456|Debug |Quik |In. OrderReplace,T(L)=2014.11.09 17:08:51.456,Sec=S#:SBER@TQBR, Native:,Type:Stock,TransId=635511382840369034,Price=76.72,Side=Buy,OrdType=Limit,Vol=0,Sec=S#:SBER@TQBR, Native:,Type:Stock,OldTransId=635511382840369031,OldOrdId=703072745,NewTransId=635511382840369034
2014/11/09 17:08:51.456|Debug |Quik |In. OrderReplace,T(L)=2014.11.09 17:08:51.456,Sec=S#:SBER@TQBR, Native:,Type:Stock,TransId=635511382840369035,Price=76.72,Side=Buy,OrdType=Limit,Vol=0,Sec=S#:SBER@TQBR, Native:,Type:Stock,OldTransId=635511382840369033,OldOrdId=703072746,NewTransId=635511382840369035
2014/11/09 17:08:51.456| |None |SendTransaction: t = {}
t["ACTION"] = "MOVE_ORDERS"
t["CLASSCODE"] = "TQBR"
t["SECCODE"] = "SBER"
t["MODE"] = "0"
t["FIRST_ORDER_NUMBER"] = "703072745"
t["FIRST_ORDER_NEW_PRICE"] = "76.72"
t["FIRST_ORDER_NEW_QUANTITY"] = "0"
t["TRANS_ID"] = "61532110"
return sendTransaction(t)

2014/11/09 17:08:51.456| |None |Result: Указанная транзакция по указанному классу не найдена: "TQBR".
2014/11/09 17:08:51.456|Debug |Quik |Out. Execution,T(L)=2014.11.09 17:08:51.456,(Order),Sec=S#:@, Native:,Type:,Ord=0/0/635511382840369034,Fail=System.Exception: Указанная транзакция по указанному классу не найдена: "TQBR".,TId=0,Pf=,TPrice=0,UId=61532110,Price=0,Volume=0
2014/11/09 17:08:51.456| |None |SendTransaction: t = {}
t["ACTION"] = "MOVE_ORDERS"
t["CLASSCODE"] = "TQBR"
t["SECCODE"] = "SBER"
t["MODE"] = "0"
t["FIRST_ORDER_NUMBER"] = "703072746"
t["FIRST_ORDER_NEW_PRICE"] = "76.72"
t["FIRST_ORDER_NEW_QUANTITY"] = "0"
t["TRANS_ID"] = "61532111"
return sendTransaction(t)

2014/11/09 17:08:51.456| |None |Result: Указанная транзакция по указанному классу не найдена: "TQBR".
2014/11/09 17:08:51.456|Debug |Quik |Out. Execution,T(L)=2014.11.09 17:08:51.456,(Order),Sec=S#:@, Native:,Type:,Ord=0/0/635511382840369035,Fail=System.Exception: Указанная транзакция по указанному классу не найдена: "TQBR".,TId=0,Pf=,TPrice=0,UId=61532111,Price=0,Volume=0
2014/11/09 17:08:51.456|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.49=19835=934=25649=quik52=20141109-11:08:51.87256=StockSharpTS37=70307274539=841=6153211058= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".60=00010101-00:00:00.000102=99434=110=053
2014/11/09 17:08:51.456|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.49=23635=834=25749=quik52=20141109-11:08:51.87256=StockSharpTS1=11=014=037=038=039=840=241=6153211044=054=155=58= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".59=160=00010101-00:00:00.000150=8151=0207=10=024
2014/11/09 17:08:51.457|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.49=19835=934=25849=quik52=20141109-11:08:51.87256=StockSharpTS37=70307274639=841=6153211158= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".60=00010101-00:00:00.000102=99434=110=057
2014/11/09 17:08:51.457|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.49=23635=834=25949=quik52=20141109-11:08:51.87256=StockSharpTS1=11=014=037=038=039=840=241=6153211144=054=155=58= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".59=160=00010101-00:00:00.000150=8151=0207=10=027
2014/11/09 17:08:52.422|Debug |None |OnParam
2014/11/09 17:08:52.423|Debug |Quik |Out. Level1Change,T(L)=2014.11.09 17:08:52.423,T(S)=0001.01.01 00:00:00.000,Sec=S#:GAZP@TQBR, Native:,Type:,Changes=[PriceStep, 0.01],[BestBidPrice, 152.16],[BestAskPrice, 152.26],[ClosePrice, 150],[LastTradePrice, 152.25]
2014/11/09 17:08:52.423|Debug |None |OnParam done
Спасибо:
sazon

Фотография
Дата: 10.11.2014
Ответить


Здравствуйте. Решил воспользоваться новым коннектором для скачивания свечных данных и столкнулся с проблемой. Во-первых, происходит дублирование свечей в сериях, которые приходят в "CandleManager.Processing". Во-вторых, свечи на один и тот же временной отрезок в каждой серии отличаются как минимум объемом, и с каждой новой серией эта величина увеличивается, и ,в конце концов, после нескольких повторений объем принимает свое окончательное верное значение. Мне кажется это поведение некорректным. Можно ведь сразу все свечи, которые уже прошли, выдавать в конечном виде и не повторять их каждый раз.
ql_candle.txt 6 MB (304)
Спасибо:
esper

Фотография
Дата: 10.11.2014
Ответить


RomSunZ
Версия 4.2.35 ошибка при котировании:

Как временное решение можно сделать ExchangeBoard.MicexTqbr.IsSupportAtomicReRegister = false
Спасибо:
esper

Фотография
Дата: 10.11.2014
Ответить


sazon
Здравствуйте. Решил воспользоваться новым коннектором для скачивания свечных данных и столкнулся с проблемой. Во-первых, происходит дублирование свечей в сериях, которые приходят в "CandleManager.Processing". Во-вторых, свечи на один и тот же временной отрезок в каждой серии отличаются как минимум объемом, и с каждой новой серией эта величина увеличивается, и ,в конце концов, после нескольких повторений объем принимает свое окончательное верное значение. Мне кажется это поведение некорректным. Можно ведь сразу все свечи, которые уже прошли, выдавать в конечном виде и не повторять их каждый раз.


Что-то ничего не понял, ни по описанию, ни по логам.
Спасибо:
sazon

Фотография
Дата: 10.11.2014
Ответить


esper
sazon
Здравствуйте. Решил воспользоваться новым коннектором для скачивания свечных данных и столкнулся с проблемой. Во-первых, происходит дублирование свечей в сериях, которые приходят в "CandleManager.Processing". Во-вторых, свечи на один и тот же временной отрезок в каждой серии отличаются как минимум объемом, и с каждой новой серией эта величина увеличивается, и ,в конце концов, после нескольких повторений объем принимает свое окончательное верное значение. Мне кажется это поведение некорректным. Можно ведь сразу все свечи, которые уже прошли, выдавать в конечном виде и не повторять их каждый раз.


Что-то ничего не понял, ни по описанию, ни по логам.

Вот, что я получаю в обработчике свечного менеджера:

11/10/2014 10:00:00;101000;101000;101000;101000;0
11/10/2014 10:00:00;101000;101000;101000;101000;2
11/10/2014 10:00:00;101000;101000;101000;101000;4
11/10/2014 10:00:00;101000;101000;101000;101000;5
11/10/2014 10:00:00;101000;101000;101000;101000;6
11/10/2014 10:00:00;101000;101000;101000;101000;10
11/10/2014 10:00:00;101000;101000;101000;101000;11
11/10/2014 10:00:00;101000;101000;101000;101000;12
11/10/2014 10:00:00;101000;101000;101000;101000;13
11/10/2014 10:00:00;101000;101000;101000;101000;14
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101000;101000;101000;0
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101000;101000;101000;1
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101000;101000;101000;2
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101000;101000;101000;3
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101010;101000;101010;4
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101010;101000;101010;5
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101010;101000;101010;7
11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;101020;101000;101020;8

Как мы видим, у нас происходит постоянное наращивание объема свечи , например, с временем "11/10/2014 10:00:00". В какой-то момент, после очередного срабатывание обработчика я получаю значение окончательное "11/10/2014 10:00:00;101000;101000;101000;101000;15".

( ...
11/10/2014 10:00:00;101000;101000;101000;101000;11
11/10/2014 10:00:00;101000;101000;101000;101000;12
11/10/2014 10:00:00;101000;101000;101000;101000;13
11/10/2014 10:00:00;101000;101000;101000;101000;14
11/10/2014 10:00:00;101000;101000;101000;101000;15
...
)

Затем начинается аналогичный процесс для следующей свечи с временем 11/10/2014 10:00:01...Почему сразу нельзя выдать всю серию так:

11/10/2014 10:00:00;101000;101000;101000;101000;15
11/10/2014 10:01:00;101000;102000;100800;102000;1343
11/10/2014 10:02:00;101770;102020;101760;101910;567
...
,без дублирования. Или это такая задумка? Черт с ним, с дублированием, зачем выдавать свечи с каким-то промежуточным значением объема. Конечно, это все можно обойти, но разве это логично. Могу Скинуть код.
Спасибо:
esper

Фотография
Дата: 10.11.2014
Ответить


Нет никакого дублирования, свечка меняется и вы получаете каждое изменение. Здесь.
Спасибо: sazon
<< < 10 11 12 13 14  > >>

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
Сообщение оформляется с помощью bb кодов
clippy

Copyright @ StockSharp Platform LLC 2010 - 2024
О компании Контакты Условия и положения Способы оплаты Политика конфиденциальности Партнерство