String: Question
ondrovic
Posts: 217
I am trying to get info from a rs232 device and I have setup this so far
but all i am getting in debug under strDVD_Buffer is [][][] any ideas on where i went wrong?
Thanks
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
0
Comments
Also, not sure why you're doing this when you could use CREATE_BUFFER. That automatically puts data from your device into a variable.
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
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.
The key is 8-bit unsigned. The help file also states a range between 0-255.
ASCII negatives? There?s no such thing. ASCII is simply a standard that defines a character set, it?s not a data type.
Huh?
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.
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)) { } }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>
for example.
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
- Chip
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
It was a blonde moment the display type was wrong, thought i had it changed