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

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

По логу такое впечатление что после регистрации стакана идет перезагрузка всех трейдов полностью.

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

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

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

trader.SupportManualOrders = true; включено.

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

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

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

Версия 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.4
9=180
35=G
34=112
49=quik
52=20141109-11:08:51.870
56=StockSharpTS
1=10097
11=61532110
37=703072745
38=0
40=2
41=61532105
44=76.72
55=SBER
60=20141109-17:08:51.862
167=CS
207=TQBR
461=E
10=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.4
9=180
35=G
34=113
49=quik
52=20141109-11:08:51.871
56=StockSharpTS
1=10097
11=61532111
37=703072746
38=0
40=2
41=61532107
44=76.72
55=SBER
60=20141109-17:08:51.863
167=CS
207=TQBR
461=E
10=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.4
9=198
35=9
34=256
49=quik
52=20141109-11:08:51.872
56=StockSharpTS
37=703072745
39=8
41=61532110
58= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".
60=00010101-00:00:00.000
102=99
434=1
10=053
2014/11/09 17:08:51.456|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.4
9=236
35=8
34=257
49=quik
52=20141109-11:08:51.872
56=StockSharpTS
1=
11=0
14=0
37=0
38=0
39=8
40=2
41=61532110
44=0
54=1
55=
58= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".
59=1
60=00010101-00:00:00.000
150=8
151=0
207=
10=024
2014/11/09 17:08:51.457|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.4
9=198
35=9
34=258
49=quik
52=20141109-11:08:51.872
56=StockSharpTS
37=703072746
39=8
41=61532111
58= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".
60=00010101-00:00:00.000
102=99
434=1
10=057
2014/11/09 17:08:51.457|Debug |#=qaBez6xggl2OPiHwxjqwmKg==|Sending to 127.0.0.1:10924: 8=FIX.4.4
9=236
35=8
34=259
49=quik
52=20141109-11:08:51.872
56=StockSharpTS
1=
11=0
14=0
37=0
38=0
39=8
40=2
41=61532111
44=0
54=1
55=
58= ukazannaya tranzaktsiya po ukazannomu klassu ne naidena: "tqbr".
59=1
60=00010101-00:00:00.000
150=8
151=0
207=
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

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

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

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

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

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 ... ,без дублирования. Или это такая задумка? Черт с ним, с дублированием, зачем выдавать свечи с каким-то промежуточным значением объема. Конечно, это все можно обойти, но разве это логично. Могу Скинуть код.

Нет никакого дублирования, свечка меняется и вы получаете каждое изменение. Здесь.