Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Столкнулся с багом, когда CopyTicksRange возвращает все запрошенные тики верно, но при этом LastError == ERR_HISTORY_TIMEOUT(4403).
Это не баг, это фича. Тоже самое выдаёт CopyTicks, иногда. Пока не придумал, как эту "фичу" использовать
в описании функции CopyTicksRange :
ERR_HISTORY_TIMEOUT – время ожидание синхронизации тиков вышло, функция отдала всё что было.
Хотелось бы, конечно, чтобы разработчики пояснили, что означает эта ошибка, при условии что тик по функции CopyTicks получен. Как эту ошибку обрабатывать. пс: вызываю в индикаторе
Прошу сообщить, какие данные нужно предоставить, чтобы скорее решить эту проблему?
Тики не копирует, выдавая ошибку.
Константа
Значение
Описание
ERR_HISTORY_SMALL_BUFFER
4407
Принимающий массив слишком мал чтобы вместить все запрошенные данные
Невозможно нормально работать с такими сюрпризами!
Через GUI (CTRL+U) тики берутся без проблем.
Строка для поиска: Oshibka 007.Прошу сообщить, какие данные нужно предоставить, чтобы скорее решить эту проблему?
Тики не копирует, выдавая ошибку.
Константа
Значение
Описание
ERR_HISTORY_SMALL_BUFFER
4407
Принимающий массив слишком мал чтобы вместить все запрошенные данные
Проверили локально у себя по разному - пока не воспроизводится. Нужны подробности:
1. Какая версия терминала?
2. С каким сервером вы работаете?
3. На каком символе вызывается скрипт?
4. Если вызывать не с COPY_TICKS_INFO, а COPY_TICKS_ALL то ошибка ERR_HISTORY_SMALL_BUFFER также взводится?
Спасибо!
Проверили локально у себя по разному - пока не воспроизводится. Нужны подробности:
1. Какая версия терминала?
2. С каким сервером вы работаете?
3. На каком символе вызывается скрипт?
4. Если вызывать не с COPY_TICKS_INFO, а COPY_TICKS_ALL то ошибка ERR_HISTORY_SMALL_BUFFER также взводится?
Спасибо!
ЗЫ В прицепе кастомный. Создать символ из json, импортировать тики, запустить скрипт на чарте этого символа. Просьба написать, воспроизвели или нет.
Просьба написать, воспроизвели или нет.
Да, на 2380 воспроизвелось.
Спасибо большое! Разбираемся.
ЗЫ В прицепе кастомный. Создать символ из json, импортировать тики, запустить скрипт на чарте этого символа. Просьба написать, воспроизвели или нет.
Еще раз спасибо.
Да, в 2380 случайно занесли проблему и потом быстро её исправили. Но в билд 2380 это успело попасть.
К сожалению с того момента новых билдов где все исправлено на MetaQuotes-Demo пока не было.
Вы можете либо откатится на любой предыдущий билд либо дождаться очередного билда на MetaQuotes-Demo.Вы можете либо откатится на любой предыдущий билд либо дождаться очередного билда на MetaQuotes-Demo.
Спасибо, для реала пока предыдущий билд. В 2380 много сделали...
MT5 последняя релизная сборка 2361. В аттаче кастомный символ. Создать символ из json, импортировать тики, запустить тест советника на чарте этого символа.
Советник
Параметры теста
1. Счёт неттинг.
1.1. При указанных датах вывод похож на правду: 2000 0 2000 0.
1.2. При смене дат на 07.04.2020-08.04.2020 вывод становится странным: -1 4004 1 0.
Во-первых, почему появляется ошибка в первом случае? Во-вторых, почему второй случай берёт только 1 тик? Дата запроса тиков не менялась.
2. Счёт хедж.
2.1. При указанных датах вывод становится странным: 2000 0 1 0.
Почему второй случай берёт только 1 тик? Дата запроса тиков не менялась.
2.2. При смене дат на 07.04.2020-08.04.2020 вывод остановится странным, но таким же: 2000 0 1 0.
Отсюда вопросы: почему CopyTicks с фиксированными параметрами зависит не только от дат тестирования, но и от типа счёта? Или я что-то не понимаю и делаю не так?
Это сильно затрудняет работу, просьба по возможности поправить. Удалось воспроизвести? Что-то ещё нужно от меня для повторения? Спасибо.
Отсюда вопросы: почему CopyTicks с фиксированными параметрами зависит не только от дат тестирования, но и от типа счёта? Или я что-то не понимаю и делаю не так?
Зависимость от типа счета - примерно можно представить причины. Не скажу, что это правильно. Биржевые символы с last-историей - там нужно хорошо один раз подумать разработчикам, что с ними делать на хедже и т.д.
Сам CopyTicks не использую в Тестере. Первые сутки не принципиальны. Если очень нужны четкие торговые сигналы, то не торгуйте первые сутки.
MT5 последняя релизная сборка 2361. В аттаче кастомный символ. Создать символ из json, импортировать тики, запустить тест советника на чарте этого символа.
Советник
Параметры теста
1. Счёт неттинг.
1.1. При указанных датах вывод похож на правду: 2000 0 2000 0.
1.2. При смене дат на 07.04.2020-08.04.2020 вывод становится странным: -1 4004 1 0.
Во-первых, почему появляется ошибка в первом случае? Во-вторых, почему второй случай берёт только 1 тик? Дата запроса тиков не менялась.
2. Счёт хедж.
2.1. При указанных датах вывод становится странным: 2000 0 1 0.
Почему второй случай берёт только 1 тик? Дата запроса тиков не менялась.
2.2. При смене дат на 07.04.2020-08.04.2020 вывод остановится странным, но таким же: 2000 0 1 0.
Отсюда вопросы: почему CopyTicks с фиксированными параметрами зависит не только от дат тестирования, но и от типа счёта? Или я что-то не понимаю и делаю не так?
Это сильно затрудняет работу, просьба по возможности поправить. Удалось воспроизвести? Что-то ещё нужно от меня для повторения? Спасибо.
Самый первый запуск. Смотрим логи тестера
Тестер синхронизировал тики всего за один день, за 8 апреля. То есть, до 8 апреля тиков нет.
В начале мы получили ошибку 4004 (не хватило памяти для запрошенных тиков). Это - неправильное сообщение, будем разбираться. Похоже из-за того, что запрос с параметрами по умолчанию на границе существующих тиков
Следующий запрос совершенно справдливо вам выдал 1 тик. Потому что с 2020.04.06 00:00:00 по текущий тестерный момент, когда пришёл первый тик, существует только один этот самый тик.
Немножко скорректируем советника
и видим, что со второго тика, тики стали забираться. В обоих случаях - 2 тика
То есть, предположение про ошибку запроса на границе существования тиков оказалось верным.
Поменяем дату начала на 7 апреля
Всё то же самое. за исключением того, что тики у нас синхронизированы уже за 2 дня - в тестерной базе лежат тики за 7 и 8 апреля.
Обратно ставим начальную дату на 8 апреля. И видим ожидаемый вывод
Потому что тиков у тестера стало больше, чем в самый первый запуск. И хеджинг с неттингом тут ни при чём