Velocidad de comunicacion Rs232

[muguerza]

Hola a todos:

Tengo un problema con la comunicación entre un PC y una máquina.

Mi código:
/*********/

// FlushInQ (com_port); /* Lento */
ComRd (com_port, MsgRx, NBYTESTRAMA);

if (err = ReturnRS232Err())/* Tratamiento de error */
MessagePopup ("ATENCION",GetRS232ErrorString(err));

//FlushInQ (com_port); /* rapido */

/***********/

tengo colocado FlushQIn en dos posiciones.

Si empleo la definida como 'rapido', generalmente no tengo problemas de comunicación.Sólo alguna vez me ha hecho algo extraño como por ejemplo darme un error cuando no debe. Yo supongo que es porque desde que límpio la linea serie hasta que vuelvo a leer puede pasar mucho tiempo ya que la máquina realiza trabajo y el PC tiene que l
eer las tarjetas de adquisición, refrescar pantalla etc.

Pero si empleo FlusQIn en la posicion de 'lento', la cosa va mucho peor. La comunicación es muy lenta, comienzo a tener solapamiento de datos y alfinal termina por bloquearse el movimiento de la máquina.

Me podeis decir como puedo hacer una comunicación rápida a la vez que segura en el tratamiento de los datos?

Un saludo

Eneko

[Jattie]

Eneko,

Pardon mi tentativa d�bil en intentar explicar en espa�ol. Utilizo un traductor del lenguaje as� que espero el sentido de las
marcas de la explicaci�n despu�s de la traducci�n.

Para intentarle y ayudar que necesito entenderle aplicaci�n mejor. Hay dos maneras de recibir datos seriales. El primer deber�a votar el dispositivo serial y el proceso los datos
y el segundo ser�a recibir una secuencia de datos continua o
sincronizada del intervalo que viene del dispositivo serial. Siempre que tenga una opci�n mi preferance debe votar (pida el
dispositivo datos) cuando soy listo procesarlo.

De acuerdo con que usted el ejemplo es se parece como si usted reciba
una secuencia continua de datos y entonces borrando el almacenador
intermediario antes de que le�do usted destruya los datos ya en el
almacenador intermediario y le tienen que esperar el dispositivo para
retransmitir antes de que haya datos v�lidos y el acceso de
comunicaci�n ley� el ciclo esperar� el untill o recibe datos del
bufer o el untill el per�odo del descanso fue alcanzado. (el valor por defecto es 5 segundos).

Para ayudarle tan que necesito mejor saber un par de cosas.

1. �Tengo raz�n en si se asume que usted recibe datos en un intervalo
fijo del dispositivo serial?
2. �Cu�l es retraso entre las transmisiones?
3. Cu�l es la longitud de la cadena de los datos vuelta, �y es la misma longitud cada vez?
4. �Hay un car�cter o un conjunto espec�fico de caracteres que indican
el extremo de la cadena de los datos?

For clarity sake, my reply in English:

Eneko,

In order to try and help you I need to understand you application better. There is two ways of of receiving serial data. The first would be to poll the serial device and the process the data and the second would be to receive a continuous or a timed interval data stream coming from the serial device. Whenever I have a choice my preferance is to poll (ask the device for data) when I am ready to process it.

Based on you example is seems as if you receive a continuous stream of data and then by clearing the buffer before a read you destroy the data already in the buffer and you have to wait for the device to retransmit before there is valid data and the communication port read cycle will wait untill it either receives data from the bufer or untill the timeout period was reached. (default value is 5 seconds).

So in order to help you better I need to know a couple of things.

1. Am i right in assuming that you receive data at a fixed interval from the serial device?
2. What is the time delay between transmissions?
3. What is the length of the data string returned, and is it the same length every time?
4. Is there a specific character or set of characters indicating the end of the data string?

[muguerza]

Hy Jattie:

Thanks for your answer. I'll try to explain in my bad english.

1. Am i right in assuming that you receive data at a fixed interval from the serial device?

Yes, it depends of the diffents kind of works that have to make the machine but when you selection a kind of work, the time is fixed for all the process.

2. What is the time delay between transmissions?

the faster transmission in one kind of work is 200milliseconds and a slowest work is 0.6 seconds.(Here is my dude.Can my matters come when coincide the read of datos from the buffer with another PC operations? I want to say , read data aquisitions cards o refresh the draws in the screen...)


3. What is the length of the data string returned, and is it the same length every time?


The sring in all cases is the same , NBYTESTRAMA=5bytes

4. Is there a specific character or set of characters indicating the end of the data string?"
Yes, received byte1 is always 0x02 . The rest of the bytes may change.

I hope, this information can be enough for you.Next week because of work , I've to go abroad so I can't talk with you until next 28 of June.

But let me know your ideas. Thanks for all.

Eneko

[Jattie]

Eneko,

let me try and help you resolve your issue by starting with an explanation of how the serial hardware and software works together.

When you initialise and/ or open the serial port for communication you basically set a buffer size that determines how much data you can store from the serial device. Servicing a serial port routine at a 200ms interval is really driving your system on a windows environment pretty close to it's limits. A very fast CPU and lots of memory migt make this more achievable but in my experience with serial data on windows, 200ms cycle times on a serial port is driving it hard.

You have to consider your baudrate as well and although 5 bytes is a small amount of data at a baudrate of 9600 it wil take approximately 150ms to clock in all the data.

This means that if you transmit data every 200ms you will have to keep track of the service time between your cycles servicing the serial port and of you exeeded 200ms and even went as far as 400ms you will have two sets of data to process.

There is a couple of solutions to get around these timing issues. Since the data will remain in the buffer in any case untill it is read you might as well read a couple of transmissions at a slower rate than 200ms. The down side to this approach is that you might read only half a data stream so that is why I asked you if there was a specific termination character. This will ensure that you only read the data untill you receive a termination chacter or string. for this you can use the comreadterm function.

On clearing buffers I would advise you to only use that once, because of your high data rate you can never gaurentee that you will not clear part of a data string from the buffer, so rateher use a read a string, look for the termination characters in the string and test the string format to ensure that it conforms to the known format and the process it for your data values. Plot or write these to file or a graph then at a slower rate and do 5 reads every second for instance. This will reduce the CPU overhead.

If this is not a suitable appraoch you can generate an event every time there is serial data in the comm buffer and use a similar appraoch to read it by looking for a string terminator. This will ensure that you do not chop the head off another string coming in by clearing the buffers.

Hope this helps.

PS: Was my spanish that bad that you switched over to english? 🐵

[muguerza]

Hi jattie:

Thanks for your information.I'll try to use it for the best.

I understood all your spanish letter but to make a good explanation I thought that my bad english would be better for you.

Thanks for all.

Yours faithfully.

Eneko