Are LWRS_RXFLAG COM callbacks called in succession at fast speeds?

[DanP]

I am trying to parse a packet which contains merit values returned from multiple sensors over the RS232 port. A typical packet looks something like this:

1P=515
1M=877
1S=412
1C=871
2F=777
$

Now, the problem is that as many as 2000 of these packets could be returned from the sensors every minute. I have installed a COM callback function with the event LWRS_RXFLAG set to '$'. In the COM callback, it reads until it encounters the termination byte '$', parses the buffer, and returns. At high rates of speed, I am getting stack overflow errors when running the program. When I take a look at my executable in task manager, over time the memory usage of the execuatable slowly grows and grows. My ques
tion is this, are multiple calls to the COM callback function being made at the same time? Or is it called in succession, i.e. looking at the beginning of the input queue, every time there is a $ the function is called one time, and then returns. There is a lot going on in my callback function, I am plotting a histogram and a strip chart, and sometimes writing to a file. I simply cannot parse the data quickly enough, but that's fine as long as there aren't multiple threads being created with multiple calls to the function at the same time.

Thanks.

[bilalD]

Hello

A better way to handle something like this would be to use LWRS_RECEIVE as the callback flag. So this way, you will be able to process multiple packets in one callback instead of getting each individual packet. The documentation states that you might miss events if the callbacks come at a high rate, and if you use LWRS_RXFLAG as the callback flag.

I hope this helps

Bilal Durrani
NI

[DanP]

My packets are coming over the RS232 port at such a high rate of speed that once the LWRS_RECEIVE callback function was called, it would never return until the sensor's stopped spitting out data. Could I simply create a loop in the callback function with a ComRdTerm call that would read one packet at a time until the input queue was empty? Would you suggest this as a better alternative?

Thanks.

[bilalD]

Inside the callback, you should get the number of bytes available at the port using GetInQLen(), do the read operation, and then parse what you just read and return. Perhaps the reason why it wont return is that the Com read operation is waiting for the number of bytes to come into the port. Also, when installing the callback, you can also set the notify count parameter to the amount of data you are expecting to process, so that the callback will ony fire if the number of bytes at the port goes above a certain value

Bilal

[DanP]

Thanks for your response. If I do what you describe, at high rates of speed the input queue will contain more than one packet with each packet being terminated with a $. I need to parse the contents of each packet individually, if I read more than one packet at the same time into a buffer, how would I do this? The buffer could look something like this:

1P=564
1M=687
1S=132
1C=867
$
1P=451
1M=657
1S=872
1C=153 ...etc

I'd need to separate the packets and then parse them individually.

[DanP]

Also, if I use the GetInQLen method, there is the possibility I would only get half a packet, I need to get a full packet at once.

[bilalD]

Yup, that sounds right. You will need to read in the string buffer. You can use the Fmt() or the strtok() function to parse out the functions. You can setup a queing system so that if you get half the packet in one case, the next time the callback runs, you can combine it.
Or you could alway read from the port in multiples of the packet size so you're always reading a bunch of packets at the same time. You might also need to make sure thatthe first time it sends you data, it doenst throw in a header somewhere. That might mess up your alignment.

[DanP]

How would I use the Fmt() function to split a large buffer up into the individual packets? I'm not having much luck using strtok. My probably is more difficult than I first though because depending on our customer, the packets come over the RS232 port at varying rates of speed. Also, the packets are not always a set length because the size of the numbers are different.