
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я так и делаю. Разница лишь в том, что у меня не стоит проблемы свой-чужой. Я все ордера отбираю строго по номерам тикетов. Каждый советник работает только с ордерами которые он сам создал, и никакими другими. Разумеется проверяю Свободен ли поток, и код ошибки. Но как оказалось сегодня утром этого мало. Сама ситуация, когда терминал вдруг повис, а советники делают непонятно что, она как-то выходит за рамки здравого смысла. Советники работали так, как будто несколько переменных потеряли свои значения. Другими словами я понимал что они делают, но ужас в том что делать они этого были не должны. Учитывая что работают они очень давно, предположить что в коде какая-то ошибка я не могу. Если предположить, что из-за отключения интернета, некоторые переменные могут терять свои значения, то какой смысл в программировании. Это может означать что весь этот терминал один сплошной глюк.
Видимо придется самому вынимать провод, имитируя отключение интернета, смотреть что при этом происходит, и что-то выдумывать.
Думается, проблему поможет решить правильная структура программного комплекса, реализующего торговлю. Каждому его компоненту надо ставить естественную для него задачу. Без MQL компонентов не обойтись, они - единственные, кто может:
- дать оперативную информацию о тиках, торговых условиях, состоянии счета;
- исполнить торговый приказ.
Этим и надо ограничить их функции. Не надо мучить их историей, оценками ситуации, принятием решений - пусть это будут органы чувств комплекса и его исполнительные органы. То есть, например: один скрипт для сбора тиков, один советник для исполнения торговых приказов. Связь с ними через файлы, сигнальные или с данными. Ядро - внешняя программа, на удобном для Вас языке. Она и торгует, в смысле командует советнику, когда на сервер MT нужно отправить какой-нибудь запрос (торговый приказ). Есть интернет, нет интернета, от этого изменяется лишь поток тиков и ответы сервера на запросы. Анализировать их удобнее в ядре, которое само диагностирует и пропажу связи с конкретным ДЦ (счетом) при наличии Интернет, и прекращение котирования какого-либо одного инструмента, и пропажу Интернет на торгующем компьютере. Собирающему тики скрипту все равно, даже запущено ли ядро, гонит пришедшие тики в файл и все. Исполнитель торговых приказов знает одномоментно только один приказ и очень короткое время, в течение нескольких секунд, пока не пришел ответ от сервера MT, передает ответ ядру и все. Никакой истории ему знать не надо. Ядро же работает без потребности в Интернет, все анализирует, в том числе, что терминал не запущен или сборщик с исполнителем не работают, помнит что надо в своей оперативной памяти или даже на диске. Ядро валится только при отключении электропитания на время, превосходящее возможности бесперебойника.
Я делаю это так
Это хорошая идея если у вас работает один советник. Если хотя бы два, то про функцию OrderTotal() можно забыть. У первого советника ордер закрылся по стопу, второй поставил отложенный ордер - количество по OrderTotal() не поменялось, первый советник будет думать, что ничего не произошло. Каждый бар проверять нельзя. Надо именно каждый тик. У меня если сработал хотя бы один тейк, все остальные ордера должны быть сразу удалены. иначе откроется что-нибудь не то.
Думается, проблему поможет решить правильная структура программного комплекса, реализующего торговлю. Каждому его компоненту надо ставить естественную для него задачу.
Это называется распределение потоков (только не тех потоков, которые описаны в mql4)... кстати не плохая идея.
Это называется распределение потоков (только не тех потоков, которые описаны в mql4)... кстати не плохая идея.
Хороший вопрос - а что будет? Вот только я не могу придумать, в какой такой ситуации мне может потребоваться закрыть или перезагрузить терминал.
Одна ситуация уже произошла и подтолкнула на создание этой ветки. Заглючить может и другая программа. Ну, допустим что на этом компе работает исключительно МТ. Так и МТ периодически обновляют и отключают старые версии.
Вторая, авария в электросетях.
Третья, комп не бессмертен.
Четвёртая, обновление ОС приводит к перезагрузке компа...
Думаю напрягать мозг в воспоминаниях ещё нескольких причин не имеет смысла...
Это хорошая идея если у вас работает один советник. Если хотя бы два, то про функцию OrderTotal() можно забыть. У первого советника ордер закрылся по стопу, второй поставил отложенный ордер - количество по OrderTotal() не поменялось, первый советник будет думать, что ничего не произошло. Каждый бар проверять нельзя. Надо именно каждый тик. У меня если сработал хотя бы один тейк, все остальные ордера должны быть сразу удалены. иначе откроется что-нибудь не то.
Ошибочное мнение. Ну пусть один советник изменил количество открытых ордеров... и что? Второй просто пересчитал свои ордера и продолжает работать.
Никому ничего доказывать не буду, но я тоже использую массив для хранения тикетов "своих" ордеров. С недавних пор стал использовать массив структур где кроме тикетов хранятся другие параметры ордера (не все).
Ошибочное мнение. Ну пусть один советник изменил количество открытых ордеров... и что? Второй просто пересчитал свои ордера и продолжает работать.
Они одновременно могут изменить количество ордеров внутри себя так, что общее количество не изменится.
Предлагаю резюмировать... Конечно каждый принимает решение сам, кратко напишу что я решил для себя.
Проанализировав ситуацию, которая произошла с моими советниками, я пришел к выводу, что дело не в советниках и не в терминале. Сложились два обстоятельства - после включения интернета терминал стал обновлять данные, а в этот момент советники стал забрасывать сервер распоряжениями на изменение и выставление ордеров. Случился какой-то перегруз и терминал завис, безконтрольно выставляя тучи ордеров без остановки. Кстати такая ситуация описывается как возможная в учебнике по mql5 (... кто-то мне здесь ссылку давал...).
Соответственно, даже если советники были бы написаны таким образом, что могли запускаться с любого места после перезагрузки терминала собирая информацию о своих ордерах, ситуацию это бы не исправило. Они, советники, просто заблудились бы в неправильно выставленых ордерах и стали бы работать не правильно. Соответственно и в файл может сохраниться всякая ерунда.
Следовательно правильным решением (сугубо мое мнение) является onTimer() с регулярной проверкой состояния связи. Если связи нет, советник долден уснуть и проснуться через какое-то время (наверное не меньше минуты или даже двух...) после того как связь восстановилась. За это время терминал должен дозагрузить все, что он не получал пока связи не было, и выйти на нормальный режим работы.
Наверное 100% гарантии не будет никогда, но риск потерь это должно минимизировать.
Всем спасибо, удачи и денег побольше.
Для тех кому интересно...
Сегодня утром имитировал отключение интернета. Дописал в программу отправку советника в сон и 40-ка секундное пробуждение после того, как связь снова возобновиться. Получилось даже интереснее. У меня вдруг не сразу включился модем и за это время нарисовался ГЭП. Через 40 секунд проснулся советник и отработал все как надо.