LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sending a result data of a While loop via another while loop of TCP communication

Solved!
Go to solution

Hi all,

I have 2 VIs

1. A Pattern Matching (using Grab method) which is put inside a While loop. This VI works properly and returns a string of a specific format (position and angle of matching object).

2. TCP server which always listens to a specific port, if it receives a correct command string, it will send the above string of VI-1 (position and angle).

Both 2 VIs works if they are in seperate VI. But I want to combine them into 1 unique VI and I catch the problem: Pattern matching does not work any more (the video has only first frame then stop).

I tried to put both While loop in parallel or put the TCP while loop inside the Pattern Matching while loop. Nothing worked.

Pls refer to my attached VI and the TCP module.

What is the solution for requirement? 

Thanks all!

Download All
0 Kudos
Message 1 of 17
(4,708 Views)
Solution
Accepted by topic author Bestest_boy

What I would do is have your two VIs in parallel.  Since you only send the latest result, store the result in a global variable.  Your pattern matching VI writes the results global variable each iteration of its loop and the TCP module reads the results global variable when it recieves the right command and then sends it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 17
(4,693 Views)

What was exactly the problem when you combined those two VIs? Did you get any error?

In general the producer/consumer architecture seems like a good fit for your application (you can find a proper template in LabVIEW).

0 Kudos
Message 3 of 17
(4,679 Views)
I don't get any error message. But the video of Pattern matching freezed and the TCP is not stable any more (sometimes it lost command).
I also use the global variable ("String to write" in the VI) for the final string of Pattern matching and the TCP while loop will use this variable to write but the value of this string is not live-updated.
0 Kudos
Message 4 of 17
(4,665 Views)

The loops must block each other somehow. Can you post the code after putting both loops in parallel in one VI?

0 Kudos
Message 5 of 17
(4,657 Views)
Ok. I will post it tomorrow because it's in my company's computer. However it will be exactly the combination of the 2 attachments I posted.
0 Kudos
Message 6 of 17
(4,643 Views)
Solution
Accepted by topic author Bestest_boy

I'm uncertain how these two loops are supposed to be connected.  Are they both running on the same PC, or are you trying to send something to the TCP routine (via TCP, of course)?

 

Generally, when you have two loops running, one "generating" data (such as your video pattern-matching routine) and the other "using" the results of the first, the Producer/Consumer Design Pattern comes to mind.  The two loops run independently, in parallel.  The Producer (the pattern-matcher, in this case) does whatever it needs to do, then when it has a "result", it puts it in a Queue that goes to the Consumer loop.  The Consumer dequeues the result, processes it (whatever that means), then goes back to the dequeue, where it waits patiently for more data to Consume.  While the Consumer is waiting, all the compute power is available to the Producer.  While the Producer is waiting to Produce (i.e. while the Camera is gathering the Image), the Consumer has all the compute power.  They only "share" the CPU when both are active, but because they are in parallel, neither "blocks" the other.

 

If you are not familiar with this code, you can find examples in the Templates that ship with LabVIEW.  Start LabVIEW (so you don't have anything else open), go to File, New ... (the dots are important), and look near the top (expand the choices) until you see Producer/Consumer Design Patterns (Data).  Choose it, and LabVIEW will build you some "demo" code to study.

 

Bob Schor

Message 7 of 17
(4,628 Views)

Here is the 2 VIs (1 with TCP, 1 without TCP). They are not connected to each other except the Stop button and the final "String to send".

0 Kudos
Message 8 of 17
(4,588 Views)

Hi all,

I changed a little bit at the final "string to send" to global variable and in the TCP while loop I call it to use and my VI worked (in my previous version, I used local variable).

1. However, this global variable in the TCP while loop seems not to be live-updated. It is only updated when the TCP while loop is executed. So that to get the latest "string to send" I have to make the TCP send twice.  Is there any way to force it updated in live?

2. One more thing, my Stop button did not work in my current VI. I made the Stop button of the Pattern Matching while loop a local variable and use it in the second TCP while loop. How to make it correct?

Thank you!

 

0 Kudos
Message 9 of 17
(4,565 Views)
Solution
Accepted by topic author Bestest_boy

@Bestest_boy wrote:

1. However, this global variable in the TCP while loop seems not to be live-updated. It is only updated when the TCP while loop is executed. So that to get the latest "string to send" I have to make the TCP send twice.  Is there any way to force it updated in live?

2. One more thing, my Stop button did not work in my current VI. I made the Stop button of the Pattern Matching while loop a local variable and use it in the second TCP while loop. How to make it correct?


1. Move the reading of the global variable to be inside of the case structure with the TCP Write.  What is happening is the variable is being read before the TCP Read is complete (no data dependency, so that is allowed).  By moving it inside of the case structure, it can't be read until that TCP command has been recieved and you will have the latest data.

 

2.  That should work fine.  But you will have to wait for the timeout of the TCP Read to expire before the bottom loop can stop.  And you have two reads in there, each with a 25 second timeout.  So you could be waiting up to 50 seconds just for the stop variable to be read and then another 50 seconds for the loop to stop.  So it could take almost 2 minutes for the bottom loop to stop.  Either use shorter timeouts and/or make sure the commands are sent more often.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 17
(4,539 Views)