Weird UDP communication between PC and RaspberryPi

[colorizedice]

Hi, friends:

I'm building a communication between PC and RaspberryPi by UDP protocol. In PC part, a labview vi is running and it will firstly send a trigger signal of "yes" to the RPi part, whereas in the RPi part, after it received the trigger signal (yes), it will generate a decimal number and send it back to PC. Finally, the PC will receive that number and show it. The whole logic is shown in the following fig. 

The weird thing is when I run the vi in PC part with the "highlight" mode (that bulb icon), everything is good, which means it can send out the trigger signal, and receive the returned data. However, if I disable the "highlight" mode, the vi will stop at the "UDP read".

Another thing is, if I only send the trigger signal and don't read the returned data (disable the "udp read"), the whole thing will run well too.

I believe the problem is related to the time interval things. For example, if I let the "wait" time in Vi as 10 seconds, the whole communication seems good, but that time interval is too big.

At last, there is a while loop in the RPi part (by python code), which is used to generate the required data. At the end that while loop, the code will sleep by 1.5 seconds.

So please give me some help on my problem. Deep appreciated for any comments.

[GerdW]

Hi ice,

However, if I disable the "highlight" mode, the vi will stop at the "UDP read".

It would really help to tell us why the code stops at that UDPRead function!

Which error do you get?

[colorizedice]

There is no errors generated. The code just stopped there. I think the reason is in the Rpi part, the python code did not receive the trigger signal, so it stopped there, and in pc part, after sent out the trigger signal, the code will move to "read", but no data would come from rpi, so it will wait there.

The question is I don't know why the rpi part will miss the trigger signal. 

[GerdW]

Hi ice,

that's a typical deadlock situation: each partner waits for the other…

Maybe you should rethink that communication scheme?

[colorizedice]

I tried... 

I will attach the python code in the Rpi part sooner. 

Thanks a lot for reply. 

[crossrulz]

Instead of UPD, maybe you should use TCP.  TCP adds a little overhead, but that transmission is a lot more reliable.  For the times you are mentioning, the TCP overhead will be negligible.

[colorizedice]

Yes, the tcp will be more reliable. However, the rpi has already used the tcp protocol for another connection with a fpga board. I have not much choice. Maybe serial communications is another choice? 

[GerdW]

Hi ice,

you can have several TCP communication "channels" in parallel…

[colorizedice]

Wow, you mean I can connect both fpga and pc by tcp protocol simultaneously?  I guess I need to use multi threads? If so, how do I synchronize these two steps? 

Maybe I didn't make my point clear. I use the pc to send a trigger signal to rpi, and when rpi received the trigger signal, it will connect to the fpga and get data from it, then, rpi will send the data back to pc. 

Hopefully I make my point clear this time. 

[GerdW]

Hi ice,

you mean I can connect both fpga and pc by tcp protocol simultaneously?

In our lab we have about a dozen computers connected to the same LAN and they all can share information using TCP or UDP.

All our office computers share the same network…

If so, how do I synchronize these two steps? …

I use the pc to send a trigger signal to rpi, and when rpi received the trigger signal, it will connect to the fpga and get data from it, then, rpi will send the data back to pc.

What do you need to sync here? Each device waits for another device, there is nothing "in sync"!

(It's rather a statemachine you need here…)