Работа блока обработки ошибок для реального времени
Для отладки. Что бы знать причину проблемы. Что бы потом разобраться почему ордер на закрылся.
Остальное от эксперта зависит, будет ли он повторять закрытие или бросит ордер.
Для отладки. Что бы знать причину проблемы. Что бы потом разобраться почему ордер на закрылся.
Остальное от эксперта зависит, будет ли он повторять закрытие или бросит ордер.
Да, делаем эксперт, работающий по таймеру, чтобы не зависеть от тиков и пусть он каждые N-ms проверят позиции на условие закрытия.
15-сек задержки обычно могут быть лишь на сильных новостях, ночное время тут ни при чем.
Ок, тогда берем эксперт на таймере, для каждого из условий закрытия открытия модификации и прочей хрени ставим таймер на проверку.
что получится если
1) функция таймер работает каждые 5 сек а проверка 15 сек
2) если робот на тиках и стят проверки по 15 сек
3) как будет работать бот на таймере если во время проверок оборвет связь.Ок, тогда берем эксперт на таймере, для каждого из условий закрытия открытия модификации и прочей хрени ставим таймер на проверку.
что получится если
1) функция таймер работает каждые 5 сек а проверка 15 сек
2) если робот на тиках и стят проверки по 15 сек
3) как будет работать бот на таймере если во время проверок оборвет связь.1) Так и получится. Что тут еще может получиться?
2) Все нормально будет. Если во время работы функции по таймеру придет тик, то по завершению работы оп таймеру произойдет работа по тику. Если при работе по тику придет время таймера, то по завершению работы по тику будет работа по таймеру.
3) Ошибки выполнения рыночных действия будут. Если таймер использовать, то надо бы проверять наличие связи.
1) Так и получится. Что тут еще может получиться?
2) Все нормально будет. Если во время работы функции по таймеру придет тик, то по завершению работы оп таймеру произойдет работа по тику. Если при работе по тику придет время таймера, то по завершению работы по тику будет работа по таймеру.
3) Ошибки выполнения рыночных действия будут. Если таймер использовать, то надо бы проверять наличие связи.
вот мне пришлось покопаться в нескольких десятках кодов и вот что нашел
https://www.mql5.com/ru/code/14303
обычный стандартный вариант который спамит в журнал, и все.
есть мысль как сделать его реально рабочим?
- голосов: 13
- 2015.12.23
- Algofxsolution
- www.mql5.com
вот мне пришлось покопаться в нескольких десятках кодов и вот что нашел
https://www.mql5.com/ru/code/14303
обычный стандартный вариант который спамит в журнал, и все.
есть мысль как сделать его реально рабочим?
Он нормальный. Когда время закрытия наступает, он будет на каждом тике попытки делать, пока все не закроет. Но и когда закроет будет продолжать.
Он нормальный. Когда время закрытия наступает, он будет на каждом тике попытки делать, пока все не закроет. Но и когда закроет будет продолжать.
я так понял хватит этого блока и ResetLastError в начале каждого тика?
или как вариант сделать обработку критических а остальные просто забить через GetLastError
Ок, тогда берем эксперт на таймере, для каждого из условий закрытия открытия модификации и прочей хрени ставим таймер на проверку.
что получится если
1) функция таймер работает каждые 5 сек а проверка 15 сек
2) если робот на тиках и стят проверки по 15 сек
3) как будет работать бот на таймере если во время проверок оборвет связь.1. Пока не закончится проверка, то есть не выйдем из OnTimer, советник не будет реагировать на новые тики и вызовы таймера
3. Работа таймера от наличия связи не зависит, просто надо ее проверять. Dmitry Fedoseev все подробно расписал.
я так понял хватит этого блока и ResetLastError в начале каждого тика?
или как вариант сделать обработку критических а остальные просто забить через GetLastError
Можно и без него, это все равно только информационный блок, но не обработка ошибок.
Обработка ошибок, это когда проверяешь результаты работы функций которые могут не успешно выполниться и принимаешь соответствующее решение: может быть прервать работу функции OnTick() до следующего тика, может быть продолжить. Допустим в процессе работы советника, в соответствии с его алгоритмом работы, появилась необходимость закрытия всех позиций и удаления всех ордеров. Значит советник должен делать попытки закрытия пока не закроет и не удалить все, только после этого продолжать с другими действиями.
Все функции, которые могут не выполниться и так возвращают true/false - вот на это надо реагировать. А номер ошибки, это последнее дело, только для информации. Кончено могут быть случаи когда и и с номером ошибки надо разбираться, но это редчайший случай. Один случай только был - копировщик работающий в цикле. Если в пятницу вечером случалась ошибка с определенным номером, то надо было делать перерыв до понедельника. Но все это только для того, что бы лог файл не раздувался.
Если возникают ошибки параметров (лот, стоплосс), торговый запрос не пройдет дальше терминала. Поэтому с такими ошибками только проблема переполнения логов. Если же ошибки другого типа, то о них можно узнать только выполнив запрос. Т.е. их никак не обработать. Значит, если советник не выполнил свой алгоритм (в процессе какого-то действия произошла ошибка), то долбить. Разве что паузы делать между попытками.
Если открытие позиции, то делать попытки в течение одного бара или штук пять попыток с паузами - зависит от стратегии. Если сеточная стратегия, то надо в каждой ситуаци разбираться, на каждой стадии создания сетки определяться, повторять ли попытку. Вот поэтому сеточники являются сложными советниками (вопреки мнению заказчиков). Если закрытие, всех позиций - долбить пока все не закроется. Если закрытие одной позиции - можно делать попытки в течение одного бара, даже если не закроется, потом все равно еще будут сигналы к закрытию (по крайней мере советник не застрянет). На ошибки трейлинга можно не реагировать, он на каждом тике работает.
Можно и без него, это все равно только информационный блок, но не обработка ошибок.
У меня будет стоять сеточник-полуавтомат. А в чем их сложность если отличие от других советников только в шаге следующего ордера?
и благодарю за исчерпывающий ответ по данному вопросу.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Давайте представим себе робота, дающего 100% профитных сделок
из - за этого можно увеличить лот до 20% от депо.
И все бы хорошо, но к примеру повар не очень настроен крыть ордер в 00.00 или 12.00 или с 2 до 5 утра где ожидание закрытия может растягиваться секунд на 15, причем ордер не факт что закроется
Смотрим стандартный блок - там написано что - то вроде "выводит в журнал сообщение об ошибке"
Ну вывели мы сообщение и что? У компьютера никого не будет пару недель.
Ордер не закрылся, счет из - за большого лота слит.
Так в чем его смысл? Для журнала хватит и стандартного блока.