LabVIEW Developers Feature Brainstorming

[Michael_Aivali…]

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?

[crelf]

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).

[altenbach]

---

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.

[crelf]

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.

[Albert.Geven]

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.

[crelf]

---

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.

[Albert.Geven]

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.

[crelf]

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

[MattH]

I love it.

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

[minnellac]

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