GetInQLen 사용에 관하여

[YulDo]

RS232-C to USB 통하여 데이터를 주고 받습니다.

Return_N = OpenComConfig (UART_Port, Text_Data, 460800, 0, 8, 1, 20480, 1024);

연결된 상태에서 스레드를 이용하여 

while (1)

{

  Rd_Qlen = GetInQLen (UART_Port);

  if(0 < Rd_Qlen)

  {

    ComRd (UART_Port, Rd_Data, 36);

  }

}

데이터를 읽어옵니다.

대략 13ms 단위로 36 Byte 보내오고 쌓이는데로 읽어오는데 3~4시간 정도 지나니 버퍼가 급격히 쌓이면서 종료됩니다.

버퍼가 쌓이지 않고 처리가 가능한지 궁금합니다.

[RobertoBozzolo]

According to Google, your question recitates:

36 Bytes are sent at approximately 13ms intervals and are read as they accumulate. After about 3 to 4 hours, the buffer accumulates rapidly and ends.

Can you explain a bit what "buffer accumulates rapidly and ends"?

If possible write directly in English just to exclude problems in using automatic translators.

Additionally, if you have Full Development System release of CVI you can enable Resource Tracking by setting the debugging level to Extended in Build Options. This will help you in determining if there is some memory leak in the program, since when you terminate it a window will appear listing all memory buffers allocated but not freed in program life, if they exist.

[YulDo]

36 bytes of data are received at 13 msec intervals for log storage and program expression. After approximately 3 to 4 hours, the software stops or terminates abnormally.
After checking the cause, it seems that all the data in the buffer storing the received data was not processed and was gradually accumulating. After 3 hours, a lot of data was not being processed and was accumulating, eventually causing an overflow.
Below is a log showing that the capacity of the memory (buffer) storing the received data is gradually increasing.
I don't know why the data received at the beginning (approximately 1 hour later) cannot be processed and continues to accumulate after a certain period of time.
Below is a track of the data the incoming buffer accumulates over time.
Does data start accumulating in the buffer after 1-2 hours?

>> Test Start  [Time H:M:S] QLen

[11:46:31.89] 0
[11:46:31.89] 0
[11:46:31.90] 36
[11:46:31.90] 0
[11:46:31.91] 36
[11:46:31.92] 0
[11:46:31.92] 36
[11:46:31.93] 0
[11:46:31.93] 36

>> Test  1h 30m  [Time H:M:S] QLen

[13:14:00.40] 36
[13:14:00.41] 36
[13:14:00.42] 36
[13:14:00.44] 36
[13:14:00.45] 36
[13:14:00.46] 36
[13:14:00.48] 72
[13:14:00.49] 72

....

[13:30:47.63] 108
[13:30:47.63] 108
[13:30:47.64] 72
[13:30:47.66] 108
[13:30:47.67] 72
[13:30:47.67] 72
[13:30:47.71] 144
[13:30:47.71] 108

....

[13:35:35.96] 4140
[13:35:35.99] 4176
[13:35:36.00] 4176
[13:35:36.01] 4176
[13:35:36.03] 4212

....

[13:47:39.59] 65536
[13:47:39.60] 65536
[13:47:39.62] 65536
[13:47:39.63] 65500
[13:47:39.64] 65500
[13:47:39.66] 65536
[13:47:39.67] 65500

Force quit.

[RobertoBozzolo · Accepted solution]

You probably just need to iterate the reading until the queue is empty. From the log can be seen that every time you read 36 bytes regardless the length of the input queue, so the buffer gradually fills up ultimately making the program to crash.

Additionally, you should verify the reading function, since it appears to be not fast enough: if the reader cannot keep with writer rate you will always have problems even if you fix the receiving section.

Finally, I suggest you to set OutputQueueSize parameter in OpenComCoonfig () to -1: it makes the program more efficient since it skips Windows buffer and writes directly to the port. See function documentation on this item.