Optimus1 Optimus1 написал: Спасибо! Подскажите пожалуйста еще, я правильно понимаю, что, если я при отключенном подключении захочу получить данные:
ds:Size(), а потом и значение самой произвольной свечи:
ds:C(i-1)
То Quik ничего не выдаст, так как эти запросы обращены к серверу, а значит сам терминал Quik должен быть подключен к серверу и в оффлайне это не работает ?
все зависит от той истории, которая скачана с сервера в терминал на требуемом таймфрейме.
возможно, часть истории уже терминал когда-то получил и вы получите историю, которая не будет актуальной. А можете ничего не получить, если по этому инструменту и этому таймфрейме терминал ничего не получал.
в момент когда вы присоединитесь к серверу, история котировок по заказанному таймфрейму начнет закачиваться и через какое-то неопределенное время она станет доступной полностью.
поэтлму в оффлайне вы получите , что что когда-то было сохранено в базе и что покажет ds;c(-1) - неведомо. Вернее ведомо, но это точно не будет предпоследняя свеча торгов
Когда смотришь графики скажем с таймфремом месяц, то зачастую ось У при Авто режиме проваливается в отрицательные значения. По логике это невозможно, т.к. цена на акцию не может быть отрицательной. Почему бы тогда не ввести поправку, чтобы ось У не убегала ниже нуля? Это улучшило бы читаемость графиков за счет того, что он был бы более растянут по Оси У. А так снизу графика сантиметра 2-3 занимают значения меньше 0, которые в принципе не могут быть на графике.
Убирать режим Авто и фиксировать вручную 0 как минимальную границу по оси У не вариант, т.к. в этом случае теряется автоподбор масштаба.
отртцательные значения на графике невозможны для цен акций, но вполне возможны для других инструментов
Ваше обращение получено, проблема изучается. Постараемся в ближайшее время дать ответ.
Егор, мне ждать ответ или лучше сразу начинать подставлять костыли? Предыдущее моё сообщение об ошибке терминала вы "изучаете" уже месяц.
(так и вижу: сгрудились всей аркой у терминала, морщат лбы, нервно курят, спорят, даже домой не идут. Это же арка - спать, есть не будем, но ошибку найдём!)
Анна написал: Добрый день. Есть робот, который на открытии сессии должен выставлять стопы и далее торговать, если есть количество открытых позиций меньше какого-то числа. Сведения по открытым позициям получаю через обращение к таблице лимитов. Периодически проскакивает проблема, что на открытии дня или перезапуске квика таблица лимитов возвращает пусто, соответственно стопы не ставятся, а новая позиция набирается сверх лимита. Есть ли варианты, как можно обезопаситься от этого? И проблема эта на стороне брокера (финам) или все-таки квика? Думала логировать позицию в конце дня, но непонятно в какой момент переключаться со считывания позиции из файла на считывание из квика.
Анна.
Таково природное свойство таблицы лимитов. Она обновляется время от времени в произвольные моменты времени. С этим нужно смириться и изменить логику робота.
Нужно еще добавить что абрау-дюрсо (TQBR/ABRD) не должен попадать в результаты запроса - он явным образом не пройдет проверку по seccode в фильтрующей функции database.search_function запроса SearchItems
Кусочек текста скрипта,занимающегося обработкой таблицы обезличенных сделок:
Код
-- Собирает из ТОС новые обезличенные сделки
rescan =
function()
if not database.need_tos_rescan then
return
end
local num_trades = getNumberOf("all_trades") - 1
local items = SearchItems("all_trades",
database.tos + 1,
num_trades,
database.search_function,
"class_code,sec_code,datetime.day,datetime.month,datetime.year"
) or {}
database.tos = num_trades
for _,n in ipairs(items) do
database.process_trade(getItem("all_trades",n))
end
database.save()
end,
---------------------------------------------------------------
-- Обработка одной сделки
process_trade =
function(trade)
log.write(trade)
local trade_datetime = datetime(trade.datetime)
что мы тут имеем?
rescan() получает новые сделки из ТОС и для каждой вызывает обработчик process_trade первое действие в process_trade есть вывод в лог самой сделки следующее действие - превращение времени сделки в некий объект.
Время от времени (закономерность неясна) последнее действие приводит к развалу скрипта по причине недопустимых данных в datetime сделки.
Все строчки абсолютно нормальные, а последняя выведенная очень интересна. Все поля нулевые, в том числе и datetime. Соответственно, обработка datetime приводит к краху:
Код
E:\quik\LuaIndicators\BS.lua:1085: Assert failed: /GoogleDisk/ROBOT/_LUA/datetime.lua : 106
Невозможно рассчитать Unix time: {week_day=1,hour=0,ms=0,mcs=0,year=1601,month=1,day=1,sec=0,min=0,isdst=false}
stack traceback:
E:\quik\LuaIndicators\BS.lua:1085: in function <E:\quik\LuaIndicators\BS.lua:1074>
(tail call): ?
E:\quik\LuaIndicators\BS.lua:1446: in function 'floor'
E:\quik\LuaIndicators\BS.lua:2563: in function 'process_trade'
E:\quik\LuaIndicators\BS.lua:2545: in function 'rescan'
E:\quik\LuaIndicators\BS.lua:2828: in function 'iterate'
E:\quik\LuaIndicators\BS.lua:1839: in function <E:\quik\LuaIndicators\BS.lua:1802>
Ситуация регулярно появляется как на моем компьютере, так и на множестве других компьютеров, что установлен этот скрипт.
Zoya Skvorcova написал: Михаил ,добрый день. В параметрах экрана для Изменения размера текста, приложений и других элементов должно быть установлено 100%
о как. Приложение уже рассказывает операционке как надо жить.
валерий написал: s_mike@rambler.ru , Я как-то так и думал. И как понимаю выхода нет? Или можно управлять порядком? По алфавиту? А что скажете про скорость? Не в курсе getCandlesByIndex вообще так работает или только в индикаторах?
Готовых способов нет.
Вам нужно или каждый раз экспериментировать с порядком наложения индикаторов или в своем индикаторе писать более сложную логику, пересчитывая индикатор на следующих тиках. Второй вариант не работает в отсутствии торгов и на неликвидных инструментах. Также там появляются навороты, если адресуемый индикатор имеет пропущенные свечи или меняет свои значения задним числом и так далее.
Ищите другой путь решения своей задачи, если не готовы продираться через эти джунгли.
Egor Zaytsev написал: Ошибка, описанная в данном инциденте, будет исправлена в одной из очередных версий программы.
Приносим извинения за причиненные неудобства.
и как же вы, Егор, планируете ее исправить?
Размножить вызов ondestroy - это полбеды. А что вы собираетесь делать с тем, фактом, что при размножении индикатора в новой диаграмме отсутствуют идентификаторы графиков и любая работа с метками из индикатора луа в размноженном окне невозможна?
Заранее извиняюсь за тупой вопрос. Подскажите пожалуйста, как можно реализовать, чтобы индикатор пересчитывался не после каждой заявки, а на каждой новой свечке?
очень просто.
хранить в переменной количество свечей графика и при каждом вызове oncalculate сравнивать актуальное количество свечей с запомненным в переменной.
Виталий написал: Уже скоро 2017 год закончится, а функции с графиками так и не реализованы. Самые нужные это, конечно, произведение графиков. Например, чтобы получить рублевые цены на нерублевые инструменты. Также полезно деление графиков, чтобы получить соотношение, например, привилегированных акций к обычным.
Есть скрипт, который должен крутиться постоянно и собирать данные из таблицы обезличенных сделок.
Чтобы каждый раз не открывать таблицу обезличенных сделок, через CreateDataSource подписываюсь на тиковый интервал котировок. Как понимаю, этго достаточно в любом случае, чтобы обезличенные сделки поехали с сервера в терминал и стали доступны для чтения в скрипте. Или недостаточно?
Каждое утро далее при подключении к серверу (приходу oncleanup) скрипт по необходимым ему инструментам делает подписку
Код
local _class,_code = string.match(instrument,"^(%w+)#(%w+)$")
local ds,err = CreateDataSource(_class,_code,INTERVAL_TICK)
if not ds then -- Нет такого инструмента
log.write("Инструмент ",instrument," не найден: ",err)
return
end
ds:SetEmptyCallback()
table.insert(database.ds,ds)
log.write("Подписка на инструмент ",instrument," успешна")
Вроде бы все чистенько - если есть какие-то проблемы (недоступен инструмент или что-то в этом роде) - мы получим ошибку. Если ошибок нет, значит подписка успешна и ждем обезличенные сделки.
Конечно на самом деле все не так )) Вот фрагмент лога quik 7 11 1 5, демо арка
и далее ни одной сделки не получено, хотя все подписки успешны. Озадачивает и нервирует. Торги идут, график бегает. Открываю руками таблицу обезличенных сделок - и чудо:
Вот и проверил. quk 7 11 1 5, демо от арка. Тест был такой:
Код
function write_log(text)
local connect = ""
if isConnected() == 1 then
connect = "Connected"
end
local f = io.open("D:\\test.log","a")
f:write(os.date() .. " " .. connect .. " " .. text .. "\n")
f:close()
end
function main()
write_log("Start " .. getInfoParam("TRADEDATE") .. " " .. getInfoParam("SERVERTIME"))
while true do
write_log(getInfoParam("TRADEDATE") .. " " .. getInfoParam("SERVERTIME"))
sleep(60000)
end
end
function OnCleanUp()
write_log("OnCleanUp " .. getInfoParam("TRADEDATE") .. " " .. getInfoParam("SERVERTIME"))
end
function OnConnected(flag)
write_log("OnConnected flag=" .. tostring(flag) .. " " .. getInfoParam("TRADEDATE") .. " " .. getInfoParam("SERVERTIME"))
end
function OnDisconnected()
write_log("OnDisonnected " .. getInfoParam("TRADEDATE") .. " " .. getInfoParam("SERVERTIME"))
end
s_mike@rambler.ru написал: Я правильно понимаю, что сначала срабатывает колбек oncleanup и только потом торговая дата кладется в то место, откуда ее вынимает getInfoParam?
да
не подтверждается.
10/02/17 03:16:26 Connected OnCleanUp 01.10.2017
Торговая дата доступна функции getInfoParam только после завершения колбека, но в непосредственно в нем самом
2. Поведение параметра tradedate отличается от параметра servertime ServerTime недоступен в отсутствии связи с брокером а также внутри колбеков OnCleanUp и OnConnected. Про иные колбеки сказать ничего о не могу. Возможно, недоступность servertime из колбеков не есть всеобщее правило и обусловлено оно стечением обстоятельств в данном случае.
3. Предположение Nikolay Pavlov о том, что oncleanUp должен сопровождаться onconnected(true) не опровергается
Толпа колбеков OnDisconnected на уже отсоединенном от сервера терминале. Откуда и что они означают - сказать трудно. При этом в 02-48-44 связь как ни в чем не бывало уже имеется и никаких onconnected и близко нет. Туманно, загадочно и волки воют.
Николай. Вопрос в том, будет ли приходить onconnected, если соединение с брокером не прерывалось с момента 23-50 до 10-00.
будет ли приходить onconnected в этом случае? Я не уверен. Нужно экспериментировать и проверять (вот нечем мне в жизни заниматься кроме как ставить опыты и конспектировать поведение этого чучела)
а вообще это просто феерия: получение торговой даты (базовая функция!) вызывает у нас какие-то неимоверные усилия. Вы пишете простыни на пол экрана с кучей условий. И все это ради элементарнейшей цели.
а тот факт, что разработчики а принципе не в состоянии сказать ничего внятного, вообще удручает.
Николай Камынин написал: Михаил,а чем не устраивает дата торгов из ТТП
Николай, это еще более условная штука, чем tradedate. ТТП может быть у пользователя вовсе не открыта или этот параметр в ней не будет присутствовать. Какие в нем инструменты есть - непонятно. Да и колбек не получишь - придется долбиться в нее на каждом проходе как ошпаренному
При этом мы ничего не выигрываем: заполнение полей ТТП произойдет уж точно никак не раньше чем параметра tradedate.
скрипт должен работать и без подключения к серверу.
Тогда нужно реализовывать две ветки, собственно работа скрипта оффлайт (дата торгов не поменяется точно) и работа скрипта после коннекта к серверу (только тут уже смотреть не на OnCleanUp, а на OnConnected), а там уже в зависимости от того поменялась дата торгов или нет свои алгоритмы...
а вы уверены, что торговая дата всегда меняется при с разрывом связи? Я не уверен. А точно это никто не знает)
Пятница повторяю, чтобы не терялась основная цель, которую я преследую. Иначе все время мы уходим в сторону.
вот и сейчас вы пишете про выставление каких-то ночных заявок. Зачем мне это? Мне все равно что там будет во времени.
к меня есть терминал и в нем есть таблица обезличенных сделок.
сделки в этой таблице могут быть датированы одним днём или двумя. Больше двух дней торговых сессий я не знаю)
мне нужно отфильтровать те сделки, которые идут последним днём. После этого собрать все эти сделки, обработать и записать в файл.
последний день я определяю через tradedate.
идея просто посмотреть, за какие даты есть в таблице обезличенных сделок сделки и выбрать те, что имеют старшую дату, не проходит из-за того, что таблица обезличенных сделок может быть в процессе закачки и сделки второго дня ещё в ней могут не присутствовать.
фильтповать по астрономическому времени нельзя. Ничто не мешает запустить скрипт в воскресенье без соединения с брокером и ни одной сделки за воскоесенье в нем не найти, хотя за пятницу (tradedate) они там будут. Я об этом вам писал и мне было неудобно.
как я понимаю, кроме общих слов я добиться ничего не смогу. Если так, я прошу прощения за беспокойство, благодарю за внимание и перестаю тратить время.
Sergey Gorokhov написал: s_mike@rambler.ru , Для начала, Вам нужно определиться, для чего именно Вам нужна дата. Если для получения данных из таблиц, графиков и прочие, то как уже было сказано TRADEDATE в данном случае не подойдет. Так как TRADEDATE это дата торговой сессии, а не астрономическая дата. Получается как только пройдет полночь, дата на графиках поменяется, а TRADEDATE останется прежним. На наш взгляд, дата торговой сессии Вам не нужна. А нужна текущая астрономическая дата, т.е. компьютера.
Сергей, мне даже неудобно Вам на это указывать, но астрономическая дата никак не связана с содержимым таблиц терминала. Например в воскресенье, если данные в терминале не очищены с пятницы. Они будут разными отсутствии соединения с брокером и т.д.
Тем более если время в таблицах квика зависит от какой-то глубоко закопанной галочки, о которой 99% пользователей (и я в том числе) просто не имеют понятия, так как она нахрен не нужна.
Цитата
"Получается как только пройдет полночь, дата на графиках поменяется, а TRADEDATE останется прежним."
Я не уверен, что вы уверены в написанном вами.
Зачем мне требуется весь этот огород Мне нужно собирать данные из таблицы обезличенных сделок, обрабатывать их и раскладывать по файлам. Один файл - один торговый (!) день. С отсеиванием вечерней сессии.
Ээээ, да это же просто!
А вот хрен. Потому что datetime зависит от тонны условностей, о которых уже упоминалось выше. Только не надо предлагать косорылые способы. Надо нормальный и надежный. И желательно не зависящий от галочек, разбросанных по всем пыльным углам терминала.
Повторяю свою надобность
Нужна функция, которая возвращает дату текущей сессии при старте программы. Под этой датой я понимаю последнюю дату, в которую в таблицу обезличенных сделок терминала приходили сделки.
Нужен текст колбека или еще чего-то, что мне сообщит, что эта торговая дата изменена и необходимо сделать рестарт всего скрипта.
как же это все же тяжело.... Вроде и вопросы стараюсь делать понятно и так, чтобы из нельзя было прочесть неправильно.
сергей.
как в вашем чертовом терминале получить сигнал о смене торговой даты?
мне не нужно других сигналов, на которые срабатывает oncleanup и всего остального. Мне нужно только получить торговую дату при старте скрипта (дату, а не nil, не бум, и не бац) и получить сигнал об изменении ее со значением новой торговой даты.
если где-то можно прочитать про эти ваши нагромождения неописаннвх сущностей -скпжиье где. Если нет - не могли бы вы просто привести луа код, который будет правильно ВСЕГДА работать?
1. Если после прихода колбека мы видим герустую торговую дату - это ГАРАНТИРОВАННО в любым случаях актуальная торговая дата, а не оставшаяся в кишках со вчерашнего дня?
Sessioniddd.
что это за зверь и каковы его своейства?
я подразумеваю, что документация этого мне не расскпжет,. Если ошибаюсь - прошу прощения
Про Setvalue я действительно когда-то писал, было. Помнится, что писало об этом уйма народу кроме меня - слишком очевидная дырка была. Ну что же, теперь можно констатировать, что толк есть. Целый один толк. )))
"Добавить флаг в OnCleanUp и следить за ним в main?"
s_mike@rambler.ru написал: Я правильно понимаю, что сначала срабатывает колбек oncleanup и только потом торговая дата кладется в то место, откуда ее вынимает getInfoParam?
да
От моего имени зарегистрировано за 10 лет пара десятков пожеланий.Не было случая чтобы реализовали. Уж не знаю какой у вас толк, а для меня никакого.
"Как вариант, можно смотреть getInfoParam в main(), после того как сработает OnCleanUp "
Отлично. И насколько позже? И как узнать, что данные уже обновились, если придти может снова вчерашняя дата?
Похоже что Вы запрашиваете данные через getInfoParam в момент когда в терминал эти данные еще не пришли. Колбеки срабатывают непосредственно перед тем как данные появятся в терминале. Как вариант, можно смотреть getInfoParam в main(), после того как сработает OnCleanUp Можем предложить зарегистрировать пожелание на добавление в OnCleanUp параметра, в котором будет возвращаться дата торгов.
Был бы толк от этих регистраций....
Я правильно понимаю, что сначала срабатывает колбек oncleanup и только потом торговая дата кладется в то место, откуда ее вынимает getInfoParam?
Приходится экспериментировать, так как нет внятной документации.
Приход колбека в 10 -00 был обусловлен настройками автоподключения. Время автоподключения было установлено с 10-00 до 23-00.
В момент подключения приходит колбек, в котором производится запрос getInfoParam("TRADEDATE")
Результат исполнения - либо пустой либо строка времени. Исходя из ваших разъяснений время может придти как вчерашнее так и сегодняшнее взависимости от температуры бабушки системного администратора сервера квик.
Кашамала какая-то..
Сергей.
Сможете привести однозначный алгоритм определения торговой даты, которая работает всегда и надежно, без расползающихся условностей?