loading
 
Socket Server
wongfeirang from Malaysia  [26 posts]
8 year
Hi Steven.
I tried to connect my PIC32 (Via Ethernet Controller) with RR using socket server. I managed to get the data received on Socket Server. However, when I try to send certain number through console, the console display a message "Disconnected from port 6767". Why this happened? Is there any bug for this Socket Server Module? I try using UDP Terminal (Software to test the UDP send and receive data) and there was no problem on sending and receiving data. Please help me to solve this problem. Before this, the USB HID also cannot being connected with PIC32 and I do not know if this problem has been rectified or not. I do not want to use Serial Module due to slow speed in data transmission.

Thanks
Steven Gentner from United States  [1446 posts] 8 year
Wongfeirang,

Go ahead and download the latest version. We tested a couple other UDP tools and found some issues with the way that we were doing things. In addition, a new broadcast mode was added that may be of interest.

Note, I'd recommend starting with the UDP mode ( as you probably have) and ensure that the PIC sends out at least one character to the server before expecting a response. The need for this is to ensure that the server gets the IP address of the PIC to reply to it.

If that's not possible, then perhaps the broadcast mode may work better.

v2.77.10 has these fixes / enhancements.

STeven.
wongfeirang from Malaysia  [26 posts] 8 year
Thanks for a quick update on Socket Server. Look like that the UDP Sending data has been fixed. I managed to send data from console to PIC32. As your suggestion, I need to make my PIC32 transmit several characters to Socket Server before I can send data from console to PIC32. However, I noticed a new problem when I started extracting the receiving data from PIC32 to Socket Server. Look like the sequence of received data that I stored on variable [Data1] and [Data2] always change each time I click the Send Now button. Another problem, when I used UDP Broadcast Mode, I noticed that the Socket Server displaying the similar data that I send from console before the actual data appears on console windows. Please refer to the attached snapshot picture for rectifying this problem.

Thanks

  
wongfeirang from Malaysia  [26 posts] 8 year
Hi Steven.
I will make further explanation in order for you to figure out the problem that I had mentioned on previous post. When I first click button "Send Now' on console, the received data stored on [Data1] = 65 and [Data2] = 68. After the second click of button "Send Now", the stored variable becomes [Data1] = 68 and [Data2] = 65. This behavior repeat again and again. How to overcome this problem?

Note:
I have program my PIC32 to reply or sending "DA" when the Socket Server send any character to my PIC32

Thanks
Steven Gentner from United States  [1446 posts] 8 year
Wongfeirang,

Do you notice that sometimes it switches the data and sometimes not? Or does it always receive the reverse?

We've not seen this behavior testing on a single machine so it might be due to the UDP packet itself that does not guarantee a specific order. We can check to see that we are sending the data out in a single UDP packet which should then arrive in the order sent but you'll have to check that the PIC is doing the same ... i.e. if you send out a packet per byte they can easily get reversed.

STeven.
wongfeirang from Malaysia  [26 posts] 8 year
Steven,

I noticed that the data always switched every time I clicked the "Send Now" button. PIC always send "DA" on consistence sequence as I captured it using UDP Terminal program. My program required to receive more than one byte (5 bytes of data). This unconsistence sequence of data also exist on USB HID module.

Thanks
wongfeirang from Malaysia  [26 posts] 8 year
Any solution for this problem??
Steven Gentner from United States  [1446 posts] 8 year
We're having problems replicating your issue. If you try the following python script on another machine do you see the same behavior of letter switches that you do with the PIC?

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

addr = ('172.31.98.221', 9090)

s.sendto(bytes("From Python",'ascii'), addr)

msg, addr = s.recvfrom(1024)
print(msg)

this is using Python 3 and sends a "From Python" string to RR on machine 172.31.98.221 (you will have to change that ip to your own). When you run this with RR running the Socket server in UDP mode you should see the full string in the correct order (in red). You can then type in 'From RR' into the send field and send that string back. That should also come out in the console on the remote machine the right order too.

Perhaps this exercise may help reveal what the underlying issue might be.

Thanks,
STeven.
Steven Gentner from United States  [1446 posts] 8 year
Were you able to replicate our results? Did you find any additional configuration that could be done to the PIC ethernet module to ensure a single packet is sent?

