Иван Ру (Все сообщения пользователя)

Нет, так не получается, выдает ошибку в модифицированной строке

[img]data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAbUAAAA7CAYAAAD8ZxTBAAAMN0lEQVR4Ae2cMW7jOhCG/7fYA+gMTgADLl34BvYWqVK4d5k0gZoUPoGLNEYap3TvItukSHyCdeHSgIHEZ9AN3sNQIkXJpCwnygvX+Q0sLFPkcOabIYektPknSZJ/wQ8JkAAJkAAJnACBHydgA00gARIgARIgAUWASY2BQAIkQAIkcDIEmNROxpU0hARIgARIgEmNMUACJEACJHAyBJjUTsaVNIQESIAESIBJjTFAAiRAAiRwMgSY1E7GlTSEBEiABEiASY0xQAIkQAIkcDIEfv7+/ftkjKEhJEACJEAC35vAzz9//nxvArSeBEiABEjgZAj8wz+TdTK+pCEkQAIk8O0J8Jnatw8BAiABEiCB0yHApHY6vqQlJEACJPDtCTCpffsQIAASIAESOB0CpaS2RBzFWDZu3xLxYIbdboZBFCHa+zfAbFezU5EhsgrVd5gNIsRa8WVc6MOUO9sWBNX8kdlTrt2Q/N1skOtvlAd85WU11O8P6VLi6ewg5EKPf5TKeYwv4zxm5FrHpYXcMrJKplUtuxRfDWoH9X57oEZ/Hh9X9V11z6VF7TKPLrXbB1GxBvOCnp8xTo7VoaL+u31SIbNgf5g/Skmtj4vRHE86OTSl8+4VG5HVusZLkiBJEqwnPfQma3WdJC+4btXsTGS8XMNbXRw5BBZZP8l6gs3wiKRZRw1tT526x9bZzXD1eIm10n+NyWaYJmtf+bHyv0P9Kv/IvV4bZ9jhdTPCRR/AMsYQiywWF8DQsbCrkvkZTD+jP4mh7S1eag+2zzAsYJmfwfxYc4/Voar+obnSq1sf09strj60KPMK//QbP/TqVK8q+xcjzOtkNbMbijGbDdy7JLXk3WF2NcZqNUZ3b4dl2adWFTHigayY00nFuTOxVh/m/uAeW0sU1KSVFahEaifNLe5VHxEie0lu7DlUXsMeS0dAVnN5UjU6y27V9J/vHnbPj8Dlryxpt3D9kmDaB3zlakXv3V27bXXrYO0Eyzwtts62Dt9Jokhjy4oPH5dC+wiD2VLtvKW9jstcnsVN2sUxYr3zr4w3YRwh6maxGHUxXs0xlJjsT5EIZO9n3+c2B6Oj1b513kHnvCVQMRjouHbbZstKY2K/PyVH21nw976PTd+WPnK5vH/E5U1mp5MdMn31SYgVuzXsAPZ1USqYWCj5znBxLCIcbdRu2swh6S5JsS/plo+rdMGi57hCubQp8HQwd+gg9hh/VYyTAnojxxoLthwT5w4djKDUXm1LGnOl+gUOMZbqd3ZCtjdOMsEe3dC/weXj/Sec2hmDPu3ih+yakmSBzjgzoH+B0ea1dLxX7n+JeLjBZC1tL7Adr9IKAvGune0yEiwgu4wWrh8m6PUmWFftsETCaoP2g8icol/YmSwwmj8VAcv9cSfdkT20sclUkN3gbWeMrgpYx2AxfVgynXpnA/wj9pSxeW3qYyo2A3jbrtDBcz7gssTnKwfytuXusJoDt8LTt+MrMnDytIV69S/5To7OXPFhyypfa7+sJ8D4DpA4kOvH5/TYes8PmYA5cJHFcBojvngTTtYJwWIEjBZIrJhMJyvZ5qe+yFUsybRjT42dq/3j8/5ULUaUjAO25Ttz7Y9Sf8Kz+4hLNd7Ehg2GekGkZSe6LQC7b2PEEk/zDiTPms8eO3PHfaH7cvlIWnjibX9OyMRreVnsm04947E/TbDojNUOYhl3Me4s8l2nkVWMdXffLp5vxXnKo4MsLg6OE2OIXHjGgi3HxFDZ75ag5b2ytzhfO+obDqUYdvrao5vqtoVfl5vmT+0skz7rMt2pxTCTKnCGNh7xXHxoVexftry9S/xSA0SOLLPbb9t0R5atgIZzYPNaJagoFkZmdlT5AFwpWUPMsYEt6k12NJMblQhUItM6qDEtE3macJ/Kyc30cYZ2L5Pp09tXXlK79k/ZNVbYpOXMH2VOT21IFwbpHV+5brf/nR2vQQK0l/rCo4PaCXp4Grmetuq+4SqLAU98GEGOC7u9fS1Vq/xgduWWPx3i06Id0o1wC7vXDXrts0LN1vWLipuLp/xZW6GC/iH6jC7S2IPE/wrbN33T8W3bY19L1SqmWlSBpzR5yXeWRt4B+5UMOXa1PkexAwrj0/RryYMj3ip9p+cQW0a1v/vTNS4fuxhuJljbu2ujjxXrvr6reGpVPG1rjRMtQ74LfZXmymNi6KyN3nyYnn4U5mu7s5KP7FsuX/t0s9odNX9b7b7y8oeshjWsdPEnQSEL5COSkW2BrH6zCVm+331+L9vi7ha3ehVu91H7Wq/ON7g7dD7s09tXXluHN2z1LrKmTaPb/JnhWTtLRgB85bVVkYo1dXDK/EjbPYEWl717joIP+0GOH+XIcYVxN0J3vMJq3EVkjrPyPm3meeknXTXKtGkdj/SRr/v3+M7XZveMRxlPqwMLb62LT46+X/X9kbZVct9zTxY/MhfuzdfvEXbabX7olzfkNEZn5Vaa1fxHkK1zdExQybFGBkmtJu6yo5j0DFifkrwLo17JLJ+gu9ByzkRHfWQKSweZJArPHGR1vkqfb+jG5W+f3r7ycnvX79UWavEuqyH7foVNUq38TFMdO563vOW26P1r/dJPiYFDB+VzF8+yUEfbchX44kMq+rjsCbEKPuIHI6aPqUwIcgwuR3UYpUfXcvwoMWMFqmZumpYvlD76OFxir4fSpq/covr3IaYFntnCxJGMKztRMrKYrKz4Th8pmY54e4/vvG3SZ0idRYJk0cH4Sj/7s5OcFes+OXV4etrWHieacaEva55S8uvHkDoalxjNkps9X+uujv726ZYJOjgOju7w/2nwUx48qo8M9ml24K6MfVKTsn0En6vUx3TxhKgbYSzTgz76E+CLbVYuW4sFEvVcWpLgEN0BDj9X053Is73hEJFks5FMQdkRjz4/aV3jYTJQz86AHno9oCNt+1OsTXkqTN6yfBE9fJtPr9517DnHffSEC/u5gDzXG0UYivK9EUa9zCifTS3ZRWQyRP9XeaV/qBoZ3eErt9pm3Ziv3gi4i6BEGV94uPY9PI0wlXGrfWLq+uPDycW081z4/OP1pyfe3rbA5Q1au2f1BuSN7q4/xeJJXlBKC3LmuoIcExZl5rEnYZ7Uf3vXEqkufTHRL/Y3Xb9ioMabtJKEfI3WblaWVvFbjr7u1BF+3z2o07a+2K2QbG45480zhny+E2FOf8siOX2Ols4pqc+68TkScWSvg+1VhEh2cSbWPX3Lc2gXTywL85R7LvONE9849I8FdwwV/a5dJUfOC/XfTjLaZr626j8YT9S88OimWmdvB09rigqoWgN/+1GC7Qp4sN8wDMhCqvLFBBgfX+yAvHt5+eH+HC/2s6j87t97JXapKSg/tv8KY5axPOwqvaBRUCTksVDSbRlj8Hrz/sdHBbv/3x8/vd1JoMjrz3sVepisb7Htyssb6UetbPWSYq8+C74fAVm1Mj6C87ucbrTlP4Wf/ZWTVXA8Cwrt8Nq+wHWhTH6EPBZ8ui0R37Xx8PJ3TuoN7NT2vMgCEiABEiABEvgSAqW/KPIlOrBTEiABEiABEmiEAJNaIxgphARIgARIIAQCTGoheIE6kAAJkAAJNEKASa0RjBRCAiRAAiQQAgEmtRC8QB1IgARIgAQaIcCk1ghGCiEBEiABEgiBAJNaCF6gDiRAAiRAAo0QYFJrBCOFkAAJkAAJhECASS0EL1AHEiABEiCBRggwqTWCkUJIgARIgARCIMCkFoIXqAMJkAAJkEAjBJjUGsFIISRAAiRAAiEQYFILwQvUgQRIgARIoBECTGqNYKQQEiABEiCBEAgwqYXgBepAAiRAAiTQCAEmtUYwUggJkAAJkEAIBJjUQvACdSABEiABEmiEAJNaIxgphARIgARIIAQCTGoheIE6kAAJkAAJNEKASa0RjBRCAiRAAiQQAgEmtRC8QB1IgARIgAQaIcCk1ghGCiEBEiABEgiBAJNaCF6gDiRAAiRAAo0QYFJrBCOFkAAJkAAJhECASS0EL1AHEiABEiCBRggwqTWCkUJIgARIgARCIMCkFoIXqAMJkAAJkEAjBJjUGsFIISRAAiRAAiEQYFILwQvUgQRIgARIoBECTGqNYKQQEiABEiCBEAgwqYXgBepAAiRAAiTQCAEmtUYwUggJkAAJkEAIBJjUQvACdSABEiABEmiEwH/v1JyJfvwtxAAAAABJRU5ErkJggg==[/img]

