Борис Гудылин (Все сообщения пользователя)

Для подобных целей я добавил к окну "кнопку сохранения". После подстройки окна скрипт по этой кнопке сохранит параметры окна в файл, откуда при необходимости возьмет их для восстановления окна.

В QLUA.chm  - "Функции и глобальные переменные переменные скрипта индикатора"
Там нет AllocTable()

Когда-то было более четкое разделение: скрипт LUA и индикатор ТА.
Со временем граница размывается, может их вообще хотят уравнять в возможностях?
Документация соответствует этой размытости, а может, она является причиной таких недоразумений.

Интересно заканчивается вышеуказанный раздел, рекурсия какая-то

• Список функций, доступных из скрипта индикатора
  

   

Можно воспользоваться выходом OnParam, профильтровать в нем какой-либо ликвидный инструмент, например, тот, что вы задаете в CreateDataSource, потом с помощью GetParamEx проследить динамику изменения параметров по Вашему списку. Если не фильтровать, то можно схватить событий в десятки раз больше.
Что-то из параметров не будет меняться, что-то будет меняться, даже часто.
ТТТ формируется срезами, точность времени -1 сек, с признаками балансировки и ограничения нагрузки. Несколько событий могут быть привязаны к одной секунде.

Такую же точность во временном штампе Вы получите, если запросите источник данных типа
     ds1,error_desc = CreateDataSource(p_classcode, p_seccode, INTERVAL_TICK, "last")
с заданием программы выхода
     ds1:SetUpdateCallback(OnUpdate)
Оба выхода (OnParam и OnUpdate) для выбранного инструмента будут вызываться срезами и синхронно ("last" оказывается сильнее INTERVAL_TICK). По факту, по реализации - близнецы с некоторыми нюансами,  как бы, гибридный вариант - источник, вроде, тиковый, но данные из него выдаются срезами, с пропусками.

Достоинства источника по параметрам - меньшая зависимость от трафика, чем в чистом INTERVAL_TICK без "last" или OnAllTrade.
Недостаток - при работе со срезами можно что-то "проморгать", например, экстремумы. Не для всех целей годится.

Вопрос к разработчикам
ds1,error_desc = CreateDataSource(p_classcode, p_seccode, INTERVAL_M1)
ds1:SetUpdateCallback(OnUpdate)
В программу выхода текущая свечка поступает несколькими порциями (срезами, так воспринимается, по крайней мере). Но срез не совсем обычный, кто-то раздвигает  H(index) и L(index), как минимум.
Насколько корректно и из каких источников идет коррекция H и L на текущий момент?
Можно ли при этом доверять полностью значениям H(index) и L(index) или они, пусть и крайне редко, но могут незначительно отличаться от действительных (для полностью сформированных свечек)?






 

Вы и сейчас можете отрезками изобразить многоугольники (вертикаль только "кривая" будет) и сами должны чувствовать текущие пределы.
На реализацию даже уже принятых предложений по доработке у разработчиков уходят годы.
Стоит ли ждать?

Imho, лучше считать, что индикаторы - промежуточный этап для отработки решений на пути к роботу.  

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

Отрезок просто изобразить, задав значения для начальной и конечной свечек (остальные оставив nil). QUIK соединит эти точки линией, если выбрать для линии индикатора Type = TYPE_LINE.

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

Попробую еще раз.
Не надо фантазировать, не надо гадать, надо просто знать матчасть. Если не работаете с ТВС (таблица всех сделок), дальше не читайте, забудьте.

У сделки две стороны - покупатель и продавец. Покупатель увидит в своей таблице сделок - "покупка", продавец в своей - "продажа".
Но в таблице всех сделок (QUIK ее транслирует с биржи, она едина для всех, может по другому называться) можно увидеть только что-то одно "покупка" или "продажа".
Есть алгоритм сведения ордеров и в нем не бросается монетка. Так, что же мы увидим в ТВС? На кого спишем эту строчку про сделку, на покупателя или на продавца?

