Data From a Serial Port

sonny

Greetings all...

I am working with the Duet driver for the Apex Destiny 6100 and need to capture the event notifications from the device. It looks like the driver will only parse data it polled for, and not the 14NQ messages. So I set PASSBACK up to get the raw data, and wrote a parser to interpret it.

Several problems had to be overcome, however. First, during alarm conditions the Destiny would "burst" all event data, and I was getting multiple packets in one STRING event. No problem...just modified the parser to handle this. However, I noticed on occasion I would get, in essence, a framing error, where part of a packet would be in one event, and the rest in the next. Again, I addressed this in code.

So, a couple of questions for those of you that have experienced this. I guess there is real no way for the low level serial port handler to know that each packet ends in CR-LF, so how does it decide how much data to buffer before generating the DATA_EVENT? If there is a buffer size setting, I would think it would be setup in the Duet Module, and I can't think of a way to modify that. If I do CREATE_BUFFER in my code, and don't set PASSBACK, will the data look any different?

Thanks...

Marc Scheibein

The DATA_EVENT[] is triggered, depending on timing of Baudrate, if there is a break in data. The data sequence which has triggered the Event can be seen in DATA.TEXT of the event. But this still doesn't quarantee that the data.text content is complete and valid.

If operating the RS232 port directly (and much more important if parsing Ethernet data), a CREATE_BUFFER is recommended, to pick up all incoming data, and then parsing is done. If the data isn't a full protocol sequence or contents other invalid data, this must be parsed out until we have a valid data sequence from the device.

Device has $02 for start and $03 for end, a valid sequence has a length of 5 chars minimum

DATA_EVENT[dvVCR]
{
  ONLINE:
  {
    SEND_COMMAND DATA.DEVICE,'SET BAUD 9600,O,7,1'
  }
  STRING: // something was received from device
  { 
    STACK_VAR CHAR sTMP[30]
    WHILE(LENGTH_STRING(sVCR_BUFFER) >= 5) // parse as long as a valid data sequence may be in, this unit has responses of 5 characters minimum
    {
      IF(sVCR_BUFFER[1] = "$02") // found prefix of protocol
      {
        IF(FIND_STRING(sVCR_BUFFER,"$03",1)) // found suffix
        {
          sTMP = REMOVE_STRING(sVCR_BUFFER,"$03",1) // it's a valid data sequence
          // now check what we have received
          SELECT
          {
            ACTIVE(FIND_STRING(sTMP,"'OPL'",1)): { nVCR_STATUS = 1 } // play
            ACTIVE(FIND_STRING(sTMP,"'OSP'",1)): { nVCR_STATUS = 2 } // stop
            ACTIVE(FIND_STRING(sTMP,"'OPA'",1)): { nVCR_STATUS = 3 }
            ACTIVE(FIND_STRING(sTMP,"'OFF'",1)): { nVCR_STATUS = 4 }
            ACTIVE(FIND_STRING(sTMP,"'ORW'",1)): { nVCR_STATUS = 5 }
            ACTIVE(1): { nVCR_STATUS = 255 } // any other valid response
          }
        }
        ELSE // if no "$03" is found, prevent buffer overflow
        {
          IF(LENGTH_STRING(sVCR_BUFFER) >= (LENGTH_ARRAY(sVCR_BUFFER)-20))
          {
            sVCR_BUFFER = ''
          }
        }
      }
      ELSE // if no $02 at begin
      {
        GET_BUFFER_CHAR(sVCR_BUFFER)
      }
    }
  }
}

Because a DATA_EVENT[] only is executed once after trigger, it must be keeped alive until no valid data is still in buffer. Mostly this is done with a WHILE condition, but this depends on the protocol of the device controlled.

If Strings have to be received from a virtual or duet device, in most cases DATA.TEXT can be used directly because the string sent is created by the module and should be a valid data sequence, so the PASSBACK option also may sent back the data received on the com port as a valid data sequence. I used the Shure DCP1248 Duet module with PASSBACK enabled, and I got the device's Protocol always as complete string sequence from the Duet device. Maybe this depends on the Duet module handling and/or the device controlled if you get full data sequences from Duet device's PASSBACK.

NMarkRoberts

sonny wrote:

I guess there is real no way for the low level serial port handler to know that each packet ends in CR-LF, so how does it decide how much data to buffer before generating the DATA_EVENT?

This appears to be unknowable so it's best not to rely upon it in any way.

Most replies from serial boxes arrive in the buffer whole and complete; others trigger the data_event one or two characters at a time.

sonny

thanks for the replies...