No good suggestion - but you might try multiple reads, each of one
byte to see how many you get.
-- Alex.
On 08/10/2010 12:29, Len Morgan wrote:
Dar,
I wish it was that simple but the length of the message is only in one
byte so it's pretty hard to swap. For test purposes, I have scrolling
field where I print the progress of the conversation and I am
displaying the correct length. Also, I've got WireShark on the line
so I can look at the actual packets to make sure I'm picking the right
bytes, etc. and all of that is ok. The only thing that seems "out of
place" is that there is one more zero byte at the end of payload that
fills out the data area to an even word boundry. This null byte is
not part of the data and is not counted in the length byte that I'm
reading. I believe that is part of the TCP/IP spec but it's been a
long time since I've done a digital colonoscopy on network protocols
so I could be mistaken.
What ends up happening is that the socket read command is getting one
more byte than I've asked for so I'm wondering if it hangs up when I
try and close the socket since I still have one unread byte in the
buffer. As it turns out, if I try and read that extra byte too, the
result is the same: The read command will not finish until
<socketTimeoutInterval> milliseconds have passed yet is never sends me
a socketTimeout message.
The particular slave I'm talking to is from a major commercial vendor
(inventor of ModBus as a matter of fact) but as I recall, my own slave
(built with an Arduino) suffered the same "problem."
Is it possible that since I'm not using the callback on the read
complete, that there is a bug in the read socket library? I will do
some more experimentation today and report back what I find. I will
also try and whip out a LiveCode slave and see if I can make it do the
same thing on the same machine. That should be interesting.
len morgan
On 10/8/2010 12:42 AM, Dar Scott wrote:
Could you have gotten the two length bytes swapped and are asking for
way too many bytes?
Dar Scott
On Oct 7, 2010, at 6:22 PM, Len Morgan wrote:
I'm trying to read data from a MODBus/TCP controller and having
some issues with the timing of the read command. I request a block
of registers from the slave and it returns the requested bytes and
header just fine and very quickly. In order to read everything
right, I have to first read the first 6 bytes of the header to know
how many bytes are to follow. Once I know that, I do a read from
socket tSock for <bytes> characters. Note that ALL of the
characters have been received in a single packet so once I read the
6 bytes, the rest of the data is already in the socket buffer.
The problem I have is when I do the second read, the read command
blocks for the socketTimeoutInterval before continuing. It doesn't
matter what I set it to, it will wait that long before continuing.
I tried catching the socketTimeout message but that message is never
sent, even when I set the socketTimeoutInterval to 5 milliseconds!
I am not using the read ... with message form of the command since I
want the handler to wait until all the bytes have been received
before I move on. Has anyone else seen this? Have I missed
something in the documentation or could this be something in the
Windows code that handles sockets?
Any help would be appreciated!
len morgan
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
