LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Highlight Execution mode prevents VI from updating UDP data

Solved!
Go to solution

Hello All,

 

  I was working with a VI (Labview 2012) that receives numeric data from a RT target, over UDP.  I noticed a flaw, and decided to troubleshoot by using the Highlight Execution mode.  When I did this, the UDP data stopped updating in real time, and it only changed when I restarted the VI.  To confirm the issue, I stripped out everything except the basic UDP functionality, and the VI exhibited the same behavior.  UDP data updates in real time when running at full speed, but does not update at all when running in Highlight Execution mode.  Is it possible that the delays that make the VI data flow human readable are causing the VI to miss the UDP data?  Please advise.

 

Thanks,

GSinMN  

0 Kudos
Message 1 of 6
(2,343 Views)

Hm, since we dont know your code, i just give a shot into the blue:

 

Highlighting significantly slows down the VI execution and puts everything in a single thread. So i would expect your program to call UDP write/read very seldom. I can imagine the the UDP connection therefore runs into a timeout. I would expect this to create at least a warning. So you have to look for possible errors/warnings you are possibly not handling properly currently.

 

hope this helps,
Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 6
(2,330 Views)

Good Morning Norbert, thanks for the reply.

 

  I thought of the timeout causing the problem, but double checked to make sure the defaults were still active for the UDP (25000 ms) and even added some time.  The code itself had been boiled down to almost nothing.  In fact, I recreated the UDP functionality in a new VI and the behavior was the same.  I have included that VI as an attachment (but there isn't much to it).  Take a look and let me know if you see anything that you think may cause the problem.  Thanks much.

 

  As far as the code that is running on the Target, it's part of a custom device that simply passes channel data through UDP.  Nothing special to see there. 

 

Regards,

GSinMN

0 Kudos
Message 3 of 6
(2,315 Views)
Solution
Accepted by topic author GSinMN

When i wrote my last reply for this thread, i also thought about the timeout (default 25s) being a possible reason, but discarded that.

As far as i know, the timeout for read/write only occurs if the buffer is full. But it seems that you do not pass such amount of data that this is an issue....

 

 

So to some conclusion:

1) Running the Windows host VI with highlight does not update the host VI anymore.

2) Rerunning the host with highlight active will update the host UI once.

3) You get not error.

 

Things you have to know/you should do:

a) UDP is a lossy protocol. So if the host does not get all data, it will not throw an error. It simply discards values. UDP does not guarantee data consistency.

b) Verify that the UDP Read function does not return any data in highlight. I think it should get data....

c) Improve your error handling: Include an "OR" between your stop button and the loop terminal and wire the error cluster to it. This will stop the loop in an error case as well. I would expect this to be the main reason for you to run the host in highlight....

d) Include some wait time in the loop. Currently, your loop time is defined by UDP Read with timeout. I am not sure if you really want to have 100% CPU load once many UDP packages arrive. If so, you should maybe go for TCP.

 

hopes this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 6
(2,286 Views)

Good Morning Norbert,

 

  Thanks for the additional information.  I did continue to ask around on this subject, and there were a few people that told me a VI is not actually fully functional during highlight mode.  It is mostly just for showing dataflow.  Kind of disappointing from a troubleshooting perspective, but at least now I know.  Looks like running with probes in place will be a better choice.

 

Thanks again,

 

GSinMN 

0 Kudos
Message 5 of 6
(2,273 Views)

Well a VI executed in highlighting is actually fully functional but of course the timing of execution is very different. There is absolutly no way to make the VI execute as fast as normal and letting you watch what it does, since your eyes are about 1 million times slower than what LabVIEW can execute the VI in.

 

But using subVIs you can much more easily define which part of the program you want to run in highlight execution mode and which part can stay running at full speed. Highlight execution mode is defined per VI, and having a mega screen sized VI with several parallel loops makes not only debugging the VI in highlight execution mode a complete nightmare, but also will put the entire diagram into highlight execution. One more reason to use subVIs, subVIs, subVIs and more subVIs, to implement logical parts of your program.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 6
(2,253 Views)