글쎄, 나는 확실히 당신을 위해 문제가 해결되기 시작했다는 것을 기쁘게 생각합니다. 그러나 어떤 이유로 당신은 내 메시지를 눈치 채지 못했습니다. 내가 같은 것을 약간 다른 말로 말하고 즉시 단점에 대해 말했습니다. 파일을 닫을 때 어디에서 발생하는지 즉시 보지 못했습니다. :)
3점 답변을 작성하셨습니다. 당신은 첫 번째 항목에서 실수를 했고(내 항목은 매우 정확합니다) 두 번째 항목에서도 실수했습니다(비록 이것은 이 메시지에 의해 평준화되었지만 실수로 인해). 그러한 그림을 배경으로 나는 경험이 풍부한 중재자로부터 답변을 받는 것을 선호했습니다.
고문이 있습니다. 테스터에서는 아무 불만 없이 잘 작동합니다. 그러나 데모에서 실행하고 고문은 일부 주문에 대해 중지를 설정할 수 없습니다. 때때로 표시되지 않는 특정 오류가 있습니다. 나는 그것을 스스로 찾기 위해 필사적이었습니다. 당신의 도움을 바랍니다. 동시에 테스터에는 불만이 없기 때문에 다른 모든 측면에서 고문이 완벽하게 작동하지만 문제는 정지가 항상 설정되지 않는다는 것입니다. 다른 계정의 다른 브로커에 오류가 나타납니다. 다음은 거래 작업을 담당하는 코드의 일부입니다.
string Error( int er) {
switch (er) {
case0 : return ( "Нет ошибки" );
case1 : return ( "Нет ошибки, но результат неизвестен" );
case2 : return ( "Общая ошибка(сбой системы, глюк, и т.п.)" );
case3 : return ( "Неправильные параметры" );
case4 : return ( "Торговый сервер занят" );
case6 : return ( "Нет связи с торговым сервером" );
case7 : return ( "Недостаточно прав" );
case8 : return ( "Слишком частые запросы" );
case9 : return ( "Недопустимая операция нарушающая функционирование сервера" );
case128 : return ( "Истек срок ожидания совершения сделки" );
case129 : return ( "Неправильная цена" );
case130 : return ( "Неправильные стопы" );
case131 : return ( "Неправильный объем" );
case133 : return ( "Торговля запрещена" );
case134 : return ( "Недостаточно денег для совершения операции" );
case135 : return ( "Цена изменилась" );
case137 : return ( "Брокер занят" );
case138 : return ( "Новые цены" );
case139 : return ( "Ордер заблокирован и уже обрабатывается" );
case140 : return ( "Разрешена только покупка" );
case141 : return ( "Слишком много запросов" );
case145 : return ( "Модификация запрещена, так как ордер слишком близок к рынку" );
case146 : return ( "Подсистема торговли занята" );
case147 : return ( "Использование даты истечения ордера запрещено брокером" );
case148 : return ( "Количество открытых и отложенных ордеров достигло предела, установленного брокером" );
case149 : return ( "Попытка открыть противоположную позицию к уже существующей в случае, если хеджирование запрещено." );
default : return ( "Неизвестная ошибка " + DoubleToStr (er, 0 ));
}
}
따라서 Advisor가 중지 설정에 실패하면 오류에 대한 정보와 그가 수정하려고 시도한 주문의 매개변수를 표시하는 메시지가 나타납니다. 그가 나를 위해 쓰는 것은 정말 미스터리입니다. 아래 사진을 보시면 알겠지만 계속해서 볼륨이 틀려진다고 씁니다. 기이한. 수정하기 전에 모든 주문 매개변수가 올바르게 계산된다는 점을 추가하겠습니다. 이는 메시지에서 확인할 수 있습니다. 게다가, 그렇지 않으면 완전히 다른 오류가 발생합니다. 프로그램은 데모에 있는 것보다 더 높은 스프레드로 테스트되었습니다.
고문이 있습니다. 테스터에서는 아무 불만 없이 잘 작동합니다. 그러나 데모에서 실행하고 고문은 일부 주문에 대해 중지를 설정할 수 없습니다. 때때로 표시되지 않는 특정 오류가 있습니다. 나는 그것을 스스로 찾기 위해 필사적이었습니다. 당신의 도움을 바랍니다. 동시에 테스터에는 불만이 없기 때문에 다른 모든 측면에서 고문이 완벽하게 작동하지만 문제는 정지가 항상 설정되지 않는다는 것입니다. 다른 계정의 다른 브로커에 오류가 나타납니다. 다음은 거래 작업을 담당하는 코드의 일부입니다.
다음은 Error(int er) 함수에 대한 코드입니다.
따라서 Advisor가 중지 설정에 실패하면 오류에 대한 정보와 그가 수정하려고 시도한 주문의 매개변수를 표시하는 메시지가 나타납니다. 그가 나를 위해 쓰는 것은 정말 미스터리입니다. 아래 사진을 보시면 알겠지만 계속해서 볼륨이 틀려진다고 씁니다. 기이한. 수정하기 전에 모든 주문 매개변수가 올바르게 계산된다는 점을 추가하겠습니다. 이는 메시지에서 확인할 수 있습니다. 게다가, 그렇지 않으면 완전히 다른 오류가 발생합니다. 프로그램은 데모에 있는 것보다 더 높은 스프레드로 테스트되었습니다.
전역 변수의 값에 주의하십시오. ord_ticket이 전역 변수라고 가정할 수 있습니다. 즉, 이전 값을 저장할 수 있습니다. 그리고 GetLastError()를 호출하여 오류를 포착하기 전에 코드 시작 부분에서 호출하여 이전 표시를 재설정해야 합니다.
TarasBY : 전역 변수의 값에 주의하십시오. ord_ticket이 전역 변수라고 가정할 수 있습니다. 즉, 이전 값을 저장할 수 있습니다. 그리고 GetLastError()를 호출하여 오류를 포착하기 전에 코드 시작 부분에서 호출하여 이전 표시를 재설정해야 합니다.
ord_ticket은 로컬로 선언됩니다. 그런 다음 첫 번째 줄에서 전역 수준으로 선언하더라도
그 의미가 바뀌어야 합니다. 작업이 성공하면 주문 번호이고 그렇지 않으면 -1입니다. 따라서 주문이 열리지 않으면 중지 설정 블록에 들어 가지 않습니다.
또한 OrderSend() 함수는 항상 마지막 오류의 값을 변경하므로(문서 및 논리에 따라) 이 경우 이전 표시를 재설정할 필요가 없으며 단순한 시간 손실로 이어질 것입니다. 즉, 131번 에러는 설정 정지 블록 진입 후 에러 메시지가 표시되기 전에 나타납니다. 정류장이 실제로 설정되지 않았기 때문에 OrderModify() 함수는 호출된 마지막 함수이며 이전 함수와 마찬가지로 항상 마지막 오류 값을 변경합니다. 나만 이해가 안되는데 왜 131??? 어디에? 다시 한번 테스터에는 문제가 없음을 말씀드립니다.
브로커가 똑똑하다는 생각은 터미널을 보내는 서버이고 차례로 오류 번호를 어드바이저에게 보내는 서버이기 때문입니다. 그런 일은 한 명의 고문의 명령으로 만 발생하기 때문에 빨리 포기했습니다. 병렬로 일하는 나머지 고문은 작업에 오류가 없습니다.
ord_ticket은 로컬로 선언됩니다. 그런 다음 첫 번째 줄에서 전역 수준으로 선언하더라도
그 의미가 바뀌어야 합니다. 작업이 성공하면 주문 번호이고 그렇지 않으면 -1입니다. 따라서 주문이 열리지 않으면 중지 설정 블록에 들어 가지 않습니다.
또한 OrderSend() 함수는 항상 마지막 오류의 값을 변경하므로(문서 및 논리에 따라) 이 경우 이전 표시를 재설정할 필요가 없으며 단순한 시간 손실로 이어질 것입니다. 즉, 131번 에러는 설정 정지 블록 진입 후 에러 메시지가 표시되기 전에 나타납니다. 정류장이 실제로 설정되지 않았기 때문에 OrderModify() 함수는 호출된 마지막 함수이며 이전 함수와 마찬가지로 항상 마지막 오류 값을 변경합니다. 나만 이해가 안가는데 왜 131??? 어디에? 다시 한번 테스터에는 문제가 없음을 말씀드립니다.
브로커가 똑똑하다는 생각은 터미널을 보내는 서버이고 차례로 오류 번호를 어드바이저에게 보내는 서버이기 때문입니다. 그런 일은 한 명의 고문의 명령으로 만 발생하기 때문에 빨리 포기했습니다. 병렬로 일하는 나머지 고문은 작업에 오류가 없습니다.
추가하겠습니다. 병렬 EA에는 정지 설정을 담당하는 동일한 코드가 있습니다. 따라서 이 Expert Advisor는 주문에 대해 정류장이 설정되지 않은 상황이 없었습니다.
위의 매개변수 계산에 오류가 있는 것으로 나타났지만 하나 이상의 매개변수가 정확하지 않으면 다른 오류가 표시되어야 합니다. 예를 들어 잘 알려진 130
ord_ticket은 로컬로 선언됩니다. 그런 다음 첫 번째 줄에서 전역 수준으로 선언하더라도
그 의미가 바뀌어야 합니다. 작업이 성공하면 주문 번호이고 그렇지 않으면 -1입니다. 따라서 주문이 열리지 않으면 중지 설정 블록에 들어 가지 않습니다.
또한 OrderSend() 함수는 항상 마지막 오류의 값을 변경하므로(문서 및 논리에 따라) 이 경우 이전 표시를 재설정할 필요가 없으며 단순한 시간 손실로 이어질 것입니다. 즉, 131번 에러는 설정 정지 블록 진입 후 에러 메시지가 표시되기 전에 나타납니다. 정류장이 실제로 설정되지 않았기 때문에 OrderModify() 함수는 호출된 마지막 함수이며 이전 함수와 마찬가지로 항상 마지막 오류 값을 변경합니다. 나만 이해가 안되는데 왜 131??? 어디에? 다시 한번 테스터에는 문제가 없음을 말씀드립니다.
브로커가 똑똑하다는 생각은 터미널을 보내는 서버이고 차례로 오류 번호를 어드바이저에게 보내는 서버이기 때문입니다. 그런 일은 한 명의 고문의 명령으로 만 발생하기 때문에 빨리 포기했습니다. 병렬로 일하는 나머지 고문은 작업에 오류가 없습니다.
생각이 한창입니다! 하지만 경험에서 알 수 있듯이 우리가 생각하는 것(당연히 있어야 하는 것과 실제로 존재하는 것은 매우 자주 다른 것입니다. 조언할 수 있는 것: "코드 실행의 전체 시퀀스를 인쇄하십시오.", - 이것이 가장 빠르게 찾을 수 있는 방법입니다. 오류 (또는 당신이 옳았는지 확인하십시오). :)
3점 답변을 작성하셨습니다. 당신은 첫 번째 항목에서 실수를 했고(내 항목은 매우 정확합니다) 두 번째 항목에서도 실수했습니다(비록 이것은 이 메시지에 의해 평준화되었지만 실수로 인해). 그러한 그림을 배경으로 나는 경험이 풍부한 중재자로부터 답변을 받는 것을 선호했습니다.
petya33r : 411페이지에 작성된 내용으로 돌아가서 ... 두 MA가 교차하는 지점에서 해당 코드와 출입구 조건을 결합하는 방법을 아는 사람이 있습니까? 아니면 보류 중인 주문이 유일한 옵션입니까?
이동 신호에 대한 거래를 연 후 주문 수 또는 이 주문을 구체적으로 모니터링하기 시작합니다. 주문 수가 감소하거나 두 번째 옵션에 따라 이 특정 주문이 어떻게 마감되는지 확인한 다음 다음과 같은 경우 어떻게 마감되었는지 확인합니다. 중지하면 현재 가격에서 반대 주문이 열립니다. 그게 전부입니다.
이동 신호에 대한 거래를 연 후 주문 수 또는 이 주문을 구체적으로 모니터링하기 시작합니다. 주문 수가 감소하거나 두 번째 옵션에 따라 이 특정 주문이 어떻게 마감되는지 확인한 다음 다음과 같은 경우 어떻게 마감되었는지 확인합니다. 중지하면 현재 가격에서 반대 주문이 열립니다. 그게 전부입니다.
이해는 하는데 쓸 수가 없습니다. EA는 움직이는 신호에서만 거래하고 손실이 발생한 경우 리버스 포지션을 열지 않거나 테스트 시작 시 터미널이 단순히 충돌합니다. 나는 일반적으로 처리되지 않은 것을 썼다는 것을 의미합니다. 글을 쓰는데 어려움을 겪고 있습니다. 코드에 대한 도움이 필요합니다.
//нет открытых ордеров - ищем в истории закрытых ордеров последний закрытый именно этим советником ордер for ( trade = OrdersHistoryTotal () - 1 ; trade >= 0 ; trade-- )
{
if ( OrderSelect (trade, SELECT_BY_POS , MODE_HISTORY ) && OrderMagicNumber () == MagicNumber && OrderSymbol () == Symbol () )
{
old_order_type = OrderType ();
if ( OrderProfit ()< 0 ) //последний закрытый советником ордер был убыточным, значит, следующий ордер открываем в направлении, противоположном закрытому с убытком
{
break ; //прекращаем поиск
}
}
}
//если раньше покупали, то теперь продаемif ( old_order_type == OP_BUY )
{
ticket = OrderSend ( Symbol (), OP_SELL , Lot, NormalizeDouble ( Bid , Digits ), slip, NormalizeDouble ( Ask +stoploss* Point , Digits ), NormalizeDouble ( Ask -takeprofit* Point , Digits ), "Martingale-Sell" , MagicNumber, 0 , Red);
Sleep ( 2000 ); //задержка в 2 секунды для обработки запроса торговым сервером брокераreturn ( 0 );
}
다음은 마감된 주문이 있는지 여부를 확인하고 OrderProfit() <0 손실을 받으면 반대쪽을 엽니다. 그러나 움직임의 신호와 함께 작동하지 않습니다. 움직이는 신호와 반대 위치를 여는 조건이 모두 같도록 단일 코드를 작성할 수 있습니까?
글쎄, 나는 확실히 당신을 위해 문제가 해결되기 시작했다는 것을 기쁘게 생각합니다. 그러나 어떤 이유로 당신은 내 메시지를 눈치 채지 못했습니다. 내가 같은 것을 약간 다른 말로 말하고 즉시 단점에 대해 말했습니다. 파일을 닫을 때 어디에서 발생하는지 즉시 보지 못했습니다. :)
3점 답변을 작성하셨습니다. 당신은 첫 번째 항목에서 실수를 했고(내 항목은 매우 정확합니다) 두 번째 항목에서도 실수했습니다(비록 이것은 이 메시지에 의해 평준화되었지만 실수로 인해). 그러한 그림을 배경으로 나는 경험이 풍부한 중재자로부터 답변을 받는 것을 선호했습니다.
그러나 응답해 주셔서 감사합니다. 그리고 새해 복 많이 받으세요! :)
안녕하세요. 불쾌한 상황에 직면했습니다. 이해하도록 도와주세요.
고문이 있습니다. 테스터에서는 아무 불만 없이 잘 작동합니다. 그러나 데모에서 실행하고 고문은 일부 주문에 대해 중지를 설정할 수 없습니다. 때때로 표시되지 않는 특정 오류가 있습니다. 나는 그것을 스스로 찾기 위해 필사적이었습니다. 당신의 도움을 바랍니다. 동시에 테스터에는 불만이 없기 때문에 다른 모든 측면에서 고문이 완벽하게 작동하지만 문제는 정지가 항상 설정되지 않는다는 것입니다. 다른 계정의 다른 브로커에 오류가 나타납니다. 다음은 거래 작업을 담당하는 코드의 일부입니다.
다음은 Error(int er) 함수에 대한 코드입니다.
따라서 Advisor가 중지 설정에 실패하면 오류에 대한 정보와 그가 수정하려고 시도한 주문의 매개변수를 표시하는 메시지가 나타납니다. 그가 나를 위해 쓰는 것은 정말 미스터리입니다. 아래 사진을 보시면 알겠지만 계속해서 볼륨이 틀려진다고 씁니다. 기이한. 수정하기 전에 모든 주문 매개변수가 올바르게 계산된다는 점을 추가하겠습니다. 이는 메시지에서 확인할 수 있습니다. 게다가, 그렇지 않으면 완전히 다른 오류가 발생합니다. 프로그램은 데모에 있는 것보다 더 높은 스프레드로 테스트되었습니다.
안녕하세요. 불쾌한 상황에 직면했습니다. 이해하도록 도와주세요.
고문이 있습니다. 테스터에서는 아무 불만 없이 잘 작동합니다. 그러나 데모에서 실행하고 고문은 일부 주문에 대해 중지를 설정할 수 없습니다. 때때로 표시되지 않는 특정 오류가 있습니다. 나는 그것을 스스로 찾기 위해 필사적이었습니다. 당신의 도움을 바랍니다. 동시에 테스터에는 불만이 없기 때문에 다른 모든 측면에서 고문이 완벽하게 작동하지만 문제는 정지가 항상 설정되지 않는다는 것입니다. 다른 계정의 다른 브로커에 오류가 나타납니다. 다음은 거래 작업을 담당하는 코드의 일부입니다.
다음은 Error(int er) 함수에 대한 코드입니다.
따라서 Advisor가 중지 설정에 실패하면 오류에 대한 정보와 그가 수정하려고 시도한 주문의 매개변수를 표시하는 메시지가 나타납니다. 그가 나를 위해 쓰는 것은 정말 미스터리입니다. 아래 사진을 보시면 알겠지만 계속해서 볼륨이 틀려진다고 씁니다. 기이한. 수정하기 전에 모든 주문 매개변수가 올바르게 계산된다는 점을 추가하겠습니다. 이는 메시지에서 확인할 수 있습니다. 게다가, 그렇지 않으면 완전히 다른 오류가 발생합니다. 프로그램은 데모에 있는 것보다 더 높은 스프레드로 테스트되었습니다.
전역 변수의 값에 주의하십시오. ord_ticket이 전역 변수라고 가정할 수 있습니다. 즉, 이전 값을 저장할 수 있습니다. 그리고 GetLastError()를 호출하여 오류를 포착하기 전에 코드 시작 부분에서 호출하여 이전 표시를 재설정해야 합니다.
ord_ticket은 로컬로 선언됩니다. 그런 다음 첫 번째 줄에서 전역 수준으로 선언하더라도
그 의미가 바뀌어야 합니다. 작업이 성공하면 주문 번호이고 그렇지 않으면 -1입니다. 따라서 주문이 열리지 않으면 중지 설정 블록에 들어 가지 않습니다.
또한 OrderSend () 함수는 항상 마지막 오류의 값을 변경하므로(문서 및 논리에 따라) 이 경우 이전 표시를 재설정할 필요가 없으며 단순한 시간 손실로 이어질 것입니다. 즉, 131번 에러는 설정 정지 블록 진입 후 에러 메시지가 표시되기 전에 나타납니다. 정류장이 실제로 설정되지 않았기 때문에 OrderModify() 함수는 호출된 마지막 함수이며 이전 함수와 마찬가지로 항상 마지막 오류 값을 변경합니다. 나만 이해가 안되는데 왜 131??? 어디에? 다시 한번 테스터에는 문제가 없음을 말씀드립니다.
브로커가 똑똑하다는 생각은 터미널을 보내는 서버이고 차례로 오류 번호를 어드바이저에게 보내는 서버이기 때문입니다. 그런 일은 한 명의 고문의 명령으로 만 발생하기 때문에 빨리 포기했습니다. 병렬로 일하는 나머지 고문은 작업에 오류가 없습니다.
ord_ticket은 로컬로 선언됩니다. 그런 다음 첫 번째 줄에서 전역 수준으로 선언하더라도
그 의미가 바뀌어야 합니다. 작업이 성공하면 주문 번호이고 그렇지 않으면 -1입니다. 따라서 주문이 열리지 않으면 중지 설정 블록에 들어 가지 않습니다.
또한 OrderSend () 함수는 항상 마지막 오류의 값을 변경하므로(문서 및 논리에 따라) 이 경우 이전 표시를 재설정할 필요가 없으며 단순한 시간 손실로 이어질 것입니다. 즉, 131번 에러는 설정 정지 블록 진입 후 에러 메시지가 표시되기 전에 나타납니다. 정류장이 실제로 설정되지 않았기 때문에 OrderModify() 함수는 호출된 마지막 함수이며 이전 함수와 마찬가지로 항상 마지막 오류 값을 변경합니다. 나만 이해가 안가는데 왜 131??? 어디에? 다시 한번 테스터에는 문제가 없음을 말씀드립니다.
브로커가 똑똑하다는 생각은 터미널을 보내는 서버이고 차례로 오류 번호를 어드바이저에게 보내는 서버이기 때문입니다. 그런 일은 한 명의 고문의 명령으로 만 발생하기 때문에 빨리 포기했습니다. 병렬로 일하는 나머지 고문은 작업에 오류가 없습니다.
추가하겠습니다. 병렬 EA에는 정지 설정을 담당하는 동일한 코드가 있습니다. 따라서 이 Expert Advisor는 주문에 대해 정류장이 설정되지 않은 상황이 없었습니다.
위의 매개변수 계산에 오류가 있는 것으로 나타났지만 하나 이상의 매개변수가 정확하지 않으면 다른 오류가 표시되어야 합니다. 예를 들어 잘 알려진 130
ord_ticket은 로컬로 선언됩니다. 그런 다음 첫 번째 줄에서 전역 수준으로 선언하더라도
그 의미가 바뀌어야 합니다. 작업이 성공하면 주문 번호이고 그렇지 않으면 -1입니다. 따라서 주문이 열리지 않으면 중지 설정 블록에 들어 가지 않습니다.
또한 OrderSend () 함수는 항상 마지막 오류의 값을 변경하므로(문서 및 논리에 따라) 이 경우 이전 표시를 재설정할 필요가 없으며 단순한 시간 손실로 이어질 것입니다. 즉, 131번 에러는 설정 정지 블록 진입 후 에러 메시지가 표시되기 전에 나타납니다. 정류장이 실제로 설정되지 않았기 때문에 OrderModify() 함수는 호출된 마지막 함수이며 이전 함수와 마찬가지로 항상 마지막 오류 값을 변경합니다. 나만 이해가 안되는데 왜 131??? 어디에? 다시 한번 테스터에는 문제가 없음을 말씀드립니다.
브로커가 똑똑하다는 생각은 터미널을 보내는 서버이고 차례로 오류 번호를 어드바이저에게 보내는 서버이기 때문입니다. 그런 일은 한 명의 고문의 명령으로 만 발생하기 때문에 빨리 포기했습니다. 병렬로 일하는 나머지 고문은 작업에 오류가 없습니다.
3점 답변을 작성하셨습니다. 당신은 첫 번째 항목에서 실수를 했고(내 항목은 매우 정확합니다) 두 번째 항목에서도 실수했습니다(비록 이것은 이 메시지에 의해 평준화되었지만 실수로 인해). 그러한 그림을 배경으로 나는 경험이 풍부한 중재자로부터 답변을 받는 것을 선호했습니다.
그러나 응답해 주셔서 감사합니다. 그리고 새해 복 많이 받으세요! :)
:D ok, 새해 복 많이 받으세요 :)
411페이지에 작성된 내용으로 돌아가서 ... 두 MA가 교차하는 지점에서 해당 코드와 출입구 조건을 결합하는 방법을 아는 사람이 있습니까? 아니면 보류 중인 주문이 유일한 옵션입니까?
이동 신호에 대한 거래를 연 후 주문 수 또는 이 주문을 구체적으로 모니터링하기 시작합니다. 주문 수가 감소하거나 두 번째 옵션에 따라 이 특정 주문이 어떻게 마감되는지 확인한 다음 다음과 같은 경우 어떻게 마감되었는지 확인합니다. 중지하면 현재 가격에서 반대 주문이 열립니다. 그게 전부입니다.
이동 신호에 대한 거래를 연 후 주문 수 또는 이 주문을 구체적으로 모니터링하기 시작합니다. 주문 수가 감소하거나 두 번째 옵션에 따라 이 특정 주문이 어떻게 마감되는지 확인한 다음 다음과 같은 경우 어떻게 마감되었는지 확인합니다. 중지하면 현재 가격에서 반대 주문이 열립니다. 그게 전부입니다.
이해는 하는데 쓸 수가 없습니다. EA는 움직이는 신호에서만 거래하고 손실이 발생한 경우 리버스 포지션을 열지 않거나 테스트 시작 시 터미널이 단순히 충돌합니다. 나는 일반적으로 처리되지 않은 것을 썼다는 것을 의미합니다. 글을 쓰는데 어려움을 겪고 있습니다. 코드에 대한 도움이 필요합니다.
다음은 마감된 주문이 있는지 여부를 확인하고 OrderProfit () < 0 손실을 받으면 반대쪽을 엽니다. 그러나 움직임의 신호와 함께 작동하지 않습니다. 움직이는 신호와 반대 위치를 여는 조건이 모두 같도록 단일 코드를 작성할 수 있습니까?