COM Port Read and Write

[Velpula]

Thankyou. Can you explain me little bit more about this delay or point me to reference(articles or examples) that explains the importance of this... I am only few months into Labview; hence all these questions.

[cirrusio]

I believe that Seeker is talking about the Wait (ms) function.  The reason that you do not want to run a while loop without a wait function is that this can potentially consume a lot of CPU time (unthrottled loops running continuously can consume near all available CPU time).  That being said, I can't remember what the loop that they are refering to is doing, but as long as you have function in the overarching loop that has to wait for data, adding a delay doesn't really help anything as the main loop will be throttled by the hardware communication (if you have a termination character, the loop will stop and wait at that VISA Read until it either 1) receives the termination character or 2) times out).  Similarly, if you have a communication VI (such as a queue or a notifier) that you are waiting on data from, you will not need a Wait function as these naturally throttle the loop in which they are located.

Cheers, Matt

[The_Seeker]

Hmmnnn... This is odd... I don't recall posting to this thread. (It appears someone here must have replied to this thread using my computer -- and hence, my profile...)

In any event, both Matt and my colleague (presumably "df86"), are correct in this instance.

Matt is correct in saying that, if the process is halted and waiting on data, it will free up the processor for other tasks (-- although, if you are new to LabVIEW, you may not have an in-depth understanding about how things work "under the hood", and what you don't know in some cases *may* come back to bite you later... 😉

My colleague (likely "df86") was also correct, referring to a commonly used "best practice" of ensuring that loops "play nicely" with each other. By including a 'ms wait' function in each loop, you are ensuring that no single loop can inundate the LabVIEW Execution Queue with so many execution requests that the other loops are starved for processor time.

A quick walk down memory lane:

Back in the early days of LabVIEW, when it ran on single core processors, and the Event Structure wasn't even a glimmer in the eye of Jeff Kodosky (...or Rob Dye, or Greg McKaskle... or whomever else it was who brought that convenient and much-needed structure into the LV world), GUI input was polled in a standard While loop. A common "newbie" error was to neglect the wait function in the GUI polling loop. Without the wait function, the LabVIEW Execution Queue would become flooded with execution requests from the GUI polling loop, and all other loops would be completely starved for processor power. The other loops -- that did the actual "work" of the application -- would never have time to execute, and if a secondary "consumer" loop was used to process the GUI input (as was common practise at the time), this secondary GUI loop would never have time to execute either. The entire application would be totally unresponsive -- all for the lack of a single, modest wait function.

Admittedly, this "best pratice" is not as crtical since the introduction of muticore computers and multithreading, however not all LabVIEW installations are built on high-end Windows systems. It still makes sense in less-caple system installations, and as a useful means to balance the load across loops.

So in a sense, both answers are correct. In a nutshell, if and when you are not sure how the LabVIEW execution system is going to respond in any given situation, it is still a good practice to include a ms wait function (-- typically 25 to 100ms) somewhere in each parallel loop to balance the load between loops -- at least until you have a better understanding of how things are working under the hood.

Cheers, and good luck with your application!

-- Dave