Bueno, seguramente ese programa tendrá un manual/ayuda no? Podrías hacer un copiar-pegar y lo vemos de ahí.
Especulando (una vez más, estoy con ganas de dejar volar la imaginación), diría que el response delay es un tiempo que el programa de la pc espera a recibir algún tipo de confirmación del dato enviado al scada. Pasado ese tiempo si no se recibe esa confirmación me imagino (especulo) que se dará el dato por perdido y el programa de la pc intentará re-enviar el dato.
Transmit delay.... bueno, no creo que se refiera a retardos en la conexión física (por longitud del cable, tiempo de respuesta del scada en tomar el dato y enviar confirmación de recepción). Para eso se fija la tasa de símbolos (baud-rate).
Por ahí viene relacionado a como el soft interactúa con Windows para escribir datos a los puertos. Las librerías usan funciones de la api de windows (DeviceIOControl y WriteFile/ReadFile, no sé que se usa ahora con el frame .net) que traen incorporado un tiempo de espera (timeout). Esa es una cuestión interna de windows, la función de ese time-out sería que se llama a una función de lectura/escritura del puerto, si el puerto está ocupado manejando otra información (transacciones) y el recurso no se libera en el tiempo especificado por el time-out entonces la transferencia se anula, devolviendo posiblemente un mensaje de error.
Por ejemplo, si uno escribe una cadena de 1024 caracteres (por decir algo) e inmediatamente intenta escribir 10 caracteres (sin dar tiempo a que se transmitan los 1024 anteriores) lo más probable es que expire el tiempo de time-out; a menos que se haya puesto como infinito (o un número muy grande). Esto último tampoco es recomendable, porque en caso de falla de la comunicación (mal contacto de conectores, o el scada no responde, etc ) el programa se bloquearía y sería difícil salir de esa situación (salir ileso, ctrl+alt+del siempre está ahí
).
Aunque no descartaría la opción de transmit delay que tenga algo que ver con la longitud del cable.... Podría ser para compensar el tiempo de muestreo de los datos. Al aumentar la longitud del cable aumenta el retardo y en vez de muestrear el dato en la parte central del tiempo de bit se termina muestreando en cualquier parte.
ByteTimeOut... mmmmm, más de lo mismo, tal vez lo anterior se aplica a paquetes de datos y esta parámetro a bytes individuales.
Bueno, ya "volé" demasiado alto, me da un poco de vértigo. Algún tipo de documentación deberá estar dando vueltas por ahí, como dije al principio es mejor que lo veamos de ahí.
Saludos
