Interrupt-like data receiving over TCP/IP

[iman_h]

Hi!

I have a device with WiFi connectivity. Sending data from LabVIEW to it, is straightforward. But how can I receive data efficiently? Data is not sent from the device periodically so an event-based procedure could be used for this.

I already have read several topics in this forum. Some users suggest parallel "polling" of received data. And as far as I know it is not possible to create an event on data value change in an Event Structure.

I have attached a simple vi which sends data successfully. 

Thanks! 

[GerdW]

Hi iman,

what's wrong with polling?

All you need to do is to handle timeout errors of the TCPRead function in case nothing was received…

[iman_h]

Thanks!

I changed the program to receive data in parallel. Sending is OK but I can not receive data. I also tried to receive data in Timeout of Event Structure.

What should I do?

[GerdW]

Hi iman,

I changed the program to receive data in parallel. Sending is OK but I can not receive data.

You did NOT change your VI to have read and send in parallel - THINK DATAFLOW!

Right now (due to dataflow dependency!) the read loop will start when the send loop has finished…

Right now you close the TCP connection in parallel to the TCPRead operation.

Make them run in parallel!

Btw. did you check the "simple TCP" example coming with LabVIEW?

[iman_h]

Dear GerdW!

Thanks.

I corrected some mistakes here:

[GerdW]

Hi iman,

do you know this function?

[Bob_Schor]

What do you want to have happen when the sender is not sending data?  Are there background routines that should be running (monitoring things, displaying things, etc.) or can everything simply stop and wait for the Sender to send?

You basically do not need to poll.  The TCP Read will "block" until either data are received or the timeout (default = 25 seconds) occurs.  If it "blocks", then all your other parallel loops can run (you need to understand how Data Flow makes LabVIEW a naturally-parallel-processing system, of course).  Should a Timeout occur, you simply ignore it and keep looping.  The only reason to shorten the Timeout (to, say, 100 msec) is to let you respond to, say, a Stop button in a "reasonable" time.  [Note in your latest example, you don't need, and probably shouldn't have, the Wait (ms) function].

Does that make sense to you?

[GerdW -- my apologies if my notion of "polling" differs from yours.  I think we are largely "saying the same thing", but I'm pushing the idea that the TCP/IP channel should be considered a parallel input "running at its own speed, and clocked by the sender, not the receiver"].

Bob Schor

[iman_h]

Thanks. I used the method in the Simple TCP/IP example.I will use the function you mentioned, instead.

[iman_h]

Dear Bob,

Here, the "client" is actually a control plant with ARM micro-controller and ESP8266 WiFi module. The server works in two modes: The Idle mode in which the server (Here LabVIEW app.) sends some data to the plant and receives some other, not on any special timely basis.

The second mode is control mode. In this mode the client collects data and send it through WiFi and the server performs some calculations and "responds" to client. Here a merely precise iteration time is necessary. (i.e. 20 to 50 ms). [I know that network-based control and data acquisition have several issues but here they are not very critical.]

The client receives data in an interrupt-based manner. ESP receives data and send it to micro via UART. The UART peripheral trigs an interrupt and so on...