На днях обновил Quik который использую при работе на Финам до версии 8.02, 64-битной вместо старой 32-битной.
Скрипты перестали работать, при этом обнаружил две проблемы.
1. Очевидная - скрипт выдает ошибку при попытке загрузки или использования библиотеки w32, которую я применяю для озвучки разных событий.
Кто-либо знает о 64-битной версии библиотеки которую можно использовать взамен прежней?

2. Перестал работать следующий код:
datetime = {}
datetime.month, datetime.day, datetime.year = string.match(os.date(),"(%d*).(%d*).(%d*)")
соответствующие значения времени оказываются пустыми = nil

Необновленные квики работают корректно...

Кто-то сталкивался / решил подобные проблемы?

Спасибо. В принципе я так уже и сделал.
Функция вызывается из нескольких мест, в примере видно только одно, в частности она вызывается при смене даты. Рекурсию надо убрать конечно и в принципе нигде ее не допускать, в данном исполнении она действительно может превратиться в бесконечный цикл с запуском бесконечного количества экземпляров функции.  

Перепроверил. Сегодня удлиненный клиринг. В таблице "Состояние счета" можно видеть верные значения, функция getParamEx также возвращает верные значения.
Возможно это действительно проблема брокера. Она также наблюдалась вчера.  

Кажется нет. На 100% не уверен. Обращу внимание в следующий раз. Для меня удивительно как брокер (Финам) может транслировать такой важный параметр с ошибкой.
В результате отправляются заявки в неторговый период и получаеш штрафные баллы за спам от Биржи.  