Правильный ответ - "Цирк, да и только! В ленте мы видим того кто оказался меньшим по объёму". Окрестности этого контекста из той статьи стоит прочитать тем, кто пытается  "вычислить"
кого-то или что-то по ТВС.

Все.


 

Зависит от того, кто активная сторона (рыночный ордер, он двигает цену), а кто - пассивная (лимитный ордер).

И еще размер имеет значение :).
Падаете ли Вы на плиту или плита падает на Вас - есть разница.

Для начала можно посмотреть что-нибудь вроде "сведение ордеров на бирже".

Подробности поищите по контексту "эпический батл quik".  Там много интересного, но найти надо нужный фрагмент.

... Один мой брокер обычно затягивает с обновлением версии сервера.
Мои самостоятельные попытки обновить версию терминала (беру риск на себя) отчасти основаны на своем понимании внесенных обновлений.
Все ли обновления описаны или что-то существенное опущено, правильно ли я их интерпретировал и осознал степень локальности - это риск.

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

Насколько аккуратны и последовательны разработчики в этом контроле - наверное, как и во всем остальном.
Но послушать их концепцию по этому вопросу интересно.

И частный вопрос - насколько корректна ручная замена всего, что можно заменить или добавить, взяв из новой версии терминала? Есть ли подводные камни?  

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

В этом смысле мой индикатор не отличается от Вашего, только математика в нем сложная.

Другой тип пользовательских программ в QUIK - скрипты, выполняют функции роботов, реализующих определенные торговые стратегии. Они тоже имеют доступ и могут анализировать свечки от первой до текущей, также имеют доступ ко многим таблицам QUIK. Они выдают торговые операции и отслеживают их прохождение, работают в темную,  Могут выводить какие-то данные в таблицы на экран и что-то получать в ответ. Это - по минимуму.

Вот еще пример того же неотстающего индикатора (на соответствие противоположных экстремумов заданному начальному экстремуму).

P.S. Последние 20 свечек находятся на правом конце графика, зачем Вам их номера?

Осложнения.
 
Сделка - процесс парный, есть покупатель и есть продавец. То, на кого она списывается - зависит от нескольких факторов.
Можно найти в Интернете правильный ответ, но вряд ли он обрадует.

Не надо иллюзий.

Обратили внимание, что Ваш впередсмотрящий индикатор заморозил свои показания на последних 20 свечках?
Найдите ошибку в коде.
Намек: некоторые переменные идут у Вас как глобальные и Вы ими фактически пользуетесь, хотя и есть отсекающая проверка

if high13 then

Добавьте else для этой проверки
...
  high1=high/21
  high2=high3/5
  else  
  return nil, nil
  end;
  return high1, high2
end

А десятью свечками ранее это выглядело так.

Попытка 2.

Построить неотстающий индикатор, синхронно чувствующий экстремумы - можно, но задача эта сложна.
[img]file:///C:/GBP-3.png[/img]

Вас устроит мой ответ, если 100 заменить на 3000 (минут, часов или дней)? Замените и перечитайте его еще раз..

А гадать нет смысла. Надо вставить отладочную выдачу поступившего на вход индикатора номера свечки, для которой надо выполнить расчет индикатора

function OnCalculate(index)
message("!!!Primer3 - " .. tostring(index), 1)

Увидите, сколько раз вызывается Ваш индикатор и с какими номерами свечек.

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

Нет, не получается.

Представьте, что на момент установки индикатора на графике уже есть 100 свечек. Индикатор после установки вызовется 100 раз (со значениями index на входе от 1 до 100), по каждому вызову для конкретного index  вернет значения для отображения в позиции index. Для последней (текущей) свечки он может дополнительно вызваться несколько раз, поскольку эта свечка еще может меняться, соответственно и возвращаемые значения индикатора для этой свечки  могут меняться. Появится новая свечка - индикатор будет вызываться для вычисления своих значений для этой позиции.

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

