nrComm data loss

[El Cid]

I am using the nrComm component in CBC 2009 and receiving data via the AfterReceive event.

Another system is sending data in bursts of 8 to 25 bytes in a repeating cycle of 28 messages. Most of these messages are received without problem, but some messages (numbers 4 to 11 in the cycle) are never received.

Another terminal programme on my PC confirms that these missing messages are being received by my hardware but the AfterReceive event never admits to seeing them.

Any suggestions on why some bytes are lost by the receiver?

[Roman Novgorodov]

Hello

The TnrComm AfterReceive event is old and reliable way for monitor and get all incoming data.
I don't see your code - possible you are doing something wrong in your program.
You can try demos\Codes\codes_demo.bpr demo. It show codes of all incoming bytes. Does this demo lose data too?

Also maybe the following topic will be useful:
http://forums.nrcommlib.com/index.php?topic=8.0

BTW you should understand that data corruption and losing is ordinary in serial communication especially on long wire lines.
You program and your transfer protocol should handle such troubles.

And last. If you are using cracked or trial version of product, it has limitation on received data size ;-)

Roman Novgorodov
DeepSoftware.Com
forums.nrCommLib.com

[El Cid]

It is a licenced version of you product.

The data cable is 1-2 metres.  If it was merely data loss I would expect it to be more random.

The codes_demo project DOES receive all the expected data.

I was not implying that the nrComm component did not work, merely hoping to get the benifit of your intimate knowledge of the component and how it works.

I have looked at the forum topic and found some interesting items, including the 'some notes about OnAfterReceive event'.

As far as I am aware my code complies with these requirements. The skeleton of it is :-

void __fastcall TUGV_Form::nrComm1AfterReceive(TObject *Com, Pointer Buffer, DWORD Received)
{
   char           buff[256], *cp, d;
   unsigned       i, lim;

   i = 0;
   cp = (char*) Buffer;
   while (i++ < Received) {
      switch (rcv_state) {
         case RCV_IDLE:
            d = *cp;
            if (d == (char) MON_SYNC) {
               received = 1;
               sp = mon_buff;
               *(sp++) = *(cp++);
               mon_rec = (T_mon_rec*) mon_buff;
               rcv_state = RCV_GOT_SYNC;
               }
            break;
         case RCV_GOT_SYNC:
            *(sp++) = *(cp++);
            if (++received >= sizeof (T_mon_rec)) {
               rec_size = sizeof (T_mon_rec) + mon_rec->size;
               rcv_state = RCV_GOT_LEN;
               }
            break;
         case RCV_GOT_LEN:
            *(sp++) = *(cp++);
            if (++received < rec_size) {
                        rcv_state = RCV_GOT_MESSAGE;
               }
            break;
         case RCV_GOT_MESSAGE:
            if (log_fd) {
               fwrite (mon_buff, rec_size, 1, log_fd);
               }
            switch (mon_rec->id) {
               case 1:
               ........
               case 28:
               }
         
         }
      }
}

An assistance you can offer would be greatly appreciated.

Regards

[El Cid]

I have modified my code to use your data processor component.  Packets of a start and length.  Result :- of packets with IDs 1 to 28, 3 4 5 6 7 8 10 11 12 13 14 15 and 16 are not detected although the code_demo project detects them.

This is becoming an intriguing problems.

[Roman Novgorodov]

Hello

I wanted to recommend you to try TnrDataProcessor component :-)

Please give me more details about your protocol and we will prepare simple demo is based on data processor and you will try it.

Roman Novgorodov
DeepSoftware.Com
Forums.nrCommLib.Com