Коллеги, просьба вести диалог в уважительном тоне, или хотя бы читать внимательнее!
При предложенном Вами исполнении, Павел Bosco, функция InitEveryDay  будет вызваться в лучшем случае единожды за все время работы скрипта -- тогда когда будет впервые установлено соединение с сервером. Выше несколько раз было сказано, что необходима ежедневная реинициализация параметров, т.е. многократное обращение к функции InitEveryDay , собственно, это даже из ее названия  понять можно!
Принципиальное решение  мне понятно -- функция вызывается при соблюдении двух обязательных и достаточных условий - соединения с сервером и смены даты. При этом ее вызов должен происходить один раз (нужен флаг сбрасываемый при смене даты).
Что касается замечания vgi, еще раз отмечу, принципиально то, что рекурсия в данном случае находится не в коллбэке. Не имеет значение откуда вызывается функция с рекурсией, она у меня может вызываться разными способами, в т.ч. и не из коллбэка, но результат плачевный в любом случае. Поэтому я и задал важный уточняющий вопрос  для Sergey Gorokhov -- я вижу что рекурсия приводит к подвисанию независимо от того в коллбэке она или нет.  

"Во вторых, как уже было сказано, нежелательно их использовать только в колбеках, а значит..."
Насколько я понимаю, функцию InitEveryDay, где имеется рекурсия не относится к коллбэкам.

ВОПРОС: "Все зависит от того что для Вас "реинициализация""
ОТВЕТ: ежедневное обновление ключевых параметров скрипта, это не OnInit, которая является коллбэком, а функция InitEveryDay. Она вызывается из OnInit, а также из еще одной функции (не колл-бэка) скрипта, которая фиксирует смену даты.

ВОПРОС: "И что мешает все тоже самое сделать в цикле "while stopMain do", а в колбеках оставить только переменные?"
ОТВЕТ: Так все-таки не получится. Этот блок проходится (функционирует) единожды -- когда скрипт инициирован (запущен), но не завершена его инициация. InitEveryDay вызывается ежедневно, в том числе, когда этот блок пройден. Я рассчитываю что мой скрипт должен работать много дней без перезапуска, собственно для этого и нужна функция InitEveryDay  

Пытаюсь использовать функцию getParamEx(class_cod, sec_code, 'EVNSTARTTIME').param_value для того чтобы получить время окончания вечернего клиринга, которое, как известно обычно - 19.00, но иногда смещается на 19.05
Однако, в те дни, когда клиринг смещается на пять минут, функция как обычно возвращает "стандартное" значение "190000".
В частности, такая ситуация была отмечена 10 января, тестировалось по ближайшим фьючерсам газпрома и других ликвидных базовых активов.
В чем дело?

Правильно ли я понимаю, что в таком случае рекурсия в принципе недопустима ни в одной из функций скрипта Lua? Корректная последовательность приблизительно такова: функция должна быть исполнена до конца, вернуть условное негативное значение, после чего, с некоторой паузой должен произойти ее повторный вызов из main, в моем случае видимо из блока while stopMain do...

Коллеги, можете ли поделиться примерами ежедневной реинициализации скрипта?

Рекурсия - когда функция ссылается сама на себя - вещь не самая удачная в программировании, однако иногда она все же нужна для работы роботов в Луа.
В частности у меня написана функция инициации робота, которая вызывает сама себя, в случае, если нет соединения с сервером. Иными словами, в определенной точки функции, если не считаны параметры времени сервера (т.е. очевидно нет связи с ним), оператором sleep инициируется пауза в работе скрипта, а затем, функция вызывает сама себя и запускается с начала.
Выглядит это в общих чертах  так:

function OnInit()
theDate = 0 -- инициируем переменную, которая будет содержать текущую дату
InitBeforSession = false -- инициация перед началом сессии
InitEveryDay () -- ежедневная инициализация
end

function InitEveryDay ()
message ('Proliv InitEveryDay start')
sleep (100)

-- Индикаторы состояния торговли
isTempStoped = false; -- временная остановка работы скрипта
isTrades = false; --есть ли торги по фьючерсам?
isTradesPrevious = false
isConnectedPrevious = false
isConnected = false

