Los parámetros que afectan a los Timings se pueden encontrar en Device Properties > Timing. Es muy común dejar los parámetros que vienen por defecto, no obstante, es interesante conocer la utilidad de cada uno ya que a nivel de optimización de las comunicaciones puede ser muy útil modificar estos parámetros. 

•  Connect timeout: Este campo solo está habilitado para los drivers Ethernet. Especifica cuanto tiempo esperará el servidor para establecer la comunicación inicial (abrir el socket) con el dispositivo. El rango válido es de 1 a 30 segundos.  

• Request timeout: Indica el tiempo que el servidor esperará a recibir una respuesta del dispositivo antes de volver a re-enviar una trama.

Este valor debe ajustarse en función del mayor tiempo de respuesta de un dispositivo, siempre a un valor superior a éste.  Es decir, si para casi todas las tramas que el servidor envía a un dispositivo, éste responde en 50 ms pero hay algunas tramas que tarda 80 ms en responder, el 'Request timeout' se debería ajustar a un valor > 80ms. Se recomienda ajustar este valor a 1,5*Tmax. Por lo tanto, en el ejemplo anterior este valor se debería ajustar a 120ms. Para poder determinar los tiempos de respuesta se pueden utilizar Softwares de análisis de protocolos, como por ejemplo Wireshark.

Es muy importante tener en cuenta el ajuste de este valor en protocolos en los cuales la frecuencia de transmisión de datos es un parámetro variable según configuración. Para muchos drivers Serie, el 'Request timeout' está ajustado a un valor por defecto correspondiente a 9600 bauds. No obstante, si se comunica con un dispositivo que utiliza un baudrate más bajo, se deberá aumentar el valor del 'Request timeout' para compensar.

• Fail after X succesive timeouts: Este parámetro especifica el número de veces que el servidor re-enviará una trama al dispositivo antes de declarar la comunicación fallida (el rango válido es de 1 a 10 veces). Si se supera este valor, el tag de error de comunicaciones  en el servidor pasará a valer 1. El ajuste de este parámetro depende mucho del entorno en el que se encuentren las comunicaciones, es decir, en entornos dónde las comunicaciones están muy afectadas por ruido se recomienda aumentar este valor.

• Inter-request delay: Este parámetro especifica el tiempo que el servidor esperará entre el envío de tramas (algunos drivers no permiten esta funcionalidad). Es útil sobre todo para dispositivos que necesitan una pequeña fracción de tiempo para cambiar el estado de transmitir a recibir (por ejemplo, algunos radio módems). El valor por defecto es 0ms, lo que quiere decir que por defecto no se tiene en cuenta éste tiempo de espera.

Se recomienda utilizar canales separados para los dispositivos que tienen configurado el 'Inter-request     delay', ya que éste tiempo afecta a las comunicaciones de los otros dispositivos del mismo canal.

Si por culpa del entorno, es propenso que se generen fallos por ruido en las comunicaciones, por un lado se puede tomar la opción de aumentar el número de intentos en que el driver prueba de enviar la trama, o por otro lado  se puede utilizar la opción del 'auto-demolition'.

Aumentar el número de intentos puede aumentar el tiempo de ciclo total en las comunicaciones de un canal y afectar a los otros dispositivos del mismo canal, ya que el driver se detiene en un request específico hasta que el dispositivo responde o hasta que se han agotado los timeouts y los reintentos. En casos como este, para optimizar las comunicaciones y no afectar a los otros dispositivos del canal, es mejor utilizar la funcionalidad de 'auto-demotion', la cual se explica en la nota FAQ003.