Received instructions greater than 2048
qtbxxsc
Posts: 13
How to handle received device instructions larger than 2048 bytes.
What to do if the network device sends and receives instructions with a large length.
0
Comments
Received instructions larger than 2048 will be truncated into data.text. Will using a buffer eliminate this error?
There are a couple ways to approach this. The first and easiest is a legacy left over from Access days. If yo do the old CREATE_BUFFER command in startup and make sure to use a variable of enough size to handle your message - the old method does work with messages larger than 2K.
However, there can often be some stutters in communication with larger messages that can lead to some pesky troubleshooting later on. A better way would be to create your own routine to essentially build your own large buffer and manage it yourslef.
The best way is to create a variable large enough to store the messages.
In your data_event do the following steps:
1) take whatever is in data.text and add it to the end of whatever is in your buffer variable.
2) Set up another routine that checks the buffer variable whenever there is something in it for the end-of-message delimiter. If the routine finds the EOM, then pass the value on for processing. But if the routine doesn't find the EOM delimiter, then just stand by because more is coming soon. If the buffer is empty - stop parsing and await the next time something comes in.
This is how I pretty much do all parsing anyway as it doesn't really cost much processing-wise and it ensures reliable message handling and also allows me to manage the pace at which data comes in. It's harder to bog down the program if it's not overwhelmed by some flood of input.
The data_event manual buffer method note above is effected by the length limitation set at the hardware.
CREATE_BUFFER is the better method especially when dealing with known large amounts of data.
I'd recommend parsing the buffer at the string handler of the data event evaluating for a complete message to remove from the buffer.
Check out CREATE_MULITBUFFER if you are dealing with multiples of the same device - things get really interesting then.
If you are implementing the data_event manual buffer you can leverage the persistent in a local_var scope variable to store your incoming data.
Wasn't there some difference that if you create your own array to store the incoming data, when the buffer is full all the new data is lost, whereas with a CREATE_BUFFER it's FIFO, the oldest data shifts out, keeping the last incoming data for the size of the buffer.
Some voice in my head tells me that it USED to be that way at some point, but it isn't anymore.
Easy to test, I guess.
Thank you guys！
Now I write like this, it seems to work.
~~~~~~~~
~~~~~~~~
STR_MAX=5000
vGetStr[STR_MAX]
vChar[STR_MAX]
DEFINE_FUNCTION Char[STR_MAX] fnCreateBuffer (Char vBuffer[])
{
cancel_wait 'buffer'
vChar="vChar,vBuffer"
RETURN vChar
}
DATA_EVENT[dvServer]
{
STRING:
{
vGetStr=fnCreateBuffer(data.text)
wait 1 'buffer'
vChar=''
}
}
vGetStr >>>>>> It's what I want
Answering myself:
Did a quick test and it is the case that a buffer created with 'CREATE_BUFFER' keeps the last data for the size of the buffer, the oldest data shifts out (FIFO). A manually created array (of course) doesn't do that, and when it's full all new data is lost.
I don't know what's better, probably depends on the application. Correctly sizing the buffer is always important.
It is not a best programming practice to use data from an overrun buffer. I know a 'win' is a 'win' and all that but geez... Just manage the buffer and make it bigger if need be.