Excessive cpu upon reading serial

Question

Hello!
I have created a program that reads in a message from a RS232 connection. the instrument sends the message every 30 seconds or so. 
it seems that after one reading of the message my program starts to use excessive cpu at higher than 50% levels. but this only happens when the reading case is active. in the reading case there is a file writer subvi, and in this one it shows that it only gets written to once per case, which is normal, which indicates that there is no infinite loop there, but I still experience a high CPU load.
This seems odd as I have a very very similar other program reading from rs485 that does not have this problem. 
I have tried to profile memory usage and higlight execution, but this seems to show nothing. 
I am using a windows Vista machine with loads of ram and cpu speed. I have attached my VI and a profiler log file.
Attachments:
ceil.vi ‏54 KB
ceilometer_memory.txt ‏110 KB

Answer 1

My first recommendation would be to not set the size of the buffer to 3993 bytes. Leave it at the default size of 4096. You don't want to fill up the buffer. I would probably make the buffer even larger since it gives you only 103 bytes of actual buffer between a full message waiting and the limit of the buffer. Try 8192.
I don't see any reason why should make the wait statement exactly 1664 ms just because that is how long it takes for the message to come in. You might be better off making the wait statement 30 seconds, the time between messages. However, based on some other changes that should be made, I would make it 1000 msec. That way there is some pause in the loop if needed, but the other changes will more effectively pace your loop.
Instead of reading bytes at port, since you know each message is exactly 3993, just read 3993 bytes. Make the timeout of the VISA port something larger than 30 seconds, perhaps 35-40.
A VISA read will wait until one of 3 things happen.
1. The requested number of bytes have been read.
2. The termination character has been read (if it has been enabled).
3. The timeout limit has been reached.
With a larger than 30 second timeout, you'll know that at least enough time was allotted for a complete message to come in even if you didn't happen to try the open the port and read the buffer until immediately after the last message came in.
The one problem with a serial communication scheme where you don't query for data and there is no disctinctive end of message character is that if you start reading the port in the middle of the first message, you really don't know where the message ends and the begining of the next message is. The trick is how to determine that you are reading the beginning of the message so that when you read 3993 bytes, you know you have a complete message, and not a mixed message.
I would open the port and configure it for a plenty large buffer (at least 4096 bytes if not 8192) and a 35-40 second timeout. In a loop, wait a second then read the bytes at port. If there are bytes, flush the port and repeat the loop. If there are zero bytes at the port, then it is probably safe to say you are in the dead time between messages, so exit the loop. Now you have an empty port and are in the dead time between messages, you can begin the real part of your program where you continually read the port and process the messages. Do that in a loop reading precisely 3993 bytes with the VISA read and process the string.