LabVIEW
Wait for 0ms in For loop?
Solved!
Hi!
I came across a "Wait(ms).vi" wired with a constant 0 in a for loop and I was wondering if this has a real utility or if it is here possibly only for debugging purposes and the programmer simply didn't removed it and changed the constant to 0 instead?
Thanks in advance.
Vinny.
From the help: "Wiring a value of 0 to this parameter forces the current thread to yield control of the CPU. "
Also look here for more detailed explanation: https://forums.ni.com/t5/LabVIEW/Wiring-a-value-of-0-to-the-milliseconds-to-wait/td-p/776227
Although, I should say that in most cases it is not needed. In the code you showed, if the array in is huge and it will take so much time to process that you want other processes to be able to do some stuff in between iterations, then it may be useful. But practically all places where I have seen it placed by others, it is totally unneeded and something a newbie seems to think they must place there.
I would suggest you experiment and see what difference it makes. Likely nothing noticeable. In that case, I would remove it, since it is just noise to the eye. If it does make a difference, I would connect a comment to it and explain why it is there, if it is not obvious.
@VinnyAstro wrote:
/.../ So, even with a massive array, is it still necessary to do this kind of action?
I guess my question is more on the difference between Cores and Threads...
There could still be a use for it, depending on what available process power you have, but there are other (better) ways to approach the issue where you notice that you are hogging a process, by refactoring the code. If you get a specific problem, post it and we can help.
This could become a deep and complex discussion. I'm just stopping here for today.
The fact that LabVIEW already is multithreading anyhow makes this indeed of very limited effect nowadays. In early days (< LabVIEW 5.0) it was single threaded and LabVIEW implemented its own style of cooperative multithreading (it still does that by the way in addition to the OS threading).
It does this by combining the diagram code into clumps. That are a series of nodes being clumped together. Whenever a clump has finished executing, LabVIEW will take the next clump from its execution queue and start that. With multithreading available it will do this simply in parallel for every thread that it created on startup for the current execution system of there are enough independent clumps available.
There are certain function nodes in LabVIEW that always force the clumper to break the diagram into separate clumps. Those are the so called asynchronous nodes, such as Delay ms and similar, that's because they typically will keep waiting on something and don't need to do that in a tight loop but instead they cause the clumper during the compiling to make a new clump so that the current clump is put back in the execution queue and in the case of a Delay function scheduled for the amount of delay again. A delay of 0 ms simply sets the clump to be scheduled again ASAP and if nothing else is present in the execution queue, the actual clump is retrieved again and executed again. So a delay of 0ms still will use the current CPU core to the max if nothing else needs to be executed but if there are other things to execute than they will get a chance to run too, even on single threaded LabVIEW.
With LabVIEW being multithreaded nowadays on all still active platforms, this delay of 0 ms makes not as much sense anymore but it doesn't really hurt either unless your loop needs to run with absolutely maximum performance for whatever reason because it does cause a slight slow down.
