SL/TP 주문 수락 - 페이지 8

[fxsaber]

Andrey Khatimlianskii # :

그건 그렇고, 네, 흥미롭습니다. 스몰 리미트 플레이어가 거대한 포지션의 TP와 같은 수준인데 이 TP가 크다고 거절당하면 리밋 플레이어는 채울 기회조차 없을까요?

잘못된 추측입니다. 모든 테이크가 전송되면 테이크 큐가 만료됩니다. 저것들. 리미터는 이 전송의 결과가 아니라 모든 테이크가 전송되기를 기다리고 있습니다.

다른 사람의 한도 한도 전송을 큰 테이크 볼륨이 아니라 한도 한도의 가격 수준에서 대량의 테이크에 의해 전송 속도를 늦출 수 있습니다. 예를 들어, 최소 많은.

[Andrey Khatimlianskii]

fxsaber # :

잘못된 추측입니다. 모든 테이크가 전송되면 테이크 큐가 만료됩니다. 저것들. 리미터는 이 전송의 결과가 아니라 모든 테이크가 전송되기를 기다리고 있습니다.

다른 사람의 한도 한도 전송을 큰 테이크 볼륨이 아니라 한도 한도의 가격 수준에서 대량의 테이크에 의해 전송 속도를 늦출 수 있습니다. 예를 들어, 최소 많은.

글쎄, 어쨌든. 모든 TP와 제한을 연속적으로 실행하는 것보다 무엇이든 좋습니다.

그러나 물론 대기열을 수정해야 합니다. TP는 일반 리미터여야 합니다.

[fxsaber]

Andrey Khatimlianskii # :

글쎄, 어쨌든. 모든 TP와 제한을 연속적으로 실행하는 것보다 무엇이든 좋습니다.

그러나 물론 대기열을 수정해야 합니다. TP는 일반 리미터여야 합니다.

여기 에 주제에 대한 더 많은 정보가 있습니다. 예와 함께.

[fxsaber]

fxsaber # :

여기 주제에 대해 더 많은 정보가 있습니다. 예를 들어.

TP 오더가 태어난 후에 활성화 TP 오더 틱이 나타났다고 합니다! 저것들. 처음에는 TP 주문이 생성되었고, 그 다음에야 TP 주문이 생성된 틱이 발생했습니다. 미친 소리야. 따라서 우리는 그림을 자세히 이해합니다.

스크립트는 실수하지 않았습니다! 이것은 틱 데이터베이스가 엄청난 지연으로 가득 차 있음을 의미합니다. 그리고 틱 시간은 녹음 시간으로 고정됩니다. 저것들. 잘못된 틱 시간.

그래서 건축이 있었다.   MT5 버그 .

MQ-Demo에서 처음부터 이 버그를 재현합니다.

 #include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define Bid SymbolInfoDouble ( _Symbol , SYMBOL_BID )
#define Ask SymbolInfoDouble ( _Symbol , SYMBOL_ASK )

input int inTP = 10 ;

// Выставляет противоположные позиции с фиксированным тейком.
void OnStart ()
{
   OrderSend ( _Symbol , OP_BUY, 0.1 , Ask, 0 , 0 , Ask + inTP * _Point );

   OrderSend ( _Symbol , OP_SELL, 0.1 , Bid, 0 , 0 , Bid - inTP * _Point );
}

포지션을 종료한 후 테이크가 트리거된 시간과 테이크를 활성화했어야 하는 틱의 시간을 확인합니다.

활성화 틱이 나타난 것보다 61ms 일찍 테이크가 트리거 되었음을 알 수 있습니다.

이 버그는 MQ-Demo에서만 재현되는 것이 아니라 실제 계정에서도 발생합니다. 그러나 MQ-Demo는 위와 같이 즉시 재생할 수 있습니다.

불행히도 거래 서버의 틱 데이터베이스가 손상되었습니다.

검색 문자열 : Osibka 042.