-- Флаги работы скрипта
is_run = false -- флаг работы цикла Main


-- Проверка на наличие соединения
if dDT.year == nil then -- если значения полей пустые, значит нет соединения с сервером !!! по-видимому здесь происходит какое-то зацикливание из-за которого quik намертво виснет при запуске  в период когда нет соединения с сервером
message ("Error: no connection")
sleep (5000) -- стоим на месте
InitEveryDay ()
end -- если значения полей пустые

end -- конец функции

function main()
-- Задерживаем старт main до исполнения кода onInit (после его завершения флаг stopMain будет переведен в false - см. выше)
message ("main - stopMain ")
while stopMain do -- старт  стопора while
sleep (500)
message ("main stopMain is  "..tostring(stopMain))
end -- конец стопора while
end

---------------------------

Проблема в том, что при неблагоприятных условиях, в частности если скрипт стартуется при отсутствии соединения с сервером, скрипт виснет и вешает Квик, приходится аварийно перезагружать программу.
Эта схема рекурсии с паузой и оператором sleep, как я увидел, неработоспособна и во всех других случаях, когда она регулярно (многократно) срабатавает.
В чем проблема? И как реализовать данную задачу корректно: скрипт многократно пытается инициироваться, пока не наступят благоприятные условия.

_sk_ спасибо за комментарий! Однако, предложенная схема вызывает некоторые вопросы.
Не совсем понимаю, как РЕГУЛЯРНАЯ связь реализуется через почту? Это какое же количество сообщений будет генерироваться за торговую сессию?
Более удачным кажется вариант постоянной связи терминала с удаленным клиентом - по аналогии с тимвьювером. Кстати, возможно удаленный клиент мог бы поддерживать постоянную работу того же тимвьювера и, в таком случае, он бы был способен еще и обрабатывать некоторые ошибки связанные с работой квик или скрипта, например, прекращение работы скрипта.
Упс, естественно установлен, думаю, как и у всех других торговцев. Беда, что не надолго его хватает... Интересно - каким образом реализована отправка сообщений при выключении питания. Специальное ПК-шное приложение? Родное приложение UPS?

П.С. Думаю интегрированное универсальное приложение с устойчиво работающей схемой было бы весьма востребовано в среде (алго)трейдеров.  

Коллеги, хотелось бы присоединиться к обсуждению и оживить тему - уже давно раздумываю над ее решением, вызрела собственная идеология и алгоритм.

0) ВВОДНАЯ. При выставлении лимитных ордеров и/или отсутствии стоп приказов контроль за работой скрипта принципиален с точки зрения риск-менеджмента.

1) Оптимальное решение -  контроль за работой скрипта с другого устройства - ПК или мобильного телефона, который сигнализировал бы при наличии проблемы. Иначе необходимо будет сидеть за терминалом постоянно, торговлю уже нельзя считать полностью автоматизированной

2) Проблема с работой скрипта отнюдь не ограничивается самим этим скриптом (по моему опыту приблизительно в половине случаев она лежит за его пределами). Иерархия (от частного к общему) типовых проблем такова :
- ошибка в работе скрипта
- потеря соединения с сервером брокера
- ошибка в работе Quik (нехватка памяти, падение программы)
- проблемы в работе ПК (падение системы, отключение в результате отключения электричества, отсутствие Интернета)
- проблемы у брокера (отсутствие соединения с биржой по каналу брокера -- такой на моей памяти дважды случалось у Альфа-директ)
Любая из указанных проблем лишает скрипт работоспособности и чревата потерями, но вот масштаб проблемы и ее решения в каждом случае разнятся ))

2) Отдельное сообщение от скрипта не устраняет большинства рисков, для контроля за работой скрипта он должен отсылать сообщения регулярно.
Наличие ошибки должно определяться либо по отсутствию регулярного сигнала (в результате падения ПК или отсутствия Интернета на нем), или же на основе особых состояний сигнала ( / Quik не запущен / торговая сессия идет, связи с сервером нет / скрипт не запущен).

3) Как верно отмечено - контроль должен быть реализован в стороннем по отношению к Quik приложении, которое должно функционировать на базовом и удаленном устройстве.

4) Полностью устранить риски не удастся (проблема у брокера нашими силами не разрешима в принципе, есть риск неработоспособности программы или удаленного устройства, а также канала связи между ними), однако, на один или два порядка риски проблем снизить можно .

Интересно послушать мнения о возможностях технической реализации, в первую очередь протоколах передачи данных и каналах связи. Возможно попытаюсь реализовать задачу своими силами.  

Ошибся "на все осуществленные транзакции", Т.е. если у меня 2003 неэффективных транзакции - биржа насчитает мне 2001 штрафной бал или только 3 штрафных балла ?

Формула расчета штрафных баллов и комиссии биржи приведена здесь: https://www.moex.com/a3825
Из пояснения биржи не ясно:
1. Штрафные баллы начисляются начиная с момента проведения 2000-ой транзакции или, при превышении этого порога, они начисляются на все осуществленные сделки.
2. Транзакция - размещение заявки, завершившаяся сделкой (заявка исполнена целиком), учитывается в расчетах?

