Home AMX User Forum NetLinx Studio

String: Question

ondrovicondrovic Junior MemberPosts: 217
I am trying to get info from a rs232 device and I have setup this so far
STRING:
    {
        IF(FIND_STRING(DATA.TEXT,"13",1))
	{
	    strDVD_BUFFER = DATA.TEXT
	    
	}
    }

but all i am getting in debug under strDVD_Buffer is [][][] any ideas on where i went wrong?

Thanks

Comments

  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    I don't know... what's [][][]? In the debugger, choose to look at decimal and not ascii.

    Also, not sure why you're doing this when you could use CREATE_BUFFER. That automatically puts data from your device into a variable.
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    can you show us your variable declaration. Perhaps you've formatted it incorrectly. Another thought is you have the baud rate and/or communications protocol set incorrectly on the serial port. You might be getting garbled messages.
  • ondrovicondrovic Junior Member Posts: 217
    ericmedley wrote:
    can you show us your variable declaration. Perhaps you've formatted it incorrectly. Another thought is you have the baud rate and/or communications protocol set incorrectly on the serial port. You might be getting garbled messages.
    CHAR strDVD_BUFFER[200]			/// Dvd Buffer
    CHAR strRESPONSE[3]			/// Response String
    CHAR strDATA[3]				/// Data String
    CHAR strDISC_TYPE[20]			/// Disc Type String
    CHAR strDVD_COMMAND[30]			/// Dvd Command
    
    
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    ondrovic wrote:
    CHAR strDVD_BUFFER[200]			/// Dvd Buffer
    CHAR strRESPONSE[3]			/// Response String
    CHAR strDATA[3]				/// Data String
    CHAR strDISC_TYPE[20]			/// Disc Type String
    CHAR strDVD_COMMAND[30]			/// Dvd Command
    
    

    I may be way off base on this but...
    I believe that you don't need the CHAR. That makes the variable an ANSI string. I think that cuts off the use of HEX values below $20.

    You're using charactors outside the ANSI standard.

    Try just taking out the CHAR before all those and making them

    strDVD_BUFFER[200]

    See if that helps.

    ejm
  • Joe HebertJoe Hebert Junior Member Posts: 2,159
    ericmedley wrote:
    I may be way off base on this but...
    I believe that you don't need the CHAR. That makes the variable an ANSI string. I think that cuts off the use of HEX values below $20.
    Yes, off base and not true. A CHAR is a byte that can range anywhere from $00 thru $FF. All the buffers I declare are CHAR arrays.

    There is not much to go on with what?s been posted so far but I would go with Matt?s original advice and choose to view as decimal (or hex) instead of ASCII.
  • ondrovicondrovic Junior Member Posts: 217
    Thanks guys will give that a shot and report back
  • ondrovicondrovic Junior Member Posts: 217
    hmmm that didnt work still getting the weird feedback under the buffer
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    Joe Hebert wrote:
    Yes, off base and not true. A CHAR is a byte that can range anywhere from $00 thru $FF. All the buffers I declare are CHAR arrays.

    There is not much to go on with what’s been posted so far but I would go with Matt’s original advice and choose to view as decimal (or hex) instead of ASCII.

    I did some grunt and groan checking of my own. The default of not declaring a variable with a dimension is a CHAR. However, my assesment of ANSI is correct. ANSI and ASCII are not the same charactor set. The Netlinx Help definition says, "
    CHAR
    An intrinsic data type representing an 8-bit unsigned integer. This data type is intended for use with ANSI character strings."


    ASCII is a 7-bit data type. It's 0 through 127 decimal. ANSI is 128-255 and is 8-bit. There is a difference. with a 7-bit number an $FF is considered to be a negative number. If it's 8-bit, then it's a positive number. So, if a device is using the ASCII standard and sends out a value of $FF it's intending it to be a negative 1. If you do math on the CHAR (if the definition was consistent with standards) what may actually intended to be a negative number is treated as a positve.

    So, if what you're saying is true (and it is) the help should say ANSI and ASCII character strings. and that ASCII negatives are converted to positve. Most times we're not dealing with any mixed strings. (text and raw values.) but I do still work with some devices that return something along the lines of G,A,I,N,:,$23 and that means the gain is now 23 units. But the ASCII string looks like 'GAIN:#'

    If all serial controlled devices ever get to the point of everyone using UNICODE this will go away.

    I have never declared my arrays with the CHAR due to my understanding that it was intended for use with ANSI. Perhaps they should change the help file.
  • Joe HebertJoe Hebert Junior Member Posts: 2,159
    ericmedley wrote:
    ASCII is a 7-bit data type.
    I hate to be argumentative but ASCII is not a data type.
    ericmedley wrote:
    The Netlinx Help definition says, "
    CHAR
    An intrinsic data type representing an 8-bit unsigned integer. This data type is intended for use with ANSI character strings."

    So, if what you're saying is true (and it is) the help should say ANSI and ASCII character strings.
    The key is 8-bit unsigned. The help file also states a range between 0-255.
    ericmedley wrote:
    and that ASCII negatives are converted to positve.
    ASCII negatives? There?s no such thing. ASCII is simply a standard that defines a character set, it?s not a data type.
    ericmedley wrote:
    So, if a device is using the ASCII standard and sends out a value of $FF it's intending it to be a negative
    Huh?
    ericmedley wrote:
    Most times we're not dealing with any mixed strings. (text and raw values.) but I do still work with some devices that return something along the lines of G,A,I,N,:,$23 and that means the gain is now 23 units. But the ASCII string looks like 'GAIN:#'
    ericmedley wrote:
    If all serial controlled devices ever get to the point of everyone using UNICODE this will go away.

    SEND_STRING dvSwit, ??GAIN:?,$23?
    and
    SEND_STRING dvSwit, ??GAIN:#??
    Are transmitted over the wires exactly the same.

    You can interpret the data any way you want. You can think of 255 as 1111 1111 or $FF or as the y with the two dots above it. But the bottom line is that a CHAR is simply an 8-bit unsigned container that can hold a value between $00-$FF.
  • joelwjoelw Junior Member Posts: 175
    Append data to your buffer when not using CREATE_BUFFER
    ondrovic wrote:
    I am trying to get info from a rs232 device and I have setup this so far
    STRING:
        {
            IF(FIND_STRING(DATA.TEXT,"13",1))
    	{
    	    strDVD_BUFFER = DATA.TEXT
    	    
    	}
        }
    

    but all i am getting in debug under strDVD_Buffer is [][][] any ideas on where i went wrong?

    Thanks

    To address the [][][] change the debug variable display type.

    When not using the CREATE_BUFFER keyword, you need to manually append incoming data to your buffer. The code below does this.
    STRING:
        {
            strDVD_BUFFER = "strDVD_BUFFER,DATA.TEXT"
    
            IF(FIND_STRING(strDVD_BUFFER,"13",1))
    	{
    	    
    	}
        }
    
  • HedbergHedberg Junior Member Posts: 671
    Tech notes are your friends.

    Technote 616 discusses parsing serial buffers. It provides an example of how to handle your buffer (using a WHILE loop ) so that it is much more likely that you not try to process an incomplete string. This topic comes up in the forums frequently, so searching the forums can turn up interesting discussions. This thread

    <http://www.amxforums.com/showthread.php?t=2075&highlight=buffer+parsing&gt;

    for example.
  • DHawthorneDHawthorne Old Timer Posts: 4,584
    The odd characters strongly suggest to me the baud rate is incorrect. Those little rectangles are the Windows way of representing any character the font does not have a displayable glyph for.

    However, if the protocol does not send back a readable character set, they could be perfectly normal. What are you expecting for a return? I've found in such cases it's far easier to set the debugger, or whatever you are using to look at the buffer, to display in either decimal or hex. It usually is more informative for non-printing characters.

    As to the whole CHAR discussion - a CHAR is 0-255. Nothing else to it. ASCII and ANSI are just ways of representing those numbers (just like hex or decimal). If the raw value (in decimal), is 35, you can represent it in hex as $23, or in ASCII as '#', but its the same number in the variable storage. The only difference is how you are writing the notation; it's still critically important, because the way you write it determines how the compiler will interpret the number. But in the end, it's the same number.

    ANSI is something else again. It's essentially a terminal display scheme and has nothing to do with the data itself. Each ANSI character is a set of ASCII characters telling a terminal how to display a character, and includes things like color, italics, cursor movement, etc. http://en.wikipedia.org/wiki/ANSI_escape_code
  • ondrovicondrovic Junior Member Posts: 217
    thanks guys finally got it working
  • Chip MoodyChip Moody Junior Member Posts: 727
    And you're not going to tell us what the solution was? Fine - just leave us hanging... :)

    - Chip
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    a brutal smack down. I stand corrected...

    I do understand all your points and I, myself don't even care about such things. I just do the same thing as you and don't worry about ACSII and/or ANSI. I've always avoided the CHAR in the first place because not putting it in front of the variable declaration does the exact same thing. I don't care what format the data comes back. I just want it to do what I want.



    The whole discussion was of no importance... It was more of a intellectual exercise that is of no use in today's world.



    Just ignore me...
    :)
    later
  • ondrovicondrovic Junior Member Posts: 217
    Chip Moody wrote:
    And you're not going to tell us what the solution was? Fine - just leave us hanging... :)

    - Chip
    Sorry chip :)

    It was a blonde moment the display type was wrong, thought i had it changed
Sign In or Register to comment.