Осложнения.
При добавлении или изменении какого-либо индикатора  на диаграмме все индикаторы этой диаграммы будут пересчитаны (вызваны для всех свечек от первой до последней).

Когда-то при запуске QUIK на графике штатно оставляли 3000 свечек, в течение дня их количество могло увеличиться в зависимости от таймфрейма.
Сейчас это ограничение увеличили до 64000 (пусть меня поправят, мне и 3000 много).    

В первом варианте Вы пытались заглянуть в несуществующее прошлое, используя H(index-2) (для свечек с номером 1 и 2), а сейчас - в еще не существующее будущее, используя H(index+1) (для текущей свечки).
Ошибка все та же, только на другом конце.
Индикатор последовательно вызывается для свечек с номерами от 1 до текущей, появится следующая свечка - индикатор опять вызовут. Текущая свечка может меняться несколько раз, соответственно и индикатор вызовется несколько раз.
В следующей версии вручную проверьте, какими данными пользуется Ваш индикатор и что он собирается выдавать для свечек с номерами (index) 1 и 2, а также для текущей свечки.
Держите себя в рамках.    

Проверьте имя FastMA2, как точно пишется с учетом регистра и где определена.  

Взгляните (визуально) на две первые свечки графика, Ваш индикатор на них не имеет значений.
И QUIK Вас проинформировал об этом в окне сообщений - проблема в строчке 42

     vrem=(H(index-1)+H(index-2))/2

\LuaIndicators\!!!Primer3.lua:42: attempt to perform arithmetic on a nil value

То, что производит декомпилятор - LUA только формально. Компилятор или интерпретатор примут его и выполнят все, что в таком скрипте написано.
Но мало кто работает с такими скриптами. Многим они будут непонятны. Они обычно раза в два раздуты в сравнении с оригинальным скриптом, мешает обезличенность, трудности с пониманием замыканий и Upvalue.
Хорошо, когда есть вспомогательные вкрапления, типа имен файлов, каких-то штатных или системных функций, сообщений. Вам повезло, что Вы в целом и в некоторых деталях представляете предметную область и что  декомпилятор не навернулся или не выдал много ошибок, как в последнем dis.txt.
Скорее всего, Вам придется ориентироваться на собственные силы, свою наблюдательность и сообразительность, сопоставление результатов разных декомпиляторов и общие соображения. В тяжелых случаях дойдете и до дисассемблирования (опция -dis в Luadec).
А LUA можно и со словарем.  

Всегда при программировании учитывайте граничные условия.
Что такое index-2 для начальной свечки в OnCalculate (ее индекс равен 1)?  

LUA я тоже не знаю, только немного со словарем.

Поэтому примите за гипотезу,
В L14_14 io.popen запускает программу sha256sum в отдельном процессе и возвращает дескриптор файла /tmp/update_sd-getsum.tmp, который можно использовать для записи данных к этой программе.

Кусками по 4К переписывает туда файл прошивки с начала (в L21_21 перед вызовом L14_14 было seek-"set"), по длине, да, за минусом 32 байтов, последний может быть неполным 4К.
Закрывает записанный файл (что сделает sha256sum - даже не догадываюсь) и открывает его для чтения на предмет match("%x+"), что получится, то и вернет в L21_21, но сначала закроет его и удалит
(os.remove("/tmp/update_sd-getsum.tmp")).

Короче, поработал я немного за интерпретатор, разобраться можно, все вроде складывается. Формальные текстовые подстановки. Декомпиляцию можно поджать, сотни 2 строк будет,

P.S. Вам надо на другой форум, здесь больше про расширение LUA для взаимодействия с биржей.  

