TCP reading and writing issue

[Adivor]

Hi Guys,

I've just finish designing a Labview client working with tcp protocol, and i'm having some issues.

I want the VI to read data until the user press on a control button, then I would like the VI to enter a writing procedure and at the end of it, return to the reading procedure. I've tried doing that by using 2 while loops: one with an event struct. in it which respond to control buttons value change ,and one for the reading procedure. It works great til I enter the writing procedure which then retrun an "Server is busy" offcourse .

my quetion is : How do I stop the reading procedure while the writing procedure is active and returning to it after the writing procedure is done?

Thanks!

[Bob_Schor · Accepted solution]

You don't say which version of LabVIEW you are using.  I'm using LabVIEW 2016, and am an enthusiastic Early Adopter of the new LabVIEW Channels, so I'm going to show you how to "do this with Channels".  Note that in place of the Messenger Channel that I will be using, you can also use a Queue.  What you are going to build is a State Machine fed by a Messenger (or Queue element), with the States coming from both an Event Loop and the Messenger Handler Loop, itself.

For simplicity, I'm going to describe a State Machine with only 6 states.

• Initialize -- the initial State, opens the TCP connection and saves the Reference in a Shift Register.
• Switch to Read -- sets a Shift Register so that the "Next State" is Read TCP.
• Switch to Write -- sets the same Shift Register so that the "Next State" is Write TCP.
• Read TCP -- does a TCP Read (and do whatever you do with the data).  Use a TCP TimeOut "just in case" no data comes in, prevents the State Machine from blocking (it just does the "Next State").
• Write TCP -- does a TCP Write (with TimeOut) and processes the data.
• Exit -- shut down TCP (not illustrated here) and stop the State Machine loop.  Note that Exit Event also stops the Event Loop.

The Snippet below shows the processing of the Read TCP button and the State Machine processing the Switch to Read State.  The "Blue Pipe" is a Channel holding an I32 (LabVIEW's "Integer" color) quantity, namely the State Enum.  This is a Messenger Channel, which has the possibility of joining to itself, so Messengers from the Initialize step (done outside the State Machine, setting Initialize as the first State), the Event Loop, and the "output" of the State Machine can all be combined and read by the Channel Reader just inside the State Machine's While loop.  Notice that the Channels are shown "on top of" (not "tunneling through") the Event, Case, and While structures -- Channels carry data asynchronously across normal Data Flow boundaries.  Thus when the Switch to Read State is executed, it puts Read TCP on the Shift Register as the Next State to be executed, and also puts Read TCP on the State Channel, which loops around to the Channel Reader and causes an immediate TCP Read to be performed.

The Snippet below (exactly the same code, but a different "view") shows how Read TCP is processed.  It also shows the Exit  Event, which (you'll notice) stops the Event Loop as all loops must exit for the program to stop.  The Read TCP code uses a TimeOut to avoid "blocking" -- every State of a State Machine should "do its thing" and then exit, otherwise the program could get "stuck" inside a particular State.  I didn't put any "real" Error Processing inside this loop -- that is up to the User to handle as appropriate.  Also, note that the Next State is taken from the Shift Register rather than being hard-wired to "Read TCP" -- why this is done is left as "an Exercise for the Reader". 

If you do not have LabVIEW 2016, or are not ready to venture into using Channels, you can accomplish the same features using Queues (though it is a little more work).  Look up State Machines, and Queued State Machines if you need more information.

Bob Schor

[Adivor]

Thank you for the solution and sorry for the delay, I've been offline for a while.

[pallen]

Great post Bob!

I haven't used Channels yet.  So it's cool to see a new feature "in the wild".

[woodbadger]

Hi Bob,

Have you built this example into a .exe?

I cannot get TCP to even create a listener after building in Labview 2016 (work fine in development).

Feels like a NI bug ... since I have tried the 2 different "create listener" techniques, and mucked around with the .ini settings related to TCP.

-Scott

[MarcDub]

Just to let you know, I have built .exe with TCP create listeners with no issue at all with LabVIEW 2016. I did not touch the .INI file at all. It just worked. So it is definitely not a bug.