Still trying to figure out buffers
normschaef
Posts: 17
All:
I know what buffers are and how they work, but what I don't seem to get is how to build strings from DATA.TXT to fill them. Here's what I've done.
Declare the buffer
The problem is as soon as another string of DATA.TEXT comes in, it overwrites what's displaying on my "monitor window." (The button is about a 1/4 of the MST-701 panel I'm using.)
Is the data coming in being concatenated up to the buffer limit or do I need create a function to concatenate the pieces that DATA.TEXT sends?
Thanks for your help.
Norm
I know what buffers are and how they work, but what I don't seem to get is how to build strings from DATA.TXT to fill them. Here's what I've done.
Declare the buffer
DEFINE_VARIABLE char myBufferOfStuff[2000] . . . DEFINE_START CREATE_BUFFER dvMyDevice, myBufferOfStuff . . . DATA_EVENT [dvMyDevice] STRING: { myBufferOfStuff = DATA.TEXT SEND_COMMAND dvMyTP, "'^TXT-100,0,'myBufferOfStuff" //a pseudo-monitoring window so I can see what's coming in from dvMyDevice }
The problem is as soon as another string of DATA.TEXT comes in, it overwrites what's displaying on my "monitor window." (The button is about a 1/4 of the MST-701 panel I'm using.)
Is the data coming in being concatenated up to the buffer limit or do I need create a function to concatenate the pieces that DATA.TEXT sends?
Thanks for your help.
Norm
0
Comments
Just comment the line "myBufferOfStuff = DATA.TEXT".
CREATE_BUFFER is used to tell the system to put the data for "dvMyDevice" into the buffer.
Just SEARCH & REMOVE the part of the Buffer you are interested in; usually a line terminator.
Instead of sending the string in question to the TP for examination - send it to terminal instead.
so something like
Send_String 0, myBufferOfStuff;
the think you'll want to do is use a good terminal program. There's one built into Netlinx Stduio. I like to use puTTY. but either way just telnet into your master at it's IP address. Then once you see the Welcome prompt send it the MSG ON command. that will turn on diagnostic messages.
Now, whenever your data.text event happens, you'll see a print out in the terminal window. You'll have a nice complete record or the whole transaction that you can copy/paste into a text doc for examination later. This same method can be used for almost any kind of debugging info you want to spit out for yourself:
The results of the math in a function - Send_String 0, " 'The value of nloop this pass is:',itoa(nloop)"
a simple message that you got into the routine:
Send_String 0,'I got here after the button push'
etc...
DEFINE_START
CREATE_BUFFER dvMyDevice, myBufferOfStuff
essentially is:
so the code in your original post was over writing that with DATA.TEXT so it was being populated with the concatenation of DATA.TEXT behind the scenes since you used CREATE_BUFFER and then in the code in your event handler you basically cleared that by making it = DATA.TEXT.
I typically don't use create_buffer and instead just use a local var like: When I get my end tag/delimiter I remove up to and including it and send it out for parsing.