Одна из возможных технологий в реинжиниринге (reverse engineering) примерно такая:
- находите LUADEC для LUA 5.3
- дисассемблируете Ваш бинарник (опция -dis), результат получается без кривизны, но он в кодах VM LUA - это эталон
- то, что у Вас криво получилось - это декомпиляция (декомпиляторы бывают разные, некоторые иногда даже срабатывают правильно), она пригодится  - ее можно взять за основу для внесения правок
- визуально сравниваете (сопоставляете) тексты дисассемблера и декомпиляции
- при параллельном сравнении находите кривизну в декомпиляции, догадываетесь в чем она и вносите правки в декомпиляцию, обычно это достаточно прозрачно
- декомпиляцию с правками пропускаете через компилятор, получаете бинарник, его дисассемблируете и сравниваете с эталоном (можно визуально, можно программами сравнения файлов), при успехе сравнения - работаете с полученной декомпиляцией (смотрите алгоритм скрипта), при желании ее текст можно сильно подсократить очевидным сворачиванием, получите совсем компактный исходник, но придется контролировать через дисассемблирование и сравнение с эталоном      
- для простых случаев большего не требуется
- если не справились - ищете документацию на коды-инструкции VM LUA (их десятка 4)
- углубляетесь и приходите в состояние просветления, даже находите возможности улучшения качества написания скриптов

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

P.S. Даже если декомпилятор сразу дал правдоподобный текст, его все равно стоит проверить на совпадение с эталоном (по кодам VM LUA)

Для поиска синтаксических ошибок можно воспользоваться, например, возможностями Текстового редактора - компилятора ScITE из LuaForWindows_v5.1.4-46.

Одна из ссылок
http://oojoo.ru/page123

Если я правильно понимаю замысел, то Вы хотите рисовать 4 (четыре) линии. Тогда в Init() надо дать return 4.
В Settings после описания линии "Low" пропущена запятая.
При запуске ищите имя индикатора - Channel.

На демках использование TRADINGSTATUS и STATUS сомнительно. У меня они на паре демок просто не работали. Расписание сессий в демках в ТТТ тоже недостоверны, у меня там и сессий больше было (4 против 3 на реале).  Может, с демками не повезло.

О расписании торгов в реале. Даже если вам приходит сообщение, что вечерка начнется в 19:10, то по факту она может начаться и в 19:05.  

Я создаю программы в редакторе FAR, при этом по необходимости переключаю кодировки Win-Dos, чтобы то немногое текстовое, что я собираюсь писать в файлы, попадало в них в нужной мне кодировке. .
Проще я уже не объясню.  

Возможно, Вам будет достаточно переключения кодировки в текстовом редакторе FAR между Win и DOS, выполняемой по F8.
Я иногда пользуюсь этим приемом.  

Выдаст в рамках доступной в терминале истории, если Вы ранее поработали с требуемым инструментом на требуемом ТФ.
Например, мне сейчас, даже без попытки установить соединение (воскресенье все-таки), терминал дал доступ к 7032 свечкам RIZ7 на M1.
Дал бы и более длинную историю, но мне даже этого много, периодически обрезаю (online) через перезаказ данных.  

Схематично
     ds1,error_desc = CreateDataSource(p_classcode, p_seccode, INTERVAL_M1)
    ...
    проверки-ожидание доступности (типа if ds1 == nil then ...и if ds1:Size()==0 then ...)
    ...
Далее обычные обращения ds1:H(n), ds1:L(n), ...

Основная идея - reverse engineering, декомпиляция бинарника с кодами виртуальной LUA-машины в псевдоисходный код.
Можно найти несколько декомпиляторов разной степени паршивости и документацию на инструкции виртуальной машины. Добавить что-то самописное.
Занятие трудоемкое, итеративное. Много ловушек и находок, но добиться стопроцентного восстановления можно. Пробовал на паре программ в несколько тысяч строк.
Скорее всего - занятие для немногих, почти как детективное расследование.  

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

По моим наблюдениям OnConnected еще не означает, что в QUIK уже все проинициализировано. Например, время сервера после OnConnected часто бывает еще отсутствующим некоторое время..

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

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

P.S. Пишу в спешке, в походных условиях, мог просто не "въехать" в ситуацию.

