내 EA가 이중 항목을 수행합니다. - 페이지 4

새 코멘트
 
doshur :

PositionSelect()가 클라이언트 측 또는 서버 측을 확인하는지 물어봐도 될까요?

나는 문제가 서버(브로커 측)가 요청을 처리하고 클라이언트 측이 업데이트되지 않은 지연으로 인해 발생한다는 강한 느낌을 받습니다. 이것이 PositionSelect()가 다시 실행되는 이유입니다

나는 cTrade와 MqlTradeRequest 방식을 사용할 때 차이가 없다고 강하게 느끼고 있으며, Sleep 기능은 PositionSelect()가 다시 실행되어 이중 항목이 발생하기 전에 클라이언트 측이 "업데이트"되도록 모든 것을 지연시키는 데 도움이 되어야 합니다. 나의 일지 탭에서 확인 > 2013.12.20 08:35:00 거래 '800****': 313ms 후 실행을 위해 배치된 시장에서 0.01 EURUSD 교환 매수 <

400 이상 잠을 자면 안전해야합니까???

어떻게 생각하나요?


"저는 이 문제가 서버(브로커 측)가 요청을 처리하고 클라이언트 측이 업데이트되지 않은 지연으로 인해 발생한다는 강한 느낌이 듭니다. 이것이 PositionSelect()가 다시 실행되는 이유입니다."

저도 이것이 이중 진입의 원인이라고 생각합니다. 내 코드에서 현재 위치 크기가 최대 허용 위치 크기보다 크거나 같으면 새 주문을 보내는 것이 이론적으로 불가능하므로 PositionSelect()가 현재 위치의 상태를 제때 수신하지 못하면 내 EA는 다시 새로운 순서로.


"400이상 자면 안전할까요???"

시간 간격이 클수록 좋지만 문제가 있습니다. 두 단계(LONG에서 SHORT로 또는 SHORT에서 LONG으로)로 포지션을 바꾸면 이 추가 시간 지연으로 인해 특히 거시 경제 상황에서 실행 가격이 나빠질 수 있습니다.

 
snelle_moda :


"저는 이 문제가 서버(브로커 측)가 요청을 처리하고 클라이언트 측이 업데이트되지 않은 지연으로 인해 발생한다는 강한 느낌이 듭니다. 이것이 PositionSelect()가 다시 실행되는 이유입니다."

저도 이것이 이중 진입의 원인이라고 생각합니다. 내 코드에서 현재 위치 크기가 최대 허용 위치 크기보다 크거나 같으면 새 주문을 보내는 것이 이론적으로 불가능하므로 PositionSelect()가 현재 위치의 상태를 제때 수신하지 못하면 내 EA는 다시 새로운 순서로.


"400개 이상 자면 안전할까요???"

시간 간격이 클수록 좋지만 문제가 있습니다. 두 단계(LONG에서 SHORT로 또는 SHORT에서 LONG으로)로 포지션을 바꾸면 이 추가 시간 지연으로 인해 특히 거시 경제 상황에서 실행 가격이 나빠질 수 있습니다.

문제가 되지 않아야 한다고 생각합니다. 방금 구매/판매 요청을 보냈을 때 내 EA가 즉시 취소되지 않습니다. 내 EA가 브로커 업데이트를 기다릴 충분한 시간을 갖도록 잠을 800ms로 설정하고 있습니다. Sleep이 여기에서 이 문제를 해결할 수 있기를 바랍니다.
 
doshur :
중개인이 여기에서 따로 노는지는 모르겠지만 우리 중개인은 같은 것 같습니다. 알파리.

필요한 경우 브로커 이름을 제거하십시오.
예 브로커는 동일합니다.
 
snelle_moda :


2013년 3월 10일 이후로 1번의 이중 입력이 더 있었습니다. 주문을 보낼 때 두 가지 방법을 모두 사용합니다. 내 이전 게시물을 참조하십시오.

아... 역시 예상대로...
 

이것은 내가 방금 구현한 것입니다. 잘하면 문제를 해결할 수 있습니다

 if (m_Trade.PositionOpen( Symbol (), ORDER_TYPE_BUY , LotSize, Price, 0 , 0 ))
            {
               Sleep ( 800 );

               if (m_Trade.ResultRetcode() == 10009 )
               {
                   Print ( "Position opened in " , Symbol ());

                   return ;
               }
               else
               {
                   Print ( "Error opening position in " , Symbol (), " - " , m_Trade.ResultComment(), "\n" , "Return Code Desc - " , m_Trade.ResultRetcodeDescription());
               }
            }
             else
            {
               Print ( "Error with PositionOpen in " , Symbol (), " - " , m_Trade.ResultComment(), "\n" , "Return Code Desc - " , m_Trade.ResultRetcodeDescription());
            }
 
doshur :

이것은 내가 방금 구현한 것입니다. 잘하면 문제를 해결할 수 있습니다

내가 아는 한 결과 코드 = 10008은 거래가 잘 이루어졌음을 나타냅니다.
 