"Кому надо" здесь обсуждают проблемы, а не занимаются саморекламой.

Все просят сделать простейшую вещь. Прошло три года, а воз и ныне там. Это удивительно.

Да, Вы правы, причина в чем-то другом. Буду разбираться.

При использовании такого параметра функция вообще не работает, насколько я помню - ALIGNMENT нет в спецификации в числе параметров доступных AddLabel
label.ALIGNMENT = "RIGHT" -- привязка
local labelId = AddLabel(chart_name, label); -- устанавливаем метку

П.С. Версия квик 7.19.0.51

Я наношу на графики значки / ярлыки с использованием функции AddLabel
Один из ее параметров - дата и время свечи.
Я получаю время свечи из источника данных с помощью
Выглядит для постановки ярлыка на последнюю свечку это приблизительно так:

local DATE, TIME = fCheckLastBarDateTime(ds)
fAddLabel (TheBaseSec.chart_name, "=", lastprice, DATE, TIME, R, G, 20, FONT_HEIGHT, HINT)

function fCheckLastBarDateTime(ds, index)
local lastbar_index
if index then
lastbar_index = index
else
lastbar_index = ds:Size() -- индекс последнего бара
end
local datetime = ds:T(lastbar_index)
local sdatetime = {} -- стринговая переменная с датой и временем
-- Приводим параметры к значению хх (вместо х)
for k, v in pairs (datetime) do -- перебираем таблицу datetime извлеченную из временного параметра последнего бара для добавления символов к одиночным значениям
local param = tostring(v) -- параметр в которое считывается значение отдельного поля
if #param == 1 then param = "0"..param ; end -- если только один символ, значит усечен 0 и его надо вновь добавить
sdatetime [k] = param -- записываем измененный параметр
end -- конец перебора полей таблицы времени
-- Формируем дату и время в нужном формате
local ddate = tostring(sdatetime.year)..tostring(sdatetime.month)..tostring(sdatetime.day) -- дата в виде строки
local ttime = tostring(sdatetime.hour)..tostring(sdatetime.min)..tostring(sdatetime.sec) -- время в виде строки
return ddate, ttime,  datetime
end


Однако, позиционируется ярлык на 1-2 бара раньше чем нужно? С чем это может быть связано? С путаницей времени начала и конца свечи? Иди с тем, что к началу бара привязывается край значка?

Действительно? Я торгую только российскими фьючерсами. Там много классов, которые, как кажется, не могут иметь к ним никакого отношения - те же американские акции, непонятно для каких расчетов могут потребоваться их котировки.  

Спасибо. С принципами оптимизации я знаком и их использую, думаю что не в этом дело
По второй теме - (загрузка данных по ненужным классам) Вы задали хороший вопрос! У меня на отдельной вкладке открыта таблица где строкой идут данные по всем обезличенным сделкам, "левых" данных, которых нет в других открытых таблицах, в частности данных по котировкам американских акций там вроде не проскакивает. Меня смущает то, что эти классы и отдельные инструменты выбраны в настройках Заказ данных / Выбор принимаемых параметров и инструментов.  

Проблема появилась повторно - с предложенными Вами настройками, увы, они не спасают.
Случилось это после аварийного завершения работы Quik (выключился свет).
Судя по работе скрипта Lua (а он тоже не мог получить котировки фьючерсов, за исключением FSU8 и SiU8) . Возможно отдельные модули Lua и QUik пытаются получить доступ к большому объему архивных данных котировок, но не могут этого сделать, может быть из-за перегрузки канала связи с брокером?
Сейчас помог повторный перезапуск терминала.

Еще один параллельный вопрос. Если я получаю данные о сделках с использованием опции "Исходя из открытых пользователем таблиц" - это удобнее, т.к. не надо менять списки каждый раз после того как происходит замена календарных фьючерсов. В то же время есть и проблема - у меня грузится информация по большому количеству классов и инструментов, которые нигде в таблицах не использовались никогда и не открыты. Например, по части американских акций. С чем это связано и как этого избежать?

Спасибо. Работаю неделю с такими настройками - пока полет нормальный.  

Тиковые данные при этом поступают нормально.

Вот сейчас, например, не вижу стаканов ни по одному основному фьючерсу за исключением FSU8, по акциям видно все. Чаще бывает что не видны стаканы только по некоторым значимым фьючерсам.
В "Потоке котировок" и   "Потоке обезличенных сделок", конечно, включен показ для всех фьючерсов. С чем может быть связана проблема?
П.С. Набор "непоказываемых" стаканов становится видным сразу после старта и в течении сессии не меняется.
П.С.С. При попытке подписки на стакан средствами Луа возвращаются нулевые значения бид/аск

Я довольно успешно использую следующий механизм для расчета текущего (пока позиция не закрыта) и окончательного финансового результата торговли в рублях.