Скорее всего здесь какой-то организационный момент - что-то служит импульсом для начала формирования длинной истории: брокер ли, запрос от QUIK к серверу, мой ли запрос в CreateDataSource - гипотез можно много породить.
Меня это не особо беспокоит, хотя интересно было бы знать, сколько времени ждать накопления длинной истории и надо ли этого ждать (уже на дневках жизни может не хватить) или она внезапно появится во всей полноте. Просто хочется  определенности.  

Проверил сейчас несколько инструментов из класса TQBR (ТФ М1).
ARSA - 3003 свечек
GAZP - 4269 (подрастает, намедни было 3526)
LKOH - 3212
SBER - 13194 (вполне нормально)
GMKN - 3212
MFON - 3152

и в SPBFUT (M1)
SiM7 - 18579 свечек
RIM7 - 18579
SRM7 - 3221

Разнобой заметен, что-то ограничивает и не думаю, что для анализа нужен архив рабочего места.

И еще раз проверил и подтверждаю (на разных инструментах) - если закрыть QUIK, не останавливая скрипт, который подключал данные по  CreateDataSource + Callback,
то после перезапуска QUIK и установления связи CreateDataSource (Size()) покажет доступность всех свечек, но и Callback получит их все, сначала старые, а потом уже новые.

В чем-то даже удобно. Тоже не думаю, что для анализа (баг или фича) нужен архив рабочего места. Но тоже хотелось бы определенности, но уже меньше, чем по первому пункту.      

Естественно - не подходит. Если я закрою глаза, то вообще не увижу ни одной свечки, но в QUIKе они же не исчезут.

Меня же беспокоят потенциально возможная перегруженность QUIK при увеличении количества обслуживаемых свечек до 64К (в 20 раз против существующего лимита). Это хорошо для обработки истории (можно даже в нерабочее время), когда время не особо критично.

Но в реальной работе на некоторых алгоритмах обсчет большого количества свечек бесполезен - очень долог для, например, ТФ М1.  И появились проблемы с памятью - запустил 3 QUIK от разных провайдеров и уже приходится закрывать другие приложения - во избежание деградации системы. Возможно, я ранее других почувствовал проблемы: Работаю на М1 (когда еще накопятся :64К свечек для высоких ТФ), подобрался к секундным ТФ, алгоритмы тяжелые (обсчет детерминированного хаоса), выжал почти все, резервов осталось мало.

В этих условиях добавление в QUIK параметра размера используемой истории представляется разумным решением.  

Вам будут говорить, что в Callback cb будут поступать только новые свечки, а после торгов их нет и Вам надо самому в main пробежаться по всем свечкам и взять из них все, что надо.
Но если вы хотите получить именно через Callback после торгов, то есть прием (в 7.10 пока работает).
Запускаете скрипт. Закрываете QUIK. Перезапускаете. График у меня уже был, но это несущественно. У меня сейчас Size() по вашим данным равен 3526. Устанавливаете соединение и Callback получит все 3526 свечек.

Баг это или фича - несколько дней назад я задавал этот вопрос - никто не отреагировал.

Так же, как никто не отреагировал на количество выдаваемых свечек - почему для GAZP (M1) их 3526, а для SiM7 их уже более 17000.

Не совсем так. И лучше быть готовым к любому развитию событий.

Простой скрипт, CreateDataSource для RIM7, для которого уже есть график на М1 и уже накопилось более 16000 свечек, устанавливается инжектор (SetUpdateCallback) - все обычно.
Загружаем QUIK (7.10), до установления соединения запускаем скрипт,  CreateDataSource успешен, ds:Size() покажет 16744 (столько сейчас есть свечек на М1) - можно выбирать самому нужные свечки. Callback молчит.

А затем устанавливаем соединение. Перезапускается скрипт, CreateDataSource успешен, ds:Size() покажет 16744. Вроде все штатно. И вдруг оживает Callback и получает все 16744 свечек. Кстати вброс такого количества свечек с простейшей обработкой происходит примерно за 1 секунду.
Для сравнения - если после этого разорвать соединение и снова установить (без перезагрузки QUIK), то развитие идет по первому варианту (Callback молчит). Могут вброситься дополнительные свечки в хвосте, если появились.

