ShaunR

I don't believe they intrinsically suspend execution until an update is received. They also have huge caveates (e.g cannot be dynamically created at run-time). Its a bit of a sledgehammer to crack a nut IMHO.

Instead of replacing threshold values with 255 (to get your black and white) replace with 1. Your picture control will look all black. If you want to see the results in the picture control, right click on it and select Palette>binary. You will then have a red and black image. Either your black and white or red and white images (binary) will work with mask functions as effectively they operate on zero and non zero for binary operations.

And press "Alt" to get just the active window.

I would defensively code a check to see if the file exists, force its attribute to be writable and delete it before trying to save (I actually do this anyway with overwriting files and have done for years). Then phone NI to see what they say. There may be a reason for it.

Sounds like my workplace

I'd prefer a "Wait on notifier history" that only executed the number of elements in the history. LV 2010?

A pendulum swinging is just eye candy. You don't need to synchronise it.KISS.

Animated "Gif" image.

I had this problem recently. My scenario was that the asynchromous consumers could either send a "completed" notifier immediately (no part present) or after some arbitrary amount of time (part has been processed). The sequence engine would wait for all notifications from the subsystems, index a carousel and then send a "Go" notifier to all of them . The problem was that if the subsystems sent it immediately, the chances were that the sequence engine wasn't waiting for the notifier at that moment in time, so on the next round would wait indefinately. The elegant solution would have been the "Wait on notifiers with history". But this doesn't wait again unless you've cleared the notifier and since you don't know which is the last one in an asynchronous system, you don't know when to clear it. If it executed the number of times there were notifications in the history....it would be perfect! The normal notiifer will only execute when you are actually waiting (if ignoreprevious is true) or again, you need to clear it (if it is false). So that didn't work either since the sequence engine was unlikely to be already waiting if a subsytem returned immediately. So I ended up with all the subsytems waiting on a notifier to "go" and a separate 1 element lossy queue for each subsystem to send back the completed (basically a notifier with a history of 1). Luckily I have a Queue.vi so it wasn't messy and just meant replacing my Notifier.vis with the queue one.

Indeed. For me it depends on whether I want (or need) to spend a day thinking about an elegent approach for a trivial part of the program or just want the results. I'm not particularly a purist, so if its neat, easily understood but not the quickest piece of code on the planet, then thats fine.

Surprised me too . But maybe optimisations are coming into play. Not sure what you mean by "whenever possible". If you need to "iterate" then I don't really see any other alternatives apart from "while" loops which don't have inherent capablity to dynamically terminate on the array length. Example perhaps?

The thread that anything runs in is not dependent on the loop (LV 9.0and "for" loops excepted) but the "Execution System" that you define. Additionally, the number of loops is irrelevent. Its the vi's that count! The max thread count is 8x5x5 = 200 (8 per execution system x 5 execution systems x 5 priorities). The default is 4 per execution system with 0 for background . So if you look in process explorer you will probably see 21 threads (4x5=20 + 1 for LV itself). Therefore, if you have 4 threads and 12 loops in 1 execution system in 1 vi which is at "Normal" priority,then the LV scheduler will split the 12 loops between the 4 threads (black magic NI secret how this is applied....chime in here LV gurus!). If you want to ensure that a single loop runs in a single thread (not documented but works for me). Then run those loops in their own vi and in diiferent execution systems (I use other1 and other2 a lot) and in asingle vi. If you change the threads per execution, then you will see the threads grow in "Task Manager". Bear in mind, that LVpre-allocates threads, so you will only see the difference when youre-start LV. One further point. Don't confuse parallelism with multithreading. You can run 2 loops in parallel but LV may only run them in 1 thread and "timeslice" between them. A usefull utility exists in vi.lib\utility\sysinfo\threadconfig.vi where you can change the thread allocations. - Don't know. None of the PC's we use have AMD processors, but seems a bit unlikely.

Intriguing question. Well. For loop original 10000 runs = 5080 ms. No for loop 10000 runs = 2ms For loop with 10000 run loop normal but code loop // (2cores)) 10000 runs = 2887 ms For loop with 10000 run loop // (2cores) and code loop // (2cores)) 10000 runs = 2 ms

Don't know where the "attached discussion forum" is, but I've thought for years that "Elapsed Time" should be in ms resolution. It would have been useful then .

Unfortunately you can't because it uses serialised data. I've actually found very few scenarios (so far) where I can use that feature. That maybe due to how I partition my code and the type of implementations.

Now your just being difficult...lol.

Also you can type in 248 on your numpad whilst holding down the alt key. Works in anything (word, excel, labview, notepad). Alt Numpad codes

A while loop with nothing will be the fastest. But it will hog your processor (although I've noticed 2009 it only hogs 50% instead of 100%) and it will be hit and miss whether other similar loops get in or not. The next is usually a wait ms with a 0 wait time as it allows context switching so your other loops at least get a look in. Timed loops under windows are better used as a periodic function rather than (in the realtime context) a deterministic function since you are still at the mercy of the windows scheduler. The rule of thumb is. if its time critical......don't use windoze!

Labview is highly optimised for "for" loops. They are very efficient. Far more so than most other array primitives/operators. Try it.

Litteraly...you don't need the for loop. Still works because its only detecting zeros which (in both your examples) only exist in the gaps.

Ahh. You can. You don't need the for loop either

I bet you say that to all the boys

I bet it isn't

For this signal, you can just look for zeros in your data which will be the start and end of gaps.

Does it matter?