Без подробных разъяснений код выглядит так:
local rublesFor1pointPrice = getPointsToRublesMultiplier('SPBFUT', sec_code) -- расчитываем рублевую стоимость 1 единицы цены лота (для большинства российских акций = 1, для товарных фьючерсов будет отличаться)
local last_price = tonumber(getParamEx('SPBFUT', sec_code, "last").param_value)
if rublesFor1pointPrice and last_price then -- если получили значение
local Margin = lotBalance * rublesFor1pointPrice * last_price -- расчитываем цену позиции в рублях
theStrategy.margin.P = Margin -- расчитываем цену позиции в рублях и записываем ее в поле E (enter) поля margin отражающего финансовый результат работы стратегии
theStrategy.margin.R = theStrategy.margin.E + Margin - theStrategy.margin.C
...

Для большинства инструментов расчет всегда оказывается корректным, но для фьючерсов, валюта которых отлична от рублей, например для RI возникают проблемы. После прохода через дневной клиринг результат по позициям открытым с 10 до 14 часов оказывается некорректным. Полагаю, это оттого, что в клиринг пересчитывается величина rublesFor1pointPrice в связи с изменением курса рубля (в приведенном случае - к доллару). Т.е. даже при снижении цены для короткой позиции результат может оказаться убыточным. Насколько я понимаю и вижу из данных таблиц Quik "Нереализованная прибыль" и "Вариционная маржа", финансовый результат рассчитанный с применением новых значений некорректен и в нашем случае необходимо использовать старое значение шага цены как для момента входа, так и для момента выхода, или же новое значение, для момента входа в позицию и ее закрытия.
Кто как решает эту проблему?

Из списка доступных классов исчез класс акций ММВБ (пятница вечером). Через creatdatasource / lua источники данных не грузятся, графики не строятся и не обновляются. При редактировании таблиц этот класс не отображается. В чем дело не могу понять.  

Спасибо, это то что мне нужно! Другим рекомендую не забыть включить отображение соотв. полей (стоимость шага цены) в таблице фьючерсов.

Правда на метод InfoSecurities.isFuturesClass у меня квик что-то ругается : attempt to index global 'InfoSecurities' (a nil value)

Я ищу штатное или готовое решение. Речь об этом.

Это частное решение. Плюс не совсем понятно на какой момент времени брать курс доллара. С расчетами завтра или сегодня? По среднему между бид/аск на момент времени (например, вход) или по цене последней сделки? А если у нас фьючерс на курс евро-доллар? На золото? Получается индивидуальный расчет для каждого инструмента исчисляемого не в рублях. Очень сложно. Кажется должно быть более простое штатное решение.  

Нет, с ценой последней сделки все понятно, их я активно использую, если Вы о котировках.
Уточняю, мне нужен рублевый эквивалент стоимости одного фьючерса (1 лота), -- тот который в конечном счете используется для расчета вариационной маржи по позиции. Хочу правильно рассчитывать этот показатель (рублевая цена) на момент заключения сделки (вход в позицию) и на любой другой момент вплоть до выхода из сделки (закрытие позиции). Акцентирую внимание - все это хочу знать в расчете на лот, а не в расчете на позицию. Зная рублевую цену позиции и количество лотов можно конечно рассчитать упоминаемый мной рублевый эквивалент стоимости одного фьючерсного контракта, скажем на золото или брент, но мне кажется помимо такого кривого расчета, должен быть и "прямой" позволяющий узнать сразу цену лота.  

Ок, спасибо, полезно, хотя и не совсем то что хотелось бы. Размер позиции в лотах может изменяться в результате работы нескольких роботов и ручной торговли. Я же хочу на лету рассчитывать финансовые результаты работы отдельных роботов, в частности торговый результат на данный момент. .
Для этого хочу знать стоимость именно фьючерсного контракта в том числе в момент совершения покупки и до него... Ну например - сколько стоит 1 фьюч на нефть в рублях (не ГО, а именно цена в рублях) в разные моменты времени, которая потом будет конвертирована в вариационную маржу).  

Как определить программно стоимость позиции или лота "сложных" фьючерсов на индексы и биржевые товары (Ri, BR и др.)
Есть ли стандартная функция или надо считать по сложному?

Совпадают.
В принципе для обхода проблемы я применял вот такие функции, пользуйтесь кому нужно и критикуйте кто может


-- ТЕКУЩЕЕ ВРЕМЯ ПО ГРИНВИЧУ (ТАБЛИЦА)
function fTimeGrinvichTable()
dtServ = {};
dtServ = os.date("!*t",os.time())
for key,value in pairs(dtServ) do dtServ[key] = tonumber(value) end
return dtServ
end

-- ТЕКУЩЕЕ ЛОКАЛЬНОЕ (ПОЯСНОЕ) ВРЕМЯ (POSIX)
function fTimeLocalPosix(offset) -- offset - смещение поясного времени в секундах (целое положительное или отрицательное цифровое значение)
if offset == nil then offset = os.offset() ; end -- если не удалось считать временной сдвиг, рассчитываем его по стандартной функции
local posix = os.time()-- считываем текущее время ПК в формате POSIX
posix = posix + offset-- добавляем поясной сдвиг
return posix -- возвращаем полученные значения
end

-- ТЕКУЩЕЕ ЛОКАЛЬНОЕ (ПОЯСНОЕ) ВРЕМЯ (POSIX + ТАБЛИЦА)
function fTimeLocal(offset) -- offset - смещение поясного времени в секундах (целое положительное или отрицательное цифровое значение)
if offset == nil then offset = os.offset() ; end -- если не удалось считать временной сдвиг, рассчитываем его по стандартной функции
local posix = os.time()-- считываем текущее время ПК в формате POSIX
posix = posix + offset-- добавляем поясной сдвиг
local datetime = os.date("!*t", posix)-- переводим в формат таблицы
return posix, datetime-- возвращаем полученные значения
end

