Speed of serial communication?

[natemoehring]

I am using cFP-2010 and LV RT 6.1 and would like to communicate with an external sensor via RS-232 at 115.2kbps. The network module communicates at this baudrate fine, but it does not seem to be able to keep up with a large amount of data on the serial port. The sensor is outputting a small packet at 100Hz, and I would like to capture each packet in real time, or as soon as possible. However, from what I can tell by experimenting, my VI is only able to retrieve a packet about every 100ms (10Hz). All of this extra data seems to build up in the UART buffer, which means I am in effect reading old data and will eventually recieve a buffer overflow error. I know I can manually clear the buffer before each read to only get new data, but I do
n't want to lose any data if possible. Also, the Serial Port Config VI has a parameter for buffer size but seems to be totally ignoring the value I give it (10 bytes). FYI, I also need to perform UDP communication in a separate loop with a much lower priority.

What is the maximum speed I can service the serial port (assuming minimal other load on the processor)? How can I improve my current acquisition rate?

Thanks for any help,
Nate

[Aaron_G]

Nate,

If you are willing to post your serial port routine code to this post, Developer Exchange members could look at your code and offer suggestions to improve performance.

Regards,
Aaron

[natemoehring]

Yes, I thought about that but didn't originally for two reasons. First, the code I am attaching is actually interfacing to a different sensor (sonar) than what I was referring to, but the code will be nearly the same. Second, I know this makes use of local variables rather extensively, which I am not happy with. If anybody knows a better way this should be coded I would love to hear it.

In this program I expect to receive a UDP packet every 50ms with new PWM values to control the output of 2 motors. I want to sample the sonar sensors as fast as possible via RS-232 to enable or disable the motors depending on the results of the sonar and the direction the robot is going. At one point I actually output a stop PWM inside the sonar su
bVI to stop the robot as soon as possible, but to make the sonar code more portable decided to remove this. I realize this means the reaction time will be a little longer because it must complete the reception of a new UDP packet before the results of the sonar will take place, oh well.

Again, if anybody has any suggestions on how to improve this code I would love to hear them. FYI, I run these VI's embedded, not using remote front panel.

[Ames]

Nate,

The controller has a 1600 byte hardware buffer. Once this is full, interrupts will be fired when new data is arriving which will force the processor to handle that piece of data coming from the serial port (possibly creating a priority inversion). Let me know if this math is wrong, but... since you are sending data at 115200 bits/s divide by 8 to get bytes is 14400 bytes/s. Divide that by what you are reading per iteration you get ~2280 Hz, which is way faster than you are going to get on the current FieldPoint controllers. So if instead you read more like 150 bytes per iteration it is more like 96 Hz. You could then set a wait until next millisecond multiple in your loop of maybe 11 ms and you shouldn't have any problems (you will proba
bly need to take into account your other loops, so you will have to read a bit more data at once). I am not sure if you can modify your application to work in this fashion, but I don't think there is anyway it can reliably handle the data rate you are currently using on the serial port with the current software configuration.

Ames

[natemoehring]

Thank you for the response. Yes, I had also considered the possibility of just reading the entire buffer each time and basically parsing all the data for SOHs, chksums, and data. In this case I would probably just log the elapsed data and only use the most recent data for motion control. I was just hoping there was some way around it. The 1600 byte buffer is useful to know, where did you learn that?

[Ames]

Nate,

I found a Knowledge Base that talked about it... here is the link:

http://digital.ni.com/public.nsf/websearch/3E10F35B2590D48E86256D51004DCC1C?OpenDocument

Ames