Errores típicos y cómo afrontarlos en el entorno comercial - página 2

 

fxsaber:

La función que indica la necesidad de una envoltura está marcada en rojo. Su problema se describe aquí. Algunos recordarán que se trata de un antiguo problema de reapertura de posiciones, que en la antigüedad se solucionaba con el Sleep, esperando a que la posición se abriera después del OrderSend. Pero en realidad, este problema no tiene nada que ver con OrderSend. Debe ser capaz de leer correctamente el entorno comercial.

La derecha es un ejemplo sencillo.

La lista de pedidos, al igual que la lista de posiciones, no se actualiza instantáneamente. Creo que no podemos prescindir de Sleep-crutch.

Probablemente sea más correcto OnTradeTransaction

 
Aleksey Lebedev:

La lista de órdenes, al igual que la lista de posiciones, no se actualiza instantáneamente. imho, no podemos prescindir de Sleep-crutch.

Probablemente, sería mejor utilizar OnTradeTransaction.

Si hay un problema esperando la actualización del entorno, ¿cómo puede ayudar Sleep? Ayudará o no.

Por lo tanto, el enfoque debe ser desde el otro lado: después de enviar una orden para abrir una posición o establecer una orden pendiente, debemos esperar el resultado y no enviar más órdenes para abrir o establecer. Por lo tanto, necesitamos una bandera que nosotros mismos manejamos en lugar de confiar en Sleep que sólo da el retraso de la ejecución del programa, pero no comprueba el resultado de una solicitud de comercio enviado por el propio programa que debe saber qué hacer después de que - para establecer una bandera y trabajar de acuerdo a la lógica de los resultados de espera. Después de esperar el resultado, se elimina la bandera.

 
Artyom Trishkin:

Pregunta: ¿Qué ocurrirá si después de enviar una orden de mercado hasta el siguiente tick la orden de mercado no es colocada por el servidor?

Será exactamente lo mismo que en MT4 - si no hay nada, no se contará.


Puede haber varias razones para una orden de comercio de este tipo

  1. OrderSend o OrderSendAsync de terceros - no del programa en el que leemos el entorno comercial. Incluso puede que no sea desde el terminal en el que se ejecuta el programa. En este caso, no se puede hacer nada. Todo es igual que en MT4 en estas situaciones.
  2. OrderSend o OrderSendAsync - se inician desde el programa en el que se lee el entorno comercial. En el caso de OrderSend, todo está claro, ya que OrderSend terminará su ejecución con un resultado claro. En el caso de OrderSendAsync podemos hacer dos cosas - pasar los datos a los siguientes eventos según el primer paradigma, o hacer OrdersAsyncWait() (no tengo el código), como se hace en una simulación de transferencia de datos asíncrona regular en MT4 (implementación de múltiples hilos).
Probablemente debería decir unas palabras sobre OrderSendAsync en MT4. En cualquier etapa de la ejecución del programa es posible ver cuán ocupado está un hilo comercial correspondiente y qué está haciendo exactamente. En este sentido, la asincronía personalizada en MT4 nos da muchas más posibilidades que la de MT5. Pero en MT4 se implementa ejecutando "clientes" en cada gráfico, es decir, caro. En MT5 es posible escribir la misma funcionalidad e incluso sin muchos gráficos - ejecutando el script en un objeto OBJ_CHART, pero todavía habrá un ligero retraso. Es decir, OrderSendAsyncCustom será ligeramente más lento que OrderSendAsync, pero seguirá siendo mucho más rápido que OrderSend + todas las ventajas de la implementación personalizada.
 
Aleksey Lebedev:

La lista de órdenes, al igual que la lista de posiciones, no se actualiza instantáneamente. imho, no podemos prescindir de Sleep-crutch.

Probablemente, sería más correcto utilizar OnTradeTransaction

MqlTradeTransaction puede ser necesario sólo cuando se elige el paradigma apropiado al trabajar con OrderSendAsync. En otros casos, OnTradeTransaction == OnTrade en sentido y no juega más papel que OnTick o OnTimer.


Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Errores típicos y cómo solucionarlos al trabajar con un entorno comercial

fxsaber, 2018.02.19 22:36

Existen dos paradigmas de trabajo con el entorno de trading, escribiendo EAs.

  1. Las entradas de eventos (OnTick, OnTimer, etc.) dependen unas de otras. Hay información que DEBE tener entre los eventos (no por velocidad, como el caché, sino por usabilidad). Por ejemplo, necesitamos guardar el resultado de OrderSendAsync y utilizarlo en OnTradeTransaction. Los cachés NO son información obligatoria y sólo se utilizan para agilizar. Por eso no los consideramos de inmediato.
  2. Las entradas de eventos (OnTick, OnTimer, etc.) NO dependen unas de otras. Cada entrada es desde cero. Más o menos como un Script que usted mismo ejecuta en cada evento.

