<DIV id=post_message_56939>Me he decidido al fin a abrir un nuevo tema tambié aquí después de mucho buscar y darle vueltas a un asunto que me trae de cabeza. Parece una tontería, seguro que es una tontería... pero debo de estar obcecado o se me está escapando algo que salta a la vista. Si alguien me pudiera ayudar le estaría enormemente agradecido. Bueno, al grano:
El asunto es que estoy desarrollando (o intentando desarrollar) una aplicación que captura datos de un lector de código de barras conectado al puerto serie RS232C, para lo cual uso el control MsComm.
Hasta aquí todo marcha bien, no hay ningún problema: los datos se leen y procesan perfectamente... lo cual no tiene escesivo mérito, es algo que ya se ha hecho millones de veces.... aunque para mí sea la primera... y aquí llega el problemilla.
El lector se puede configurar vía RS232 o escaneando una hoja de códigos de barras de configuración... yo uso este segundo método (aunque también he probado el primero) y también aquí marcha todo bien... HASTA QUE CONECTO EL LECTOR AL PUERTO.
Entonces el aparatito YA NO SE REDISPARA SÓLO. Únicamente consigo que funcione teniendo encendido el láser continuamente.
Le he dado mil vueltas al asunto... y de momento no hay manera, no doy con el quid.
Mi esperanza es que sea algo típico o la clásica metedura del novato... y que alguno de vosotros de con el problema rápidamente o me sugiera cosas que probar...
Agradecería enormemente cualquier ayuda...
Saludos y gracias.
PD: Por si hace falta el dato: el lector es un Opticon NLV-1001

yo he trabajo con lectores de código de barra RS232 y cuando capturan un dato éste queda en la memoria del lector y no permite capturar ningún otro hasta que le envíes un RTS (control por hardware).

prueba colocando
MsComm1.RTSEnable = True

y nos cuentas como te fue.

Mehabían sugerido que viese si el problema era por el handshaking, pero como yo tenía la propiedad Handshaking puesta a comNone y el lector configurado en "No handshake"... pues que me extrañaba que fuera por eso.
Ocurre que hoy no puedo probarlo porque el portátil en que tengo que trabajar estos días no tiene puerto serie y hasta que me traigan el adaptador, que espero sea hoy, seguiré en ascuas, pero me quedan un par de dudas:
¿Tengo que poner MsComm1.Handshaking = comRTS?
¿Te refieres a poner MsComm1.RTSEnable = True simplemente en tiempo de diseño o tengo que hacerlo cada vez que reciba un dato para que me envíe otro?
Es que lo que me resulta curioso es que el lector sólo conectado a la corriente funcione perfectamente, y nada más conectarlo al puerto se quede KO. Sería maravilloso que simplemente enviándole un RTS "espabilara"...
Muchas, pero muchasgracias por la sugerencia... Tan pronto tenga buenas o malas noticias lo posteo.

Bueno, instalé hoy el adaptador USB-serie y....... ¡no me funciona! como era previsible.
Tampoco hice nada más que poner RTSEnable a True en tiempo de diseño.....
Pufffff... es que es de esas cosas desesperantes que parecen una chorrada... y seguramente lo son, pero no lo soluciono ni a tiros.
Segurísimo que estoy pasando por alto algo absolutamente trivial... es que por eso me da hasta vergüenza: a ver si me hace caso el fabricante, o el distribuidor o el que sea...
Mañana me lo tomo con más calma y a ver si así veo lo que tiene que estar delante de mis narices...
Saludos y gracias por la ayuda.

una pregunta estúpida. ¿usas un cable null moden de 7 o de 3 hilos?

¡Oh Dios mío! Es incluso más complicado de lo que parecía... jaja
Ahora que ya sé lo que es un cable null modem pues yo diría que no utilizo ninguno... ni se me ocurre para qué podría necesitarlo: ya te digo que es la 1ª vez que me las veo con estos aparatos desde este punto de vista y seguro que estoy pasando por alto algo grave.
El aparatito en sí consta de un conector hembra de 9 pines del que sale un cable para el cabezal lector y otro para la alimentación. Y ya está (aparte de accesorios para montarlo en un soporte)...
Si ves que me falta algo...


Voy a hacer dos cosas: intentar probar con OTRO lector diferente y hacer el ridículo seguramente y enviarle un mail al distribuidor del maldito aparatejo...

Muchas gracias por el interés y la colaboración, Garfield.
Saludos.

Entonces voy a hacer un pequeño resumen.

los equipos se dividen en 2 tipos DTE (equipo terminal) y DCE (equipo de comunicación), un PC es un DTE y su puerto serial suele ser macho.
un módem es un DCE, su conector es hembra y está pensado para conectarse con un DTE con un cable 1 a 1, o sea, la pata 2 en el PC se conecta con la pata 2 del módem y así sucesivamente.

cuando conectas 2 DTE, ocurre que la pata 2 cumple la misma función en ambos equipos (recibe los datos), así que para conectar 2 DTE es necesario cruzar los cables, pues la pata que escucha tiene que ir conectado con la parta que recibe en el otro equipo, es como cuando hablas por teléfono, el emisor del teléfono va a tu oído que es tu receptor, o sea están cruzados. A ese cable se le llama NullModem.

en una comunicación RS232, hay 2 canales de comunicación, el R (receptor, pin 2))y el T (transmisor pin 3), como son señales eléctricas necesitan un retorno o referencia que es G (pin 5). Con esos 3 canales o hilos eléctricos es posible establecer una comunicación y es el mínimo que se utiliza.
Además de la comunicación, a veces se utiliza un control de comunicación que puede ser por software (XON/XOFF) o por hardware, cuando es por hardware es necesario agregar 4 hilos más al cable para llevar estas señales de control que son:

DTE ready (pin 4) y DCE ready (pin 6) ready DTE es una señal de salida que le dice al otro equipo que nosotros estamos presentes, el canal DCE es lo mismo per o de entrada, es donde nosotros sabemos que al otro lado del cable existe un equipo funcionando. En un buen control por hardware es necesario que tener ambas señales para que exista comunicación, sin embargo es muy común obviar esta señal y solo usar las 2 siguientes.

RTS (pin 7) petición para enviar datos, está señal se utiliza para preguntar si el equipo que está al otro lado del cable se encuentra en condiciones de establecer una comunicación, muchos equipos utilizan de paso esta señal como reemplazo de la señal DTE ready, ya que asumen que si existe una señal en el canal RTS es porque existe un equipo funcionando y no es necesario comprobar el canal DTE ready.
cuando se solicita una RTS, el otro equipo nos debe responder con una CTS (pin 8) o sea, que se encuentra listo para comunicar. Sólo si está presente la señal CTS podemos iniciar la comunicación.

Respecto a los lectores de barra, yo utilizo unos de marca "Metrologic", ahora mismo tengo uno al lado mio y también tiene un conector hembra, o sea, está pensado para conectarse de forma directa con el PC, si llegas a utilizar un cable intermedio asegurate de que tiene todos los hilos conectados y no sólo 3.
cuando mi lector lee un código, tiene un led que pasa a rojo, indicando que tiene un dato en memoria y que no puede leer nuevos códigos hasta que le envíe una RTS.
Si en tu caso no funciona, prueba a tener la señal DTE y RST encendidas (ya mencione que a veces usan el DTE), si no funciona puede ser que necesite un comando por software (lo creo poco probable peor no imposible) y ahí necesitas que el distribuidor te entregue el comando.

PD: no uses el Handshaking, dejalos prendidos de forma permanente (MsComm1.RTSEnable = True)

PD2: otro problema que a veces me a ocurrido con las comunicaciones seriales, es que algunos conversores USB a RS232 funcionan con baja potencia y no son compatibles con algunos equipos, es raro pero me ha pasado, si puedes prueba el lector con un PC con puerto RS232 nativo y no con conversor USB, para descartar.

Todo un curso acelerado de comunicaciones serie para mí y el que lo lea. Desde luego que se agradece el esfuerzo.
Aunque llevo unas semanitas dándole vueltas a estos asuntos, debería ser superfluo preguntarse por como funciona el hardware si todo marcha como debe marchar. Estos son dispositivos muy comunes y más o menos con enchufarlos debería bastar.
También recuerdo hace bastantes años utilizar una clase en C, que nos explicaban y daban hecha para una práctica, para gestionar a bajo nivel el puerto serie... que si IRQ 4 y tal y cual... (no me preguntes ahora como funcionaba el tema que ni idea... jajaja)... Pues para eso está MsComm y no tenemos que preocuparnos... ¿no? pues lo mismo.
Vamos es que ni se me ocurre que es lo que falta. Un par de observaciones para resumir y aclarar:

1. En "vacío" el aparato funciona bien: hay un puntito rojo que se convierte en una gran linea cuando detecta un código de barras (esto lo hace una opción "Auto Trigger Enable")
2. Cuando lo conectas al puerto se apaga casi instantáneamente, esté en ejecución o no mi programa (o sea que no soy yo o MsComm el que lo hace)
3. Sólo consigo que despierte (lo cual me permitió casi terminar el resto de la aplicación) mandándole por software los comandos "TriggerDisable" y "LaserEnable" y a partir de ahí se leen perfectamente todos los códigos de barras que hagan falta, eso sí, con el diodo en ON continuo. Para mí eso significa que el aparato y la aplicación se comunican bien.
Tampoco necesito decirle que me envíe el dato, como en tu modelo.
4. El adaptador USB/RS232 sólo lo uso desde ayer, hasta ahora conectaba directamente al puerto, o sea que no es ese el problema: funciona igual de mal de las dos maneras... jajaja
Seguiré probando cosas y, de momento, ya envíe la consulta al distribuidor. A ver si se apiadan de mí y me hacen caso.
En fin, Garfield, muchas gracias por la ayuda: si nos encontramos algún día estás invitado a lo que quieras.
Muchos saludos.

se agradece Hal y suerte con el distribuidor.

Gracias a ti... cuando uno se atasca en algo tan exasperante cualquier solidaridad o mínimo dato se agradece enormemente.
Todavía no me han contestado, pero me he descargado esta mañana el Free Serial Port Monitor que recomendaste en el tema de la báscula.
Muy útil: por lo que puedo ver todo funciona como debe ser (salvo lo del inicio)... y además me soluciona un problema porque también probé a configurar el lector vía puerto y tenía la duda de si me recogería los comandos que le envío (por el tiempo de espera del dispositivo)... le he puesto un Sleep de 50 ms y gracias al programilla ese se puede confirmar que lee los datos (y que sigue sin hacer caso... jaja).
Al final va a ser la tontería más grande del mundo, como una linea en el manual que he leido 20 veces y no le he hecho caso: seguro.
Muchos saludos.

Bueno, ya tengo noticias del distribuidor. Realmente me ha sorprendido agradablemente que contestaran tan rápido.
Os pongo un extracto de lo que me han dicho:
"...este modelo tendría el trigger conectado a DB-9 pin 1...En algunos casos podría causar un problema. La solución sería desconectar con cuidado el cable en DB-9 pin 1 y de aislar el extremo del cable...Otra solución sería devolver el lector...para su modificación."
En fin, Garfield, como eres bastante experto en esto a lo mejor a ti se te ocurre algún comentario sobre el problemita...
Lo que esto ha tenido de bueno para mí es que, a fuerza de buscar y buscar,he aprendido un montón de cosas estas ultimas semanas que no hubiera aprendido si el lector funcionara bien desde el principio.
Saludos.

Pues la verdad, si no te dicen lo del trigger no hay forma de descubrirlo.

el Pin 1 en un DTE es una señal que el módem utiliza para informar de la existencia de señal portadora (la portadora se utiliza por el módem para "convertir" la señal de digital a analógica). Así que el uso que ellos de dan al pin 1 es una modificación exclusiva de ellos y debería aparecer en los manuales del equipo.

lo bueno es que ya lograste descubrir el problema.