Re: Socket read problems
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
Re: Socket read problems
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
Re: Socket read problems
On Oct 8, 2010, at 5:29 AM, Len Morgan wrote: I wish it was that simple but the length of the message is only in one byte so it's pretty hard to swap. Yeah, I guess the high byte is always zero. I never use read by number of bytes. It is not that I have seen problems with it, I just became comfortable doing things another way. I usually use 'read from socket with message callback'. I don't think the 'with message' is important for the behavior I see. This reads whatever is in the buffer. I think some people use an idiom of for 0 in the command for this. I collect bytes into a buffer until there is a whole message and then pull that off, in a sense, doing myself what you are looking for LiveCode to do. You might be able to use 'read from socket' as a way to prevent the timeouts and to diagnose the problem. This will show if there are problems with the frame length. Dar Scott -- ** Dar Scott Dar Scott Consulting and darzLAB 8637 Horacio Place NE Albuquerque, NM 87111 Lab, office, home: +1 505 299 9497 Fax:try 299-9497 Skype/Google: lets set up a time http://www.swcp.com/dsc d...@swcp.com Computer programming and tinkering ** ___ 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
Re: Socket read problems
Dar, As it turns out, (and much to my embarrassment) you were close on your first response: I was trying to read more bytes than were actually there. The ModBus/TCP spec actually sends two length items. One is the header + data length and the other is the data length only. What I was doing was reading the former, then getting the actual data length, then trying to read that many MORE bytes when I already had the data and header in a variable. It still bothers me though that I never got the socketTimeout message even though that's exactly what was happening. len morgan On 10/8/2010 11:45 AM, Dar Scott wrote: On Oct 8, 2010, at 5:29 AM, Len Morgan wrote: I wish it was that simple but the length of the message is only in one byte so it's pretty hard to swap. Yeah, I guess the high byte is always zero. I never use read by number of bytes. It is not that I have seen problems with it, I just became comfortable doing things another way. I usually use 'read from socket with message callback'. I don't think the 'with message' is important for the behavior I see. This reads whatever is in the buffer. I think some people use an idiom of for 0 in the command for this. I collect bytes into a buffer until there is a whole message and then pull that off, in a sense, doing myself what you are looking for LiveCode to do. You might be able to use 'read from socket' as a way to prevent the timeouts and to diagnose the problem. This will show if there are problems with the frame length. Dar Scott -- ** Dar Scott Dar Scott Consulting and darzLAB 8637 Horacio Place NE Albuquerque, NM 87111 Lab, office, home: +1 505 299 9497 Fax:try 299-9497 Skype/Google: lets set up a time http://www.swcp.com/dsc d...@swcp.com Computer programming and tinkering ** ___ 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
Re: Socket read problems
On Oct 8, 2010, at 12:02 PM, Len Morgan wrote: It still bothers me though that I never got the socketTimeout message even though that's exactly what was happening. I have a vague memory of strange things with this. I wonder if you don't get the message if you don't use 'with message' in the read. Maybe that info is just in the result. Dar ___ 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
Re: Socket read problems
Not according to the documentation. And I didn't start off using the with message form. In fact, I never did get around to even trying that once I discovered that I was the one that was making the mistake (i.e., trying to read more bytes than were there). len morgan On 10/8/2010 1:29 PM, Dar Scott wrote: On Oct 8, 2010, at 12:02 PM, Len Morgan wrote: It still bothers me though that I never got the socketTimeout message even though that's exactly what was happening. I have a vague memory of strange things with this. I wonder if you don't get the message if you don't use 'with message' in the read. Maybe that info is just in the result. Dar ___ 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
Re: Socket read problems
I still haven't remembered what is weird about socketTimeout. Perhaps you don't get it if you get socketClose or socketError. (When debugging TCP, I use handlers for all.) Is your socketTimeout handler in the right path? (An example situation is when your socketTimeout handler is in the card script but the actual read is in a handler in the stack script.) Dar Scott On Oct 8, 2010, at 12:33 PM, Len Morgan wrote: Not according to the documentation. And I didn't start off using the with message form. In fact, I never did get around to even trying that once I discovered that I was the one that was making the mistake (i.e., trying to read more bytes than were there). len morgan On 10/8/2010 1:29 PM, Dar Scott wrote: On Oct 8, 2010, at 12:02 PM, Len Morgan wrote: It still bothers me though that I never got the socketTimeout message even though that's exactly what was happening. I have a vague memory of strange things with this. I wonder if you don't get the message if you don't use 'with message' in the read. Maybe that info is just in the result. Dar ___ 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
Re: Socket read problems
The two handlers are right next to each other in the card script. You may be right about getting another error like socketError or socketClose that overrides the need for socketTimeout although I would think any socket timeout would also constitute a socket error wouldn't it? If so, why the two messages? len On 10/8/2010 2:29 PM, Dar Scott wrote: I still haven't remembered what is weird about socketTimeout. Perhaps you don't get it if you get socketClose or socketError. (When debugging TCP, I use handlers for all.) Is your socketTimeout handler in the right path? (An example situation is when your socketTimeout handler is in the card script but the actual read is in a handler in the stack script.) ___ 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
Socket read problems
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
Re: Socket read problems
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