Вопрос. Есть ли в этом что-то неожиданное?

Смежный вопрос - для меня назревает некоторая проблема. Спасибо разработчикам за возможность подрастить количество свечек с 3К до 64К - будет удобно работать с историей. Специфика моих индикаторов и алгоритмов в скриптах - используется много памяти с целью повысить их быстродействие.  Такое большое количество свечек будет съедать много памяти. Уже чувствую ограничение возможностей. При том, что для реальной работы скриптам не нужно такое большое количество свечек (1000, скорее всего, хватило бы). Очевидно, что я буду обрабатывать только небольшой хвост истории. Но штатное хранение и использование большого количества свечек опасно деградацией QUIKа.

Предложение. Ввести в параметры настройки QUIK размер хранимой/усекаемой истории (типа тех 3000 свечек, что неявно были до недавнего времени).  

Спасибо.  

О синхронизации локального времени с сервером точного времени.
 
Раз в час синхронизирую время с сервером точного времени ntp1.vniiftri.ru. Сразу после этого  локальное время и время биржи если и отличаются, то не слишком заметно.
Но за час расхождение достигает нескольких секунд.  

Сергей Королев, не пробовали с помощью промежуточных выдач (message()  или в файл протокола) локализовать проблемный участок? Устойчиво ли воссоздается ситуация? Есть ли зависимость от версий QUIK?  

Да, но еще и алгоритмы пришлось ускорить (скорость в ущерб памяти).

Автор вопроса уже не новичок здесь, но к теме потоков QUIK, похоже, подошел только сейчас.
Не стоит ждать от разработчиков переработки архитектуры QUIK, лучше учесть специфику существующей.

Есть еще пара вариантов, кроме банального зацикливания, когда индикаторы (OnCalculate), выполняющиеся последовательно в основном потоке, не спешат вернуть управление QUIK, тормозя или блокируя его работу.

1. реальный вариант - есть алгоритмы, которые требуют очень большого объема вычислений. Когда-то мои простейшие алгоритмы требовали на QPILE нескольких минут для построения индикатора.
LUA + DLL (C++) дали выигрыш  по скорости в 5-6 порядков, но существенно более сильные алгоритмы мне пока не все доступны.

2. маловероятный вариант - некорректное использование средств Windows (типа WaitForMultipleObjects) для синхронизации потоков. Вряд ли автор их использовал, это больше относится к скриптам (роботам), чем к индикаторам.        

Пока от индикаторов еще не отказался, но собирался поставить временные "костыли" в целях противодействия бессмысленному перерасчету всех индикаторов, например, при безобидной смене цвета линии какого-либо индикатора.
У меня очень "тяжелые" индикаторы (процессор) и их количество на одном графике может достигать нескольких десятков. И, в частности,  собирался опереться на значения параметров.
Тоже столкнулся с аналогичной проблемой. Похоже, у разработчиков нет внятной идеологии работы OnCalculate - сколько раз и в каких случаях надо использовать полный перерасчет индикаторов и надо ли вообще его делать, да еще ошибки реализации.
Но, по ощущениям, не все так драматично.
Вот пример простого индикатораРисуется одна горизонтальная линия. Контролирую вызов функции Init, приход первой свечки и приход предпоследней свечки.
В двух местах выдаю выбранные из Settings имя индикатора и толщину линии индикатора.
Протокол работы.
 
Индикатор нормально добавился, получил все свечки и успешно выдал в протокол имя индикатора и толщину линии из функции Init и при получении первой свечки (строки 1-7 ), отрисовал прямую..
Затем я зашел в настройки индикатора и ничего не меняя выдал OK.
Пошел перерасчет индикатора, при получении первой свечки имя индикатора было успешно выдано, а на доступе к толщине линии - облом. Оставшиеся свечки обработались нормально. Строки 8-11.
Затем пошел второй перерасчет индикатора (сейчас это, как бы, норма) с тем же обломом. Строки 12-15.
То, что индикатор смог один раз отработать нормально (ведь, могут же!), дает мне надежду, что разработчики возводят на себя поклеп. Нужно их пояснение.
 