-- СМЕЩЕНИЕ ВРЕМЕНИ ОТНОСИТЕЛЬНО ГРИНВИЧА ЛОКАЛЬНОЕ / ПОЯСНОЕ ВРЕМЯ К ГРИНВИЧУ - (СЕКУНДЫ)
function os.offset()
  local currenttime = os.time()
  local datetime = os.date("!*t",currenttime)
  datetime.isdst = true -- Флаг дневного времени суток
  return currenttime - os.time(datetime)
end

-- ДОПОЛНЕНИЕ ТАБЛИЦЫ ВРЕМЕНИ (Добавляет к поляем времени поля текущей даты, а также поле 'posix' с данными в соотв. формате)
function curDayToPosix (timeTab, dateTab, offset) -- timeTab -- таблица со временем, но без полей дат, dateTab - таблица с полями дат
if offset == nil then offset = os.offset() ; end -- если не удалось считать временной сдвиг, рассчитываем его по стандартной функции
-- устанавливаем в поля даты значения текущего дня
timeTab.year = dateTab.year
timeTab.month = dateTab.month
timeTab.day = dateTab.day
timeTab.posix = os.time (timeTab) + offset
end  

Да, так все совпадает. Спасибо.  

Попробуйте получить время posix с помощью os.time, а затем конвертировать его во время в табличном формате. Получится рассинхронизация
Посмотрите на пример кода и полученный результат

КОД:
local posix = os.time()
message ('os.time()'.."-"..tostring(posix))
local ttime = os.date()
message ('os.date()'.."-"..tostring(ttime))
local posixToDate = os.date("!*t", posix)
local posixToDateStr = posixToDate.hour..":"..posixToDate.min
message ('Convert os.date() result to posix'.."-"..tostring(posixToDateStr))

РЕЗУЛЬТАТ ИСПОЛНЕНИЯ:


Мои скрипты первоначально считывали время и дату сервера и уже ее конвертировали в формат posix, но я столкнулся с проблемой -- периодически выскакивала ошибка типа "в таблице отсутствует поле day/hour и т.п.). Каких либо закономерностей не обнаружил, я так понял, что это связано с потерей пакетов при загрузке интернет-канала или какими-то другими проблемами связанными с соединением локальной машины и сервера -- поэтому от этого способа пришлось отказаться.  

При выставлении заявок роботами я активно использую поле для комментариев -- так я отличаю заявки разных роботов.
Делаю я это с помощью нижеприведенного поля:

["CLIENT_CODE"] = roboName, -- так в заявках выставляемых с полями на английском
["Комментарий"] = roboName, -- так в заявках на русском


Около недели назад, в выставленных заявках, где используются обозначение полей на английском, поля перестали приходить в функции OnTransReply.
Т.е. поле brokerref, которое возвращает функция OnTransReply оказывается пустым.
При этом в таблице заявок и сделок Quik имя робота прекрасно отображается в поле "Комментарий "
Кто-либо сталкивался с такой проблемой? С чем она может быть связана

Нееет... эта функция возвращает время по Гринвичу, которое не совпадает с локальным временем компьютера и с временем сервера.
Я уже реализовал получение точного локального времени, но выглядит эта конструкция очень громоздко - потребовалось 8 операций, включая 5 вызовов функции даты и времени!

-- ТЕКУЩЕЕ ЛОКАЛЬНОЕ (ПОЯСНОЕ) ВРЕМЯ (POSIX + ТАБЛИЦА)
function fTimeLocal(offset) -- offset - смещение поясного времени в секундах (целое положительное или отрицательное цифровое значение)
if offset == nil then offset = os.offset() ; end -- если не получили временной сдвиг, рассчитываем его по стандартной функции
local posix = os.time()-- считываем текущее время ПК в формате POSIX
posix = posix + offset-- добавляем поясной сдвиг
local datetime = os.date("!*t", posix)-- переводим в формат таблицы
return posix, datetime-- возвращаем полученные значения
end

-- СМЕЩЕНИЕ ВРЕМЕНИ ОТНОСИТЕЛЬНО ГРИНВИЧА ЛОКАЛЬНОЕ / ПОЯСНОЕ ВРЕМЯ К ГРИНВИЧУ - (СЕКУНДЫ)
function os.offset()
  local currenttime = os.time()
  local datetime = os.date("!*t",currenttime)
  datetime.isdst = true -- Флаг дневного времени суток
  return currenttime - os.time(datetime)
end

1. Все нормально синхронизировано. На компьютере время точное - проблема не в этом, а как Вы верно заметили, в том что сервер выдает время последних торгов, которое не всегда актуально.
2. Это значит, что считывание актуального времени (в виде таблицы) с помощью квик и луа -- простейшая, казалось бы, задача, -- становится очень нетривиальным действом.
Просто так считать с помощью date | time его нельзя. Необходимо рассчитывать разницу между поясным временем и временем Гринвича, конвертировать время в формат POSIX, добавлять нужную величину, а затем конвертировать время POSIX в таблицу.
Т.е. получение ключевого простейшего показателя требует выполнения четырех ресурсоемких функций!! Или может я что-то недопонимаю и есть более простой путь?

