Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы думаете, я не проверяю. Размер лота проверяется в отдельной функции
Лимиты тут не нужны, т.к. Stop Loss и Take Profit равны нулю при открытии сделки. RefreshRates() обновляет данные при расчёте лота. Проверки связи и т.д. конечно нет перед каждым входом, но дело то не в этом во всём. Если бы OrderSend отправила запрос, была бы конкретная ошибка: 130, 131 и т.д. Но у меня то
Вообще не пытается отправить приказ на открытие. Даже в последнем тесте, когда из функции OnInit() я выставляю контрольную отложку
Возможно. Но я уже перепроверил всё. Не знаю куда дальше копать.
В функции нормализации лота вы округляете лот после проверки его на макс/мин значения.
Ну да, использую
MathRound();
P.S. Думаю, надо всё таки копать от входных параметров, т.к. бывает что проверку проходит. Делать проверку "на дурака" каждый параметр.Я уже не говорю о логах теста валидатора. Но хоть параметры на которых НЕ проходит проверку может быть возможно отправлять. Не за что зацепиться вообще, чтобы исправить код. Я понимаю что вариативность выбора параметров тестирования может быть бесконечна. Переменную типа int можно поставить равной как +50000, так и - 45000. Но некоторые входные параметры я не могу тупо ограничить тупо каким то диапазоном значений, для разных инструментов он будет различаться.
Вам нужно сделать так, чтобы торговый лот в любом случае был допустимым. Я не зря вам указал на изменение лота у вас в коде уже после его проверки на допустимый диапазон его размеров.
И именно проверку на совершенно дурацкие входные параметры нужно обязательно делать.
Так с лотом то как раз проблем нет. Он проверяется на макс/мин. До округления он делится на step, затем целое округлённое число вновь умножается на step. Получаем совершенно корректный лот.
_lot(0.568)/step(0.01)=56.8
MathRound(56.8)=57
57*step(0.01)=0.57
Далее проверяется на то, хватит ли свободной маржи для открытия. На лот валидатор вообще не ругается. Он не видит торговых функций, видимо из-за ввода некорректных входных параметров. Советник просто не делает сделок вообще при определённой их комбинации! У меня же не мартин без условий, и не сеточник который открывается на каждой свече. Как объяснить валидатору, что советник по логике не делает сделок при неких параметрах.
Так с лотом то как раз проблем нет. Он проверяется на макс/мин. До округления он делится на step, затем целое округлённое число вновь умножается на step. Получаем совершенно корректный лот.
_lot(0.568)/step(0.01)=56.8
MathRound(56.8)=57
57*step(0.01)=0.57
Далее проверяется на то, хватит ли свободной маржи для открытия. На лот валидатор вообще не ругается. Он не видит торговых функций, видимо из-за ввода некорректных входных параметров. Советник просто не делает сделок вообще при определённой их комбинации! У меня же не мартин без условий, и не сеточник который открывается на каждой свече. Как объяснить валидатору, что советник по логике не делает сделок при неких параметрах.
Не объяснять, а сделать так, чтобы советник корректировал неправильные входные параметры. Желательно с сообщением в журнал об их недопустимом значении и корректировке к допустимому.
И, если по каким-либо причинам вы хотите возложить в реале ответственность на пользователя за ввод некорректных параметров, то ему нужно сообщать при некорректные параметры.
Но для тестера нужно их ещё и скорректировать - чтобы советник торговал.
Так как их корректировать, если для EURUSD будут одни параметры, а для Золота, например, совсем другие. Сейчас по умолчанию стоят более менее сносные для основных пар, но для золота они вообще не прокатят. Сделок там не будет. Параметры для того и существуют (как я понимаю) чтобы адаптировать их под каждый инструмент. Если бы всё было так просто, я бы зашил все параметры в советник, и не выносил бы ничего во внешние.
Ещё один баг валидатора, что он совершенно не видит других таймфреймов. Я его обошёл, но в ущерб алгоритму в какой то степени. В советнике ряд индикаторов берут данные с других ТФ, с недельных, D1, H4, и т.д. до M1. Но данные приходят нулевые, как я выяснил путём многочисленных экспериментов. И с этим ничего сделать нельзя, только обходить. Почему советник приходится подкраивать под валидатор в ущерб алгоритму? Не наоборот ли должно происходить, валидатор надо адаптировать под тесты. А то пройти проверку абсолютно работающего советника превращается в какую то каторгу!
Так как их корректировать, если для EURUSD будут одни параметры, а для Золота, например, совсем другие. Сейчас по умолчанию стоят более менее сносные для основных пар, но для золота они вообще не прокатят. Сделок там не будет. Параметры для того и существуют (как я понимаю) чтобы адаптировать их под каждый инструмент. Если бы всё было так просто, я бы зашил все параметры в советник, и не выносил бы ничего во внешние.
вы-же ставили ровно перед OrderSend деление на 0 - и такая ошибка была. Значит до OrderSend оно доходит, но не открывает. То есть лоты/маржа/лимиты/цена, что-то из них неучтено
Максим, если что то из вами перечисленного неучтено, валидатор выдаёт совершенно определенную ошибку: 130, 131, 134, 145 и т.д. Здесь не тот случай!
P.S. Поверьте, я за 4 дня дня уже больше сотни раз отправлял на проверку, и испробовал массу вариантов.
Да, до деления на 0 (следовательно до OrderSend) доходит сразу же. И выдаёт ошибку.
Но если я отправляю на проверку советник без деления на 0 в коде, он каким то волшебным образом выставляет параметры при которых сделок не открывается совсем за указанный период, и возвращает ошибку. Это моя версия происходящего, но видимо она недалека от истины.