TCP IP multi client connection is not working properly

[ritch_by_nature]

My Program is a client server software communication where the server collector data from a cDaq and sends data to the client then the client sends command to the server to execute. The problem I encountered is when I sedn a command to the server, It shows that the server receives it but it doesnt execute it properly. Please take it a look, and see where I went wrong. I have been stuck on this for a while. I will add the more subvis after this post 

Admin Note - VIs removed per user's request.

[ritch_by_nature]

More Subvis

Admin Note - VIs removed per user's request.

[ritch_by_nature]

More subvis

Admin Note - VIs removed per user's request.

[ritch_by_nature]

More subVis

Admin Note - VIs removed per user's request.

[RavensFan]

When you have more than 2 VI's, you should just zip them up and attach that.  It is very tedious to down load multiple VI's from multiple messages.  (As I'm sure it was tedious to try to upload them all.)

[ritch_by_nature]

Sorry Here's the Zip Files. Please Help!!

Admin Note - VIs removed per user's request.

[RavensFan · Accepted solution]

It's missing Untitled Library 1.

What does  "not execute properly" mean?  Waht is it doing or not doing and what are you expecting it to do?

I see a problem in the TCP-IP subVI client.  Why are you enqueueing an element then immediately dequeueing it?  Then you proceed to to enqueue it again after the subVI ends.  But you have a parallel loop where you dequeue the element.  You've got a race condition.  One of two things could happen.

1.  The data gets enqueued and dequeued inside the subVI.  When it ends, it gets enqueued again in the same queue.  Then the parallel loop could dequeue it and work with it.  I'm guessing if this order of execution happens, it probably behaves properly for you.

OR.

2.  The data gets enqueued inside the subVI.  The parallel loop with the dequeue is sitting there waiting for something, dequeues the element and works with.  Then the dequeue inside the subVI sits there forever waiting for an element in the queue that will never come because now you've locked up the code.  The loop can't iterate to ever get more data in the queue.

You have a lot of strange queue operations going on in that subVI and another subVI in the parallel loop.  Why are you obtaining another reference to the queue, flushing it, then releasing that queue reference.  I'm not even going to try to guess how that would complicate the 2 scenarios I already listed above.

I suggest looking at more queue examples to understand how they work.  Any given queue should only have 1 dequeue operation, otherwise the dequeues will race to steal the data from each other.

[ritch_by_nature]

My Mistake @RavensFan

Admin Note - VIs removed per user's request.

[ritch_by_nature]

I change the TCP-IP client Subvi, It seems to work better now. Please take a look. When I meant not working Properly.

A few times, in the client there's a command option( cdaq and waveform). If it set to cdaq the server supposed to send me data from the cdaq if I choose the other it is supposed to send me waveform generator data. But When i do that, the data I get bck from the server is switching from cDaq to waveform generator data and I couldnt figure out. where my problem was coming from .

As you notice I use a global variable to update the top while loop in the server. I wanted to use Queue or a more better way to avoid losing commands being sent over to the client. but using Queue caused race condition so I decided to go back to globals.

Admin Note - VIs removed per user's request.

[RavensFan]

Queues are still better than globals.  Globals are more frequently abused and cause race conditions than queues do.  But you have to use queues properly.

Queues are for one to one, or many to one situations.  Basically you should never have more than one dequeue per queue.  (And something like a flush queue is effectively similar to a dequeue.).  If you need to send the same piece of data to two locations, then you should use two queues.  If you need to send data one way, and other data back, then you should have a queue or notifier for sending data back to the original loop.