El resaltado denota que el mismo código comercial se ejecuta en cada función On. El correspondiente código de no comercio completa todo lo demás.

 
fxsaber:

Será exactamente lo mismo que en MT4 - si no hay nada, no se contará.

Es decir, en el siguiente tick el programa envía una nueva solicitud de apertura. Como resultado, tenemos el mismo problema: múltiples aperturas.

El Asesor Experto debe tener la siguiente lógica:

  1. Recibimos una señal para abrir una posición o establecer una orden pendiente
  2. Compruebe el número de órdenes/posiciones, si no hay señal para abrir una nueva posición - salga (al punto 1).
  3. Comprueba el indicador de respuesta en espera del servidor:
    1. Bandera levantada - salida (al paso 1)
    2. Bandera omitida - continuar
  4. La bandera se omite - enviar una orden de comercio (el número de intentos es limitado) y comprobar el código de retorno
    1. La orden se ha ejecutado - fije la bandera de espera
    2. Orden fallida - llame a la función de corrección de órdenes comerciales y pase al punto 4
  5. Se levanta la bandera de espera - comprobar el cambio de entorno comercial
    1. El entorno comercial no ha cambiado - salga (al paso 1).
    2. El entorno ha cambiado - se ha colocado una orden pendiente o se ha abierto una posición - elimine la bandera de espera y salga (al paso 1).
 
Artyom Trishkin:

Es decir, en el siguiente tick, el software envía una nueva solicitud de apertura. Como resultado, tenemos el mismo problema: múltiples aperturas.

Sería bueno leer todo el post.

El EA debe tener la siguiente lógica:

  1. Hemos recibido una señal para abrir una posición o establecer una orden pendiente
  2. Compruebe el número de órdenes/posiciones, si no hay señal para abrir una nueva posición - salga (al punto 1).
  3. Comprueba el indicador de respuesta en espera del servidor:
    1. Bandera levantada - salida (al paso 1)
    2. Bandera omitida - continuar
  4. La bandera se omite - enviar una orden de comercio (el número de intentos es limitado) y comprobar el código de retorno
    1. La orden se ha ejecutado - fije la bandera de espera
    2. Orden fallida - llame a la función de corrección de órdenes comerciales y pase al punto 4
  5. Se levanta la bandera de espera - comprobar el cambio de entorno comercial
    1. El entorno comercial no ha cambiado - salga (al paso 1).
    2. El entorno ha cambiado - se ha colocado una orden pendiente o se ha abierto una posición - elimine la bandera de espera y salga (al paso 1).

La bandera de espera sólo está disponible para el segundo caso y OrderSendAsync. En el caso de OrderSend, el indicador de espera no es necesario en absoluto. OrderSendAsync sin bandera de espera es OrdersAsyncWait().

Se puede comprobar cualquier teoría en la práctica.

Guiado por los resultados prácticos.
 
fxsaber:

Es una buena idea leer el post en su totalidad.

La bandera de espera sólo es posible para el segundo caso y OrderSendAsync. Para OrderSend la bandera de espera no es necesaria en absoluto. OrderSendAsync sin bandera de espera es OrdersAsyncWait().

Cualquier teoría puede probarse en la práctica

Me guío por los resultados prácticos.

Bueno, escribí para el modo asíncrono. Con la sincronización no es necesario esperar: el resultado ya está en la respuesta de la consulta.

 
Artyom Trishkin:

Bueno, yo escribí para el modo asíncrono.

Se ha dadouna respuesta detallada desde el principio.

 
fxsaber:

Se diouna respuesta amplia desde el principio.

Debo haber leído mal :)

No he visto ningún paso para evitar el error de descubrimiento múltiple. Sólo los "paradigmas" generales ;)

Por eso he señalado la lógica aproximada, que es redundante - la bandera se comprueba en una función (wrapper) que abre posiciones / establece órdenes pendientes. O quizás también en la función de seguimiento de la señal.

Hay que pensar en la mejor manera.

 
Artyom Trishkin:

la bandera se comprueba en la función (wrapper) de apertura de posiciones/colocación de órdenes pendientes. O quizás también en la función de seguimiento de la señal.

Prefiero mucho más la solución vía OrdersAsyncWait(), cuando la salida de la función On se hace siempre sin colgar el estado. Entonces, la siguiente lectura del entorno comercial con una pizarra limpia es lo más relevante posible.

El uso de OrderSendAsync debería ser siempre apropiado. La única situación en la que puede ocurrir es el envío de varias (> 1) órdenes comerciales, independientes entre sí, sobre la misma señal. Por lo tanto, lo de OrderSendAsync nunca tiene sentido en los demás casos.


SZZY Hay un tema aparte en el que OrderSendAsync es muy relevante - multiasesores: varios TS independientes en un Asesor Experto. El OrderSend rara vez es adecuado allí e incluso el OrderAsyncWait( const string Symb) no es bueno ya que en principio no se permite el Sleep.

Razón de la queja: