22 respuestas en este tema

[look]

Hola amigos , estoy tratanto de leer los datos de una balanza, concretamente esta

utilizo el componente comport.

 

esto es lo que hago:

delphi

procedure TFrmMain.ComPort1RxChar(Sender: TObject; Count: Integer);
var
  Str: AnsiString;
begin
 
  ComPort1.ReadStr(  Str, Count);
 
  Memo1.Lines.Add(  Str );
 
end;

pero lo que veo en el memo son caracteres raros.. que podra ser?.

[egostar]

Hola amigos , estoy tratanto de leer los datos de una balanza, concretamente esta
utilizo el componente comport.
 
....
 
pero lo que veo en el memo son caracteres raros.. que podra ser?.

 
Que tal amigo look,
 
Prueba con ésto
 
 

delphi

procedure TFrmMain.ComPort1RxChar(Sender: TObject; Count: Integer);
var
  Str: AnsiString;
begin
  ComPort1.ReadStr(  Str, Count);
  Memo1.Lines.Add(  PAnsiChar(Str) );
end;

Saludos

[look]

 
Que tal amigo look,
 
Prueba con ésto
 
 

delphi

procedure TFrmMain.ComPort1RxChar(Sender: TObject; Count: Integer);
var
  Str: AnsiString;
begin
  ComPort1.ReadStr(  Str, Count);
  Memo1.Lines.Add(  PAnsiChar(Str) );
end;

Saludos

 

Hola amigo, este es el resultado:

 

[egostar]

Hola amigo, este es el resultado:

 

 

Ok, aquí será prueba y error.

 

Cambia el parámetro de velocidad a 1200, luego a 2400, 4800, 19,200. No creo que supere mas de esa velocidad. 

 

Saludos

[egostar]

Y no se pero debería de haber otros parámetros modificables, que son :

 

longitud de Datos, 7, 8

Bit de parada: 1, 2

Paridad: Ninguna, Par, Impar.

 

Verifica esos datos tambien.

 

Lo que normalmente funciona es una configuración de esta forma

 

1200, Ninguna, 8, 1

1200, Par, 7, 2

 

La velocidad puede ser diferente, pero los demás parámetros normalmente utilizan esas combinaciones, a menos claro que el proveedor lo haya soñado diferente

Saludos

[Delphius]

Hola, desconozco como es el tema de ComPort, no lo he usado nunca, y tampoco he tocado alguna vez esas balanzas. Pero permítanme hacer un poco el papel de abogado del diablo y hacer una incómoda pregunta... ¿Y que se supone que debe devolverte?

 

Es decir, ¿Cuál es el resultado, en teoría, que debiera de devolverte?

Porque a ver, déjenme ver si alguito entiendo, se le manda un comando a la balanza. Un comando tendrá un formato definido, tanto en parámetros, valores, cantidad de bits, etc y perfectamente documentado en algún manual.

Asumiendo que el comando se envia perfectamente, se recibe una respuesta positiva por el mismo puerto. La respuesta también tiene su formato, y también está documentado en algún manual en que consiste.

 

Por lo general las balanzas y lectores de código de barras envían como último caracter el CRLF para indicar FIN DE COMANDO. Hasta que no se lea esto no DEBERIA pretenderse leer y encontrarle sentido a lo anterior.

 

¿No será que o bien está mal configurada? ¿No será que justamente esos caracteres raros son la versión "cadena" de los bits en cuestión? ¿No será que debería analizarse la cosa binariamente hablando? ¿O que estás mandando mal el comando?

 

EDITO:

Si nos dices más o menos como debiera de ser la salida esperada podríamos saber por donde apuntar.

No es mi itención venir de malas, solamente doy mi humilde apreciación. Porque, al menos a mi, lo más probable de esperar es que el dato no va a venir tan mágicamente visible para colocarlo tal cual en un componente que acepte cadena. Sino que deba ser "procesado" y "reinterpretado".

Algo como, bits 9 a bits 4 es el peso. Entonces un caracter asi como asi no es.

 

Saludos,

[egostar]

Hola, desconozco como es el tema de ComPort, no lo he usado nunca, y tampoco he tocado alguna vez esas balanzas. Pero permítanme hacer un poco el papel de abogado del diablo y hacer una incómoda pregunta... ¿Y que se supone que debe devolverte?

 

Es decir, ¿Cuál es el resultado, en teoría, que debiera de devolverte?

Porque a ver, déjenme ver si alguito entiendo, se le manda un comando a la balanza. Un comando tendrá un formato definido, tanto en parámetros, valores, cantidad de bits, etc y perfectamente documentado en algún manual.

Asumiendo que el comando se envia perfectamente, se recibe una respuesta positiva por el mismo puerto. La respuesta también tiene su formato, y también está documentado en algún manual en que consiste.

 

Por lo general las balanzas y lectores de código de barras envían como último caracter el CRLF para indicar FIN DE COMANDO. Hasta que no se lea esto no DEBERIA pretenderse leer y encontrarle sentido a lo anterior.

 

¿No será que o bien está mal configurada? ¿No será que justamente esos caracteres raros son la versión "cadena" de los bits en cuestión? ¿No será que debería analizarse la cosa binariamente hablando? ¿O que estás mandando mal el comando?

 

Si nos dices más o menos como debiera de ser la salida esperada.

 

Saludos,

 

Hola amigo Marchello,

 

Las comunicaciones seriales tienen su protocolo de comunicación y hablando digamos en términos terrenales, los dos equipos deben hablar el mismo idioma, no se puede hablar uno en Chino y otro en Español.

 

Saludos

[look]

Ok, aquí será prueba y error.

 

Cambia el parámetro de velocidad a 1200, luego a 2400, 4800, 19,200. No creo que supere mas de esa velocidad. 

 

Saludos

 

 

ya probe esto y el resultado siempre son caracteres raros, varian..

[Delphius]

Hola amigo Marchello,

 

Las comunicaciones seriales tienen su protocolo de comunicación y hablando digamos en términos terrenales, los dos equipos deben hablar el mismo idioma, no se puede hablar uno en Chino y otro en Español.

 

Saludos

 

A eso voy. Justamente.

Edité mi mensaje porque por error pulsé en enviar.

 

Yo creo que a lo mejor, tal como dices que debe hablarse el mismo idioma... suponiendo que la configuración está bien hecha. ¿No será que debe leerle la cosa binariamente? Algo como bits 9 a bits 4 está el peso... Es decir, hay que "procesar" y reinterpretar lo que se recibe en lugar de pretender leerlo como viene al pelo ¿que no?

 

Saludos,

[look]

A eso voy. Justamente.

Edité mi mensaje porque por error pulsé en enviar.

 

Yo creo que a lo mejor, tal como dices que debe hablarse el mismo idioma... suponiendo que la configuración está bien hecha. ¿No será que debe leerle la cosa binariamente? Algo como bits 9 a bits 4 está el peso... Es decir, hay que "procesar" y reinterpretar lo que se recibe en lugar de pretender leerlo como viene al pelo ¿que no?

 

Saludos,

 

tengo la impresion de que los datos deben de convertirse a algun formato, como de binario a ?, en fin , leere el manual, en el primer post he puesto el link del fabricante y hay varios manuales , segun veo la configuracion del puerto es para 9600, 8 bits , paridad none , nada fuera de lo comun , cosa que probe...

 

otra cosa mas , la balanza tiene un boton que se llama print: al presionarlo escribe en el puerto el valor de los pesos en kg.

[Delphius]

tengo la impresion de que los datos deben de convertirse a algun formato, como de binario a ?, en fin , leere el manual, en el primer post he puesto el link del fabricante y hay varios manuales , segun veo la configuracion del puerto es para 9600, 8 bits , paridad none , nada fuera de lo comun , cosa que probe...

 

otra cosa mas , la balanza tiene un boton que se llama print: al presionarlo escribe en el puerto el valor de los pesos en kg.

 

Estoy viendo el manual en la version 2.04, hay mucho por leer.

Pero por el momento me voy a detener en esto:

 

 

The PLC controller uses discrete write and discrete read commands to send and receive data from the Remote I/O
Interface. The PLC controller and Remote I/O Interface share a quarter rack of slot space, resulting in two 16-bit
words for the output image table (used to write commands to the indicator) and two 16-bit words for the input
image table (used to read data from the indicator).
3.1 Output Image Table Format
The PLC places two 16-bit words in the PLC output image table which are read by the Remote I/O Interface
node adapter. A discrete write command is performed when the PLC controller writes data to the output image
table. The Remote I/O Interface reads the contents of the output image table, translates the command to a form
that can be used by the indicator, and sends the command to the indicator.
The format of the output image table is shown in Table 3-1.

 

Bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Word 0 v15 v14 v13 v12 v11 v10 v09 v08 v07 v06 v05 v04 v03 v02 v01 v00
Word 1 R s s s w b b b c c c c c c c c

 

where:
v00–v15 16-bit signed integer value
R Reserved
sss Status data format
w Weight format
bbb Bit shift
cccc cccc Command number

These fields are described below:

....

 

 

Ver página 15 del archivo.

Esto me da la sospecha mia. ¿Tomar lo que viene "a lo pelo" parece que no va que no?  

 

Saludos,

[Delphius]

Ha... y en la hoja anterior dice otra cosa:

 

 

2.6 Allen-Bradley Serial Stream
Figure 2-9 shows the format of the Allen-Bradley serial stream format. This format is output from the indicator
when the EDP port AB-RIO and STREAM parameters are set ON.
Figure 2-9. Allen-Bradley Serial Stream (ABSTRM) Format
2.7 Decimal Point Handling
Discrete Transfer
Discrete transfer commands return no decimal point information to the PLC. For example, a value of 750.1
displayed on the indicator is returned to the PLC as 7501.
Block Transfer
Block transfer commands support decimal point information with no special handling.

 

Parece que hay que fumarse todo el manual y dependiendo de como esté seteado/configurado leerse de una forma u otra.

Te va a llevar un poco más de tarea de lo que pensabas look. Mil disculpas por ser el portador de las malas noticias. Pero bue... alguien iba a tener hacerlo.

 

Lo cierto es que ni bien vi la imagen que pusiste en lo primero que pensé es que la data no iba a poder leerse "tal cual". Me hizo acordar a cuando de curioso procedí a "leer" mis archivos generados "binariamente" donde guardaba mis matrices de puntos flotantes para un proyecto. Cuando uno abre el archivo con el bloc de notas o cualquier otro editor se encuenta con cosas "raras". Y esto es porque lo uno ve es justamente la interpretación "ASCII" de los bits y no necesariamente en "procesar" los bits con el tipo esperado.

 

 

Saludos,

[egostar]

Hola

 

Por lo poco que he podido leer, son valores de referencia que se traducen con el manual, debería de llegar valores ascii sin problema, lo que yo normalmente hacía (hace mucho que no toco interfaces seriales) era utilizar hiperterminal la cual se configura automáticamente con los parámetros que se requieren.

 

Aunque en versiones actuales de Windows ya no está disponible, puedes buscarla en internet y descargar la que venía en XP me parece.

 

Saludos

[Delphius]

Hola

 

Por lo poco que he podido leer, son valores de referencia que se traducen con el manual, debería de llegar valores ascii sin problema, lo que yo normalmente hacía (hace mucho que no toco interfaces seriales) era utilizar hiperterminal la cual se configura automáticamente con los parámetros que se requieren.

 

Aunque en versiones actuales de Windows ya no está disponible, puedes buscarla en internet y descargar la que venía en XP me parece.

 

Saludos

 

Buenas noches.

Te entiendo amigo. Pero es que la respuesta es SI y NO.

 

De que se puede leer el ascii sin problemas, seguro. En eso no discuto. Lo que digo es que es muy probable, de que justamente el contenido que espera leer look no venga "formato ascii" a lo pelo. Es decir, ¡no se hagan a la idea de que necesariamente la balanza va a devolver la cadena "1KG" y eso debería mirarse asi en el memo.

 

Existe una buena posibilidad de que el contenido esté codificado/formateado entre los bytes. Porque no es lo mismo leer esperar que el dato esté justo en bytes sino en el "medio".

 

A lo mejor se me entiende mejor con un ejemplo:

Supongamos que el comando recibido por la balanza es de dos bytes. El componente lee lo que hay en el COM y lo interpreta como una cadena o texto.

Perfecto, hasta ahí todo bien. Ahora entra el juego el protocolo que establece la balanza. Hemos dicho que son 2 bytes. Pero no lo que hay internamente.

 

Si el protocolo está hecho así:

[ byte1 ][  byte0 ] = <Peso><Var.Control>

 

Y si se lee un objeto de un kilo, lo de esperar es que el componente pueda interpretar ese byte1 como el '1'. El asci para '1' es 0011 0001 y como no nos interesa lo que hay en byte0 lo descartamos. Listo. El contenido hipotetico que recibe el ComPort sería 1x (siendo x la incognita)

 

Ahora, si en cambio, el protocolo dice que en lugar de esa cosa bonita y que encaja en bytes, es algo asi:

[ byte1 ][ byte0 ] = <Var.Control1><Peso><Var.Control2>

 

¡El famoso '1' está codificado entre los dos bytes! La lectura no es inmediata. En realidad debemos leer todo entero y reinterpretar nosotros lo que recibimos. Supongamos que lo que recibimos es esto:

0110 0011 | 0001 1010

Si miramos la tabla ASCI esto se traduce en la cadena 'c' seguida de un carácter "raro" ya que el byte0 en formato asci se corresponde a un elemento de control llamado sustitución.

¿Donde está tu 1? Claro. Existe... pero no como cadena, sino como un flujo de bits en el "medio".

 

Eso es lo que muy posiblemente esté pasado acá, pero a una escala mayor.

 

Ha... y ¿quien te dice que la balanza envia las cosas como asci? La balanza envia bits... pero no necesariamente van a ser entendibles para asci. Que el componente interpete ese flujo de bits como cadenas no necesariamente es lo que es. Porque no es lo mismo '1' que 1. Y no es lo mismo que ese '1' o 1 esté "bien acomodado" en sys bytes que esté "desplazado".

 

¿Y si lo que viene es justamente la interpretación binaria del peso? Porque eso justamente pareciera significar lo que dice en la página 15, si se utiliza la dichosa balanza en "modo Discreto". Lo que viene en el word1 (16bits) es un integer y ahí esta el valor del peso. Y justamente aqui rige eso último que dije: no es lo mismo '1' que 1. Si efectivamente viene el numero binariamente es lógico que el componente va a leer cualquier cosa. Podría arreglarse con hacer un casteo a integer de los caracteres en cuestión. No se puede usar StrToInt porque no va por ahí. Digo casteo.

Pero no termina ahí la cosa porque también depende de lo que hay en el campo Weight format y el Bit Shift. Dependiendo de eso se tiene que hacer una serie de corrimientos de bits, etc.

 

Asi que no queda otra que leerse bien la documentación de como es que funciona.

Porque claro que la cosa (el componente) nos presenta cadenas ¿Pero es en realidad su significado?... el tema es realmente interpretarlo. ¡quien te dice supongamos que si viene la cadena 'wq3#' y eso quiere decir intermante que hay 1,2 kg! Al 1, y al 2 ni lo vemos... (y puede que ni el separador decimal venga) pero el peso de que está ahí escondido seguro.

 

Es muy fácil decir que "son caracteres raros" y que la balanza no anda.

 

Saludos,

[egostar]

Yo digo que se use Hiperterminal y después hablamos.

 

Saludos

[Delphius]

Yo digo que se use Hiperterminal y después hablamos.

 

Saludos

 

¿Y si muestra los mismos caracteres raros?

 

EDITO:

Si luk nos pasa una copia del texto y no sólo la imágen podríamos jugar un poco a ver que bits se esconden detrás e intentar decodificarlo. Por la imagen, y pareciendo que recibe dos lineas, yo según la documentación me inclino a pensar que está en "modo discreto", la cadena1 (la primera, superior) se corresponde al valor y la 2da a la data de control, etc.

 

 

Saludos,

PD: Parece que mi madre tenía razón... como abogado hubiera sido uno bastante bueno

[egostar]

¿Y si muestra los mismos caracteres raros?

 

Saludos,

PD: Parece que mi madre tenía razón... como abogado hubiera sido uno bastante bueno

 

Bueno, pues ya estaríamos seguros, ¿no?

 

Saludos

[Delphius]

Bueno, pues ya estaríamos seguros, ¿no?

 

Saludos

 

Seguros de que yo tengo razón...

Hoy estoy peleon

 

Saludos,

[look]

Hola amigos , ya encontre la solucion , espero que no me arrojen tomates!.

 

prirmero he hecho unas pruebas con hiperterminal como recomendo egostar, resultado:

 

 

en fin , despues de seguir jugando con el puerto logre esto:

 

y guala! , ha funcionado, ¿ cual era el problema ?, pues hice muuuchas pruebas con todas las configuraciones posibles, pero por alguna razon se me escapo uno ," baud = 4800 y Bits = 7".

porfavor no me arrojen tomates!... .

 

En fin , tenia razon en algo , la simplicidad del aparato, al darle al boton de print en la balanza este escribe en el puerto, tal cual...

 

gracias amigos por tenerme paciencia, saludos!

[egostar]

Hola amigos , ya encontre la solucion , espero que no me arrojen tomates!.
 
prirmero he hecho unas pruebas con hiperterminal como recomendo egostar, resultado:
 

 
en fin , despues de seguir jugando con el puerto logre esto:

 
y guala! , ha funcionado, ¿ cual era el problema ?, pues hice muuuchas pruebas con todas las configuraciones posibles, pero por alguna razon se me escapo uno ," baud = 4800 y Bits = 7".
porfavor no me arrojen tomates!... .
 
En fin , tenia razon en algo , la simplicidad del aparato, al darle al boton de print en la balanza este escribe en el puerto, tal cual...
 
gracias amigos por tenerme paciencia, saludos!

Seguros de que yo tengo razón...
Hoy estoy peleon
 
Saludos,

 

     

 
Creo que ésta vez le he ganado al buen Marchello
 
Perdón, pero trabajar con puertos seriales desde 1989 algo me enseñó 

Saludos