STeven.
wongfeirang from Malaysia  [26 posts] 8 year
Hi Steven.
Thanks for the Python script. I had running the Python script on one PC and connected to to my computer that run RR with Socket Server module. The result was similar with PC to PIC32 communication. As I click run module on Python, the result store on Data1 and Data2 always switches. This behavior is similar with what I got on PC to PIC32 communication. There is something need to be done with this module. The received data display on Socket Module received field is in consistent order but the problem exist when I tried to capture the data on Data1 and Data2 variables. I have attached the result of this experiment here. Please view and study it so you can solve this problem. Last time you modified the USB Hid module, it became slow with 2 seconds delay. I hope this will not happen on Socket Server module as I really need a high speed communication. Please also solve the previous USB Hid issues. Below is the Python script I used on this experiment:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

addr = ('10.88.18.154', 6767)

s.sendto(bytes("DA",'ascii'), addr)

msg, addr = s.recvfrom(1024)
print(msg)  



Thanks

  
Steven Gentner from United States  [1446 posts] 8 year
Wongfeirang,

Thanks for the screenshots. That helped direct us to the appropriate area. I had thought that you were seeing AD in the console as apposed to just in data1 and data2. Seeing the screenshot were its correctly DA in the console but swapped in the data lead us in the right direction. My apologies for not noticing this earlier!

We were then able to replicate your issue and have uploaded a fix. Please download 2.77.19 for this correction.

I would still incorporate a known marker (i.e. a known byte) to avoid UDP packet loss which will cause similar symptoms. So instead try

=\[data1]\data[2]

where the = is a known character that the Socket server parser will use to know that the start to the 3 byte data has begun. If you don't and a single byte goes missing, you end up with the switch that you noticed. This is not as necessary on a known small network but can be required if more machines are using the network.

You will see this sync marker even used in serial connections (often as \255)

Thanks for your patience and your continued help in resolving this!
STeven.
wongfeirang from Malaysia  [26 posts] 8 year
Steven,
Thanks for a new update of RR. I had tested it and seem the issue has been solved. As I mention on previous post, the USB Hid module also produced the similar result when I am trying to read the data send form my PIC32 to USB Hid module. Hope you can also solve this issue as the issue is exactly the same (Data switched again and again) with Socket Server module. I hope you can look back on USB Hid module to increase the speed of this module. Last update on this USB Hid module produced 2 seconds delay during transmission which is not really good for someone (me) who intend to use this high speed data transmission. Hope you can solve this 'old' issue as soon as possible.  Below is the link for our previous discussion on USB Hid module for your reference

http://www.roborealm.com/forum/index.php?thread_id=5459#1

Thanks.

wongfeirang
Steven Gentner from United States  [1446 posts] 8 year
Wongfeirang,

Yes, that fix would have applied to the USB HID module too. I've checked for any delay but don't see anything beyond the following 2 configs that would cause this:

1. Make sure the "send only when sequence changes" is NOT checked. This will ensure that the data is sent out each time even if its the same as before (not needed for most devices).

2. Be sure the "Send Rate" is set to AFAP (as fast as possible).

Otherwise, can you include your robofile that we can check the configuration that you are using ... I didn't see it posted in the previous thread.

Thanks,
STeven.
wongfeirang from Malaysia  [26 posts] 8 year
Steven,

I have tested USB Hid Module with new RR 2.78.0. The result is very disappointing. There were no received data appeared on USB Hid Module received field. I have set my PIC32 program to light on LED when RR send '2'. This was successful but with two seconds delay during sending. Means here, when I pressed Send Now button on the console, RR wait for 2 seconds to display '2' on Send & Received Field. After that number appear on that Field, then the LED is light up. I have not even check "send only when sequence change" and have set "Send Rate" to AFAP. My PIC32 program also transmitting "DA" when RR send '3'. There were nothing receive on Send & Receive Field when I send '3' form RR. Previously, the received data appeared on the field but with switching sequence. Now, there is nothing appeared. I tested it using same PIC32 program. Please solve this problem. I have attached the RR file for your reference.

Thanks

 

program.robo
Steven Gentner from United States  [1446 posts] 8 year
We removed the changes we added when this was first identified as an issue. So the 2 second delay should be removed and back to where it was. Assuming that the DA AD swapping was really the only issue that has been the only thing updated.

Can you try with the latest version 2.78.1 and see if that helps.

If not, are you able to setup a Teamviewer session so that we can login and do some additional tests?

STeven.

This forum thread has been closed due to inactivity (more than 4 months) or number of replies (more than 50 messages). Please start a New Post and enter a new forum thread with the appropriate title.

 New Post   Forum Index