Спасибо kroki , Вы совершенно верно описали мой резон. Замечание ваше перепроверю на практике.
Я обнаруживал забавное явление. Моя программа дважды в секунду считывает стакан и ведет подсчет неудачных попыток считывания. Я обнаружил, что даже на ликвидных акциях приблизительно в одном случае из двухста попытка считать стакан оказывается неудачной, точнее приходят пустые данные. В любых ситуациях, даже при широком канале. Интересно, с чем это связано?

Тестирую вот такой код:

dt = {}
dt.day,dt.month,dt.year,dt.hour,dt.min,dt.sec = string.match(getInfoParam('TRADEDATE')..' '..getInfoParam('SERVERTIME'),"(%d*).(%d*).(%d*) (%d*):(%d*):(%d*)")
message (tostring(dt.day).."-"..tostring(dt.hour)..":"..tostring(dt.min)..":"..tostring(dt.sec))

Сейчас, 12 февраля в 02 часа ночи, однако результат исполнения кода дает время - 9 февраля, 12 часов дня. При этом в строке сообщений Quik время выводится верное (оно берется из компа?)
Выглядит строка сообщений приблизительно так:
2:17:29  09-12:17:29

Почему время сервера сильно отстает от реального? У меня из-за этого проблемы с исполнением кода...

Пробовал, все-равно ошибка периодически проскакивает. Все-таки хочу понять - как ее обрабатывать, чтобы скрипт не падал, буду изучать ссылку приведенную выше.  

В последнее время в робот периодически выдает ошибку чтения стакана и падаете.
Не может прочитать поле price вот в таком коде (ошибка "attempt to index field &"  в строках bidPrice = ... ; offerPrice = ...). Не спрашиваю как ее избежать, как ее обработать чтобы скрипт не падал? Как видите опробовал уже и разные проверочные условия, почему-то все-равно проскакивает...


function bidoffCalc(value) -- value -- таблица-объект с данными об инструменте, включая ссылку на базовый актив и его параметры (tShares.value)
Subscribe_Level_II_Quotes(value.cod, value.sec)
value.tbl =  getQuoteLevel2(value.cod, value.sec) --считываем стакан
-- расчитываем bid ask
local indexBid = tonumber(value.tbl.bid_count);
local indexAsk = tonumber(value.tbl.offer_count);
local bidPrice = 0
local offerPrice = 0
 if indexBid ~= nil then
  if value.tbl.bid then
   bidPrice = tonumber(value.tbl.bid[indexBid].price)  -- !!!!!!!!!!! где-то здесь появляться ссылка на несуществующую переменную выпадает ошибка attemp to index
  end
 end
if indexAsk ~= nil then
if value.tbl.offer then -- если существует соответствующее значение
  offerPrice = tonumber(value.tbl.offer[1].price)
 end
end
return bidPrice, offerPrice -- NUMBER
end

Спасибо. По поводу вертикальной линии - чтобы не держать метку для каждого размера,  должна быть возможность растягивать метку по одному измерению (вертикали), однако я не вижу инструмента позволяющего это делать в настройках метки. Кроме того, в квике нет возможности создания пустого поля (окна в окне) для отображения вертикальных линий-меток со своей собственной шкалой -- тут также необходимо изголяться и втюхивать их в какой-либо индикатор или показатель объема.  

Пример такой, я считываю данные по стакану и анализирую их. В случае какой-либо ошибки (торговая сессия завершена, не удалось считать стака, бид или аск и т.п.) нужно сразу завершить анализ инструмента и перейти к следующему в рамках цикла.
На Си++ такое действо можно совершить с помощью оператора continue. Как это сделать в Lua - инфы нигде не нашел. Можно использовать условия if then, но придется городить их огромное количество, что сильно усложняет читабельность кода. Есть какой либо простой выход/ спецоператор?

Спасибо за ответ.
Я уже работаю с метками и это много дает! Но визуализировать таким образом вертикальные линии как мне кажется невозможно (если Вы знаете как - буду признателен за совет), а горизонтальные - неудобно и ресурсоемко.
Не совсем понял про прямую связку луа и эксель (стройте линии в Экселе сразу из скрипта луа). Разъясните пожалуйста, что имеется ввиду и где про это написано?

Печаль! Почему же так??? Давно ведь просили. Когда ждать?
Мне сейчас для построения стратегии необходимо визуализировать сконструированные в lua параметры, без такого функционала это сделать в квике неовзможно, увы. Единственный выход -- сбрасывать данные в текстовый файл, потом качать в эксель и там строить. Кучу времени придется гробить...

Ну и чем все закончилось? Есть ли такая возможность сейчас? Можно ли из Lua (не LuaIndicators, а именно LUa) отрисовывать иные объекты кроме меток - линии, бары и т.п.? Крайне актуально!

Выше я написал, что работаю через Финам.

Нет, там пусто. Ничего не экспортируется. Мне это не нужно, не пользуюсь.
Имеет ли значение большое число инструментов в "Потоке обезличенных сделок..."