NI Home > Community > NI Discussion Forums

LabVIEW Developers Feature Brainstorming

Showing results for 
Search instead for 
Do you mean 
Reply
Active Participant
Michael_Aivaliotis
Posts: 704
0 Kudos

Re: For Loop with Break

Yes, enhancing the array capabilities with loops is a must. Selective auto-index is great! How about selective build (if not already mentioned)? The ability to build an array on the output of a loop by column not just by row?


Michael Aivaliotis
---------
Download VIPM 2014 and take control of your reuse libraries.
---------
VI Shots
Active Participant
crelf
Posts: 1,457

Re: For Loop with Break

One feature I've been asking for for years: a native wait in every loop:
 

 
 
If unwired it would default to 0, and at least let thread switching occur.  You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default...  (PS: I know that you can do this using timed loops, but I'd like to see it in all of them - I've seen too many "programmers" complain that their CPU is at 100% because their loops are going nuts).




Copyright © 2004-2014 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Knight of NI
altenbach
Posts: 27,015
0 Kudos

Re: For Loop with Break



crelf wrote:
You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default... 

This one is a bit tricky, because one might want to be able to thread-switch every 10th or 100th iteration, so it should depend on the input. Even with the time terminal present, we need to be able to turn it off at runtime. Maybe a negative time input would act like the wait statement is not present?

Personally, I would also prefer "Wait next ms multiple" instead of "wait ms".

There are definitely many cases where we don't even want a 0ms wait because they are pure computations with finite iteration counts. Look at e.g. the abx subVI in lev-Mar fitting. I also often use a quick Newton-raphson loop to calculate equations that cannot be solved for Y. Upgrading old code should definitely NOT introduce a 0ms wait in every loop so this needs ot be addressed.

Still, I am very aware of the problem you are trying to solve. I have seen code with 20+ parallel infinite while loops without a single wait. SInce LabVIEW will ping-pong between such loops every 55ms (http://ideasinwiring.blogspot.com/2005/05/55ms.html), it will take over 1000 millisecond to service any partiular loop and the entire program thus runs extremely jerky! ... then they conclude that a faster computer is the solution. :smileysurprised:


LabVIEW Champion . Do more with less code and in less time .

Active Participant
crelf
Posts: 1,457
0 Kudos

Re: For Loop with Break

altenbach: I aggree with your comments - that's why I suggested a right click -> ignore wait (for advanced users) - but with a 0ms wait by default for beginners and intermediate users.  Also - you're right, a wait until next ms would be more appropriate here.




Copyright © 2004-2014 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Trusted Enthusiast
Albert.Geven
Posts: 3,323
0 Kudos

Re: For Loop with Break

Hi Guys

I don't understand the question for a wait until next ms. At least not in the way it is implemented in windows at the moment. I see everybody filling in 10 or 50 or 100 ms wait to get nice timing and when you lokk at the processing sytem you see a machine that is doing almost nothing and then every 10 ms jumps up being activated more every 50ms and even worse on a 100 ms point. The realtime implementation is OK So don't synchronize with the system timer please.

greetings from the Netherlands
Active Participant
crelf
Posts: 1,457
0 Kudos

Re: For Loop with Break


Albert wrote:
I don't understand the question for a wait until next ms. At least not in the way it is implemented in windows at the moment. I see everybody filling in 10 or 50 or 100 ms wait to get nice timing and when you lokk at the processing sytem you see a machine that is doing almost nothing and then every 10 ms jumps up being activated more every 50ms and even worse on a 100 ms point. The realtime implementation is OK So don't synchronize with the system timer please.

There's been a misunderstanding: I'm not talking about sycnronization at all - I'm talking about forcing a beginner user to have some sort of "timing" in their loops - not for timing's sake, but for thread swapping's sake - nothing to do with synchronization.





Copyright © 2004-2014 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Trusted Enthusiast
Albert.Geven
Posts: 3,323
0 Kudos

Re: For Loop with Break

That is exactly why I did not understand the remark from Christian that he preferred the wait until ms
 
and yes Christopher I passed the architect exam and found it easier than the developer exam.
greetings from the Netherlands
Active Participant
crelf
Posts: 1,457
0 Kudos

Re: For Loop with Break


Albert said:
I passed the architect exam and found it easier than the developer exam

 
Hey - congratulations!  Thanks for the reminder: I've got to do my architect resit this month :smileysurprised:




Copyright © 2004-2014 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant
MattH
Posts: 201
0 Kudos

Re: For Loop with Break

I love it.

While your at it, why not make a "right click" option to hide the annoying little iterator?

Active Participant
minnellac
Posts: 359

Re: For Loop with Break

I'd like to weigh in on the Flex loop that adapts to the type of the inputs. I think this is a good idea for integer types, but I'm not a big fan of using floating point step sizes for increments. I think you are asking for trouble when you use a floating point number. For example, there is no "0.1" in floating point land. A loop that uses a single precision float to increment will quite possibly not iterate the expected number of times. Check out the screen shot. A loop like this: for i=0, step 0.1 to i = 100 actually would require 1001 iterations to complete using single precision floats due to the round-off error. The same structure, but using an increment of .25 would operate as expected because 1/4 can be represented exactly.

Just a thought,
Chris