Find String runtime error

Rich Abel

This is driving me nuts...maybe some fresh eyes will see my error?

I am getting a runtime error as follows:

(0000101697) DVD DATA_EVENT HAS OCCURRED
(0000101700) CIpLibrary::Find_String - Error 2
(0000101701) Library Call error on Line 196

from code that is parsing a response from an ARCAM dvd player in its DATA_EVENT


DATA_EVENT[dvDVD]
{
ONLINE:
{
SEND_COMMAND dvDVD,"'SET BAUD 19200,N,8,1,485 DISABLE'"
}
STRING:
{
cDVD_BUFFER = "cDVD_BUFFER,DATA.TEXT" // POPULATE BUFFER
nEND = FIND_STRING(cDVD_BUFFER,13,1) // FIND END
cDVD_WORKBUF = LEFT_STRING(cDVD_BUFFER,nEND) // COPY TO WORKING BUFFER
cREPLY_CODE = MID_STRING(cDVD_WORKBUF,2,1) // EXTRACT RESPONSE CODE
cANS_CODE = MID_STRING(cDVD_WORKBUF,3,1) // EXTRACT ANSWER CODE
cPARAM1 = MID_STRING(cDVD_WORKBUF,4,1) // EXTRACT PARAMATER 1
cPARAM2 = MID_STRING(cDVD_WORKBUF,5,1) // EXTRACT PARAMATER 2
cPARAM3 = MID_STRING(cDVD_WORKBUF,6,1) // EXTRACT PARAMATER 3
etc, etc.
}
}

When I watch cDVD_WORKBUF in the debugger window it is never populated. nEND is never assigned a non zero value.

The Find_String on cDVD_BUFFER seems to be the culprit.

Anyone see the issue?

Thanks,

Rich Abel

mpullin

You should consider putting CREATE_BUFFER dvDVD, cDVD_BUFFER in your define_start and eliminating the line ending in // POPULATE BUFFER. The CREATE_BUFFER command manages your buffer for you.

I don't see anything obviously wrong with this code.. if nEND is 0, that means that the FIND_STRING function resulted in an error. Perhaps it did not find a CR in the string it received from the device? Do Diagnostics->Device Notifications to look at what your device is sending you.

Rich Abel

Find String Runtime Error

Thanks for the suggestions Matt.

I do see the carriage return in cDVD_BUFFER in the debug window, yet the Find_String fails.

I'll try the alternate buffer handling, although I haven't had issues with the

buffer = "buffer,data.text"

in the past.

Seems that the problem lies in the Find_string....

Chip Moody

First I would wrap that 13 in quotes:

nEND = FIND_STRING(cDVD_BUFFER,"13",1) // FIND END

To make sure the compiler/interpreter treats it as a string.

Second, I would modify the code just a bit to prevent it from unnecessarily running code in the case where you haven't gotten a complete response from the unit: (this also assumes you've already done the CREATE_BUFFER suggestion)

STRING:
{
  nEND = FIND_STRING(cDVD_BUFFER,"13",1) // FIND END
  IF (nEND)  // If nEND is non-zero, it means there was actually a carriage return there
  {
    cDVD_WORKBUF = LEFT_STRING(cDVD_BUFFER,nEND) // COPY TO WORKING BUFFER
    cREPLY_CODE = MID_STRING(cDVD_WORKBUF,2,1) // EXTRACT RESPONSE CODE
    cANS_CODE = MID_STRING(cDVD_WORKBUF,3,1) // EXTRACT ANSWER CODE
    cPARAM1 = MID_STRING(cDVD_WORKBUF,4,1) // EXTRACT PARAMATER 1
    cPARAM2 = MID_STRING(cDVD_WORKBUF,5,1) // EXTRACT PARAMATER 2
    cPARAM3 = MID_STRING(cDVD_WORKBUF,6,1) // EXTRACT PARAMATER 3
    // etc, etc.
  }
}

Your code also presumes that there wasn't any other garbage in the buffer preceeding the response you expected, and that none of the response was lost. Instead of starting your extraction with the first character in WORKBUF, I would instead base the extraction positions on the end of the string - since you know what that is for certain. If this device always only sends the same length message, you might want to do a check on LENGTH_STRING (cDVD_WORKBUF) right after the LEFT_STRING.

Don't forget to clear out your buffer, too - LEFT_STRING will give you the characters you want to decipher, but will never clear them out of cDVD_BUFFER. Try REMOVE_STRING (cDVD_BUFFER,"13",1) instead of the LEFT_STRING perhaps...

- Chip

Chip Moody

I guess I'm feeling chatty today.

I always try to code for extreme conditions - even if they never happen, it can't hurt, and it's more satisfying to an anal-retentive like myself.

That said, here's what I almost always do with any kind of serial port buffer where the responses that come in ALWAYS have the same delimiter. (I.E., 99% of the time)

This also assumes that your CREATE_BUFFER was established in DEFINE_START.

DATA_EVENT [RS232Device]
{
  ONLINE:
  {
    // yeah, yeah - we all know what goes here
  }
  STRING:
  {
    WHILE (FIND_STRING(MyBuffer,"delimiter",1))
    {
      MyMessage = REMOVE_STRING(MyBuffer,"delimiter",1))
      // now parse contents of MyMessage
    }
  }
}

The parsing won't take place unless the delimiter was part of the most recent data coming in the com port that triggered the event, and in the off chance that the device snuck TWO messages into the buffer before the event triggered, (yes, I've seen that happen) it makes sure that every response that may be in the buffer is processed before exiting. This also clears messages out of the buffer while leaving any potential partial messages there. (To be processed next time the event fires and the delimiter is found)

- Chip

mpullin

Chip Moody wrote:

First I would wrap that 13 in quotes:

nEND = FIND_STRING(cDVD_BUFFER,"13",1) // FIND END

To make sure the compiler/interpreter treats it as a string.

Good call, I bet that's what it is. Here I was thinking that it had to be something wrong with the contents of cDVD_BUFFER!

DHawthorne

mpullin wrote:

Good call, I bet that's what it is. Here I was thinking that it had to be something wrong with the contents of cDVD_BUFFER!

I would say it's definitely what the problem is, or at the least "a" problem. Functions that are looking for a string as a parameter do not interpret a single character properly unless it's in the double quotes. This applies to all the string functions.

Rich Abel

Thanks

Thanks to all who responded. As you noted, there were several issues.

Your comments were very helpful.

Rich