У меня рука "тяжелая". Индикаторы только свои.
Если будет время, попробую воссоздать ситуацию на моделях своих индикаторов.  

В QUIK есть неявные (по факту) ограничения на количество индикаторов в одном окне. Проявляются по-разному.
Например. Если в основном окне индикаторов больше двух десятков, то замена инструмента начинает срабатывать лишь при существенном уменьшении числа индикаторов, сейчас не помню, то ли до 7, до ли до 17.
Никакой реакции, никакой диагностики. Поснимаю "лишние" - замена инструмента заработает, потом возвращаю снятые обратно.  

Это не мое "злоупотребление".
Я про количество индикаторов (типа несколько десятков) в одном окне.
И про график длиной в 5000 свечек.  

В натуральном виде - исключено, но, если будет время, попробую упростить его предельно (пока ошибка будет сохраняться).
Про мои "злоупотребления" можете что-то сказать?  

Откуда такая уверенность? Давайте временно оставим брокера в покое. Я обещал посмотреть оставшиеся несколько тысяч ошибок. Вот, выделил еще одну.
Упростил одну диаграмму, убирал индикаторы, пока эффект еще оставался.
Для сравнения - версия 7.5, как бы, исходное состояние.
   
Инструмент всем знакомый, совсем свежий - RIH7, М1.. Кстати, при замене инструмента заголовок диаграммы автоматом не меняется, правил руками (или там вообще другой смысл какой-то заложен).
Нет сомнения, что брокер подал много данных, может, дыры и есть, но на глаз не очень заметно. Как бы, на сервере брокера график не поврежден.
И для версии 7.6. Картинка снята почти сразу после первой.

Данные обрезаны радикально. Это даже не дыра.
Мой индикатор - один и тот же, но ему уже чинятся какие-то помехи.
По тем параметрам, которые в нем есть, он должен выдать просто прямую линию, Одно и то же значение для всех подаваемых свечек.
Пусть Вас не смущает, что на моем индикаторе другой инструмент - RIZ6.
Пару дней назад он был и вверху, с теми же ошибками, нет возможности хранить все сочетания версий, индикаторов, инструментов, параметров,...

Чем "злоупотребляю" я, признаюсь сразу.
Большим количеством индикаторов, их было много, оставил единственный. Если его убрать, то данных останется столько же мало, но дыра исчезнет.
Возможно, где-то в документации или на просторах Интернета и можно найти ограничения на количество индикаторов, но за руку меня никто не хватал.
Еще могу несколько суток не обращать внимания на QUIK, количество свечек может дорасти тысяч до 5. Обязан ли я каждый день перезагружать QUIK - не знаю, QUIK не требовал.

Предыстория у этой диаграммы очень богатая, несколько лет жила. Где была та развилка, с которой начался такой финал, и была ли она вообще - не ведаю.

Дополнительно могу сообщить, что чем-то похожая ситуация была с графиком RTSI, недели.
Он переставал обновляться с правого конца в версии 6.17. Приспособился - создавал новую диаграмму, добавлял индикаторы со старыми параметрами, движение возобновлялось, как-то перебивался.      

P.S. Извините, еще частный вопрос. В версии 6.17 при добавлении нового индикатора давалась возможность до его установки поменять параметры.
В 7.5 он ставится с какими-то параметрами по умолчанию, потом приходится его искать и задавать нужные параметры. Это "бага" или "фича"?
Мои индикаторы необычайно ресурсоемки по процессору и проходить лишнюю инициализацию слишком накладно.
Ведь сейчас и так при добавлении или переопределении индикатора пересчитываются вообще все видимые индикаторы.

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