Problem receving countinously data with a UDP socket connection

I have to read the position coordinates of the end-effector of a robotic device freely moving in space. The (x,y,z) coordinates are sent via UDP to my PC as binary single variables. In run this code:

u_in=udp(in_ip,in_port,'LocalPort',in_port); u_in.DatagramTerminateMode = 'on'; u_in.ReadAsyncMode = 'continuous'; u_in.DatagramReceivedFcn = @obj.stateManager; fopen(u_in); obj.u_in = u_in;

The statemachine callback function is:

function obj = stateManager(obj,~,~)

data = fread(obj.u_in,12); data = typecast(uint8([data]'), 'single');

end

The problem is that fread returns always the same values althougth the robotic system sent different position coordinates. I tried to use flushinput, but the problem persists. The only way to get a new value is to close (fclose(obj.u_in)) and re-open the connection but this is unpractical for me since I have to read data continuously from my device.

Does anyone know how to solve this problem?

Answer 1

[Vinod]

Based on your description I wonder if this is just that your device is continually sending the same value that is filling up your UDP buffer.

Try this to isolate the problem:

1. obj.u_in = udp(someHost, somePort) % open a UDP connection to your robot end effector
2. data1 = fread(obj.u_in,12)
3. physically move the robot end effector
4. [~] = fread(obj.u_in,obj.u_in.BytesAvailable) % throw away the bytes in the buffer
5. data2 = fread(obj.u_in,12)

Post back if you see data1 and data2 to be the same.

[Benedetta]

Dear Vinod, thanks for the reply. I tested if this was the case prior to post my question in this forum. By acquiring in real time the device position with another software using UDP protocol it works fine. Howwever I have to use Matlab form my app. Thus the problem is not on the device, which sends its position correctly. In my opinion it has something to do with the fread function. I still do not understand if it can be used for similar applications, or if I am not using it correctly.

[Vinod]

We have very extensive tests for UDP and I am not sure that FREAD is the root cause here. The other application you mention may be doing things to filter the UDP data to only provide you the outputs when the position has changed (as opposed to all the data on the UDP bus.)

It would be difficult to reproduce this problem at MathWorks since we do not have your hardware. Is there a way to reproduce the issue you are seeing without the robot end effector? Alternatively perhaps you can work with technical support over a screen-share to identify the source of the problem. Create a new tech support case here .

Answer 2

[Raymond Chitwood]

Try adding flushinput(obj.u_in); before each new fread. I had similar problems, and clearing the buffer helped.