나는 이 문제의 원인을 찾는 것이 매우 중요하다고 생각합니다. 물론 무슨 일이 일어나고 있는지 완전히 이해할 수 있을 때까지 해결 방법(Sleep ?)을 갖는 것도 중요합니다. 그래서 나는 상황을 재개하려고합니다.

  • CTrade 클래스에서 PositionOpen 메소드를 사용할 때, 적어도 3명의 사용자가 어느 시점에 얻었고, 2는 1이 아닌 같은 방향으로 거래되어 예상했던 것보다 두 배의 볼륨을 가진 위치가 되었습니다.
  • 처음에 doshur가 게시한 코드는 거래가 열리지 않은 상태에서 "Position opens in..."이라는 로그를 볼 수 있는 이유를 설명할 수 있습니다. 이는 PositionOpen()이 true를 반환하더라도 거래가 이루어졌음을 의미하지 않기 때문입니다. 설명서 를 참조하십시오 . 그러나 "이중" 거래가 이루어진 이유를 설명할 수 없습니다.
  • 나는 이 "이중" 거래에 대해 2가지 설명만 볼 수 있습니다.
  1. PositionSelect()는 항상 위치의 실제 상황을 반환하지 않습니다. 위치가 열렸지만 PositionSelect가 false를 반환합니다. 그러면 PositionSelect의 버그가 발생합니다.
  2. 거래가 이루어지지만 다음 틱에서 PositionSelect()가 호출되면 해당 위치는 아직 존재하지 않습니다. 그것이 가능한지 이해하려면 거래가 이루어질 때의 운영 흐름을 알아야 합니다.
  • 이 문제는 Depth of Market이 활성화된 기호와 함께 동일한 브로커에서 발생하는 것으로 보입니다(관련 사람들이 확인하시기 바랍니다).
  • 이 문제는 동기 순서에서 발생하며 비동기 순서가 사용되지 않았습니다(확인하십시오).
  • 문제는 무작위로 발생합니다.
  • Klammeraffe 보고서 에는 더 이상 문제가 없지만 그가 게시한 코드가 이를 설명할 수 있는 방법을 알 수 없습니다. 이 코드는 각 틱에서 실행됩니까? 이 코드는 PositionSelect()를 사용한 후에 실행됩니까? 그래서 아마도 그는 오류의 원인을 제거했거나 무작위일 수 있습니다.
  • 코드를 확인한 후 CTrade 클래스를 사용하거나 OrderSend와 함께 MqlTradeRequest를 직접 사용하는 것 사이에 차이를 볼 수 없습니다.

나는 snella_moda에 동의합니다 . 가장 좋은 설명은 다음과 같습니다.

I think the problem is the (to slow) execution of the PositionSelect(Symbol()) function. Maybe, the new ticks come in so fast, the EA sends in a new order before it receives a response of the PositionSelect(Symbol()). So the current position size is not calculated properly. In my code, its theoretically impossible to send in a new/double order if the current position size is equal or greater than the max allowed position size, see code. 

하지만 확인이 어렵습니다.

가장 좋은 방법은 Metaquotes에게 조언을 구하는 것입니다. 나는 그것을 시도 할 것이다.

 
angevoyageur :
  • Klammeraffe 보고서 에는 더 이상 문제가 없지만 그가 게시한 코드가 이를 설명할 수 있는 방법을 알 수 없습니다. 이 코드는 각 틱마다 실행됩니까? 이 코드는 PositionSelect()를 사용한 후에 실행됩니까? 그래서 아마도 그는 오류의 원인을 제거했거나 무작위일 수 있습니다.

"각 틱"에 관한 줄이 더 이상 발생하지 않는 이유일 수 있습니다.

이 기능 은 새 막대가 나타날 때만 실행됩니다. 따라서 막대의 첫 번째 눈금만 거래를 실행할 수 있습니다. 첫 번째 막대 다음에 새 막대가 나타날 때까지 코드 get은 '반환'입니다. 아마도 이것이 나를 위해 해결되었습니다.

이 코드는 다음 기사에서 가져온 것이라고 생각합니다.

 //-------------------------------------------------- Check for new bar     
         static datetime OldTime;
         datetime NewTime[ 1 ];
         bool newBar= false ;
         
         int copied= CopyTime ( Symbol (), Period (), 0 , 1 ,NewTime);
         if (copied> 0 )
           {
             if (OldTime != NewTime[ 0 ])
               {  
                 newBar= true ;
                 OldTime=NewTime[ 0 ];
               }
           }
         else
           {
             Print ( "Error in copying historical times data, error =" , GetLastError ());
             ResetLastError ();
             return ;
           }  
         if (newBar== false ) return ;      
//-------------------------------------------------- Check for new bar
 
Klammeraffe :

"각 틱"에 관한 줄이 더 이상 발생하지 않는 이유일 수 있습니다.

이 기능은 새로운 막대가 나타날 때만 실행됩니다. 따라서 막대의 첫 번째 눈금만 거래를 실행할 수 있습니다. 첫 번째 막대 다음에 새 막대가 나타날 때까지 코드 get은 '반환'입니다. 아마도 이것이 나를 위해 해결되었습니다.

이 코드는 다음 기사에서 가져온 것이라고 생각합니다.

네, 그렇게 생각합니다. 고맙습니다.
 
  • 처음에 doshur가 게시한 코드는 거래가 열리지 않은 상태에서 "Position opens in..."이라는 로그를 볼 수 있는 이유를 설명할 수 있습니다. 이는 PositionOpen()이 true를 반환하더라도 거래가 이루어졌음을 의미하지 않기 때문입니다. 설명서 를 참조하십시오 . 그러나 "이중" 거래가 이루어진 이유를 설명할 수 없습니다.

보정. 2개의 "Position open in..."이 있고 2개의 거래가 열렸습니다.

  • 이 문제는 Depth of Market이 활성화된 기호와 함께 동일한 브로커에서 발생하는 것으로 보입니다(관련 사람들이 확인하시기 바랍니다).
다른 사람들은 확실하지 않지만 내 것은 DOM이 있습니다.

  • 이 문제는 동기 순서에서 발생하며 비동기 순서가 사용되지 않았습니다(확인하십시오).
저는 기본 cTrade 설정을 사용하고 있습니다.

  • 문제는 무작위로 발생합니다.
네, 무작위로

1234567891011
새 코멘트