Haz una pregunta
  Foros de Electrónica » Diseño digital » Interfaces y Programación
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

16/12/2008 #1


Parametros de tiempo para RS-232C
para la interfaz entre la pc y un sitema scada power measurement basado en un microcontrolador de 16 bits, el cual he tratado de comunicar mediante un cable serial RS232C y que conecte a un conversor RS232 a RS485 para la comunicacion con el sistema, pero en la pc me habre un cuadro de dialogo llamado timings y que me pide parametros de tiempo como Response Delay, Transmit delay, Byte timeout y otros dos parametros llamados rts control y dtr, con estos dos parametros no existe mucha complicacion, pero con el valor de tiempo que debe de ser en milisegundos presiento que es el problema porque no se acerca de estos parametros para el puerto serial.
22/12/2008 #2

Avatar de Ardogan

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
Respuesta
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Buscar más temas sobre:
Lupa Interfaces y Programación

Lenguajes de programación, gestión y manejo de puertos

Cerrar
Foros de Electrónica » Diseño digital » Interfaces y Programación

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.