Leaderboard

Yes, yes, and more yes. Some VIs shouldn't be reentrant (things like functional globals and uninitialized shift registers), but any other subVI in a reentrant VI should be made reentrant. I found an NI article that talks about it more a while ago but can't find it right now. I've been burned more than once, where I had a reentrant VI spin off, but one of the subVIs were not reentrant. Under almost all circumstances the program would run like normal, but once in a while there would be a dead lock, where one VI was running this subVI that was waiting on another VI, which blocked all the other reentrant VIs from running. Attached is a VI if you're interested, which can take a folder of VIs and turn them all into reentrant. Save VIs as Reentrant.vi

Thanks for that VI, I love it. I even made my own Wait (us), VI with that and it works great.

More submissions to OpenG. This time I have a few array functions that I have had to use over the years. These VIs are for taking a 1D array and turning it into a 2D array, taking a 2D array and turning it into a 1D array, and to simply get the last element of at 1D array. Thoughts? Critisism? Praise? Ideas to make it better? Good for OpenG? 1D to 2D array.llb 2D to 1D array.llb Final Array Element.llb

Hi guys How do you measure execution times/performance? I have 3 favourites. The Profiler (Profile Performance and Memory) Desktop Execution Trace toolkit (it give um timing accuracy very nice ) And a Timing Probe (see attached VIs) How do you do it? Timing Probe (Error).vi TimingProbe_Kernel.vi Cheers, Mike

Nope. Those don't return errors. :-)

Yup. It used to be 50 about 15 years ago (we moaned like buggery!). There is no restriction now, however.

It's a shame that the conditional disable structure cannot tell what version of LabVIEW it is. I've got a "Tick Count" vi that uses the perf counter method on windows, the normal (1ms) one on the others and it would be great if I could put another case in there to use this little gem for when I'm working in 2010 and greater so it uses the best available (I have to work in 2009,10 and 11).

That's awesome. So, when will something like that be shipping with LabVIEW?

I came here looking to see what the G experts have done wrt timing probes and found this discussion of High Resolution Relative Seconds.vi (HRRS). I am the person responsible for putting this VI in vi.lib/Utility. It calls back into a utility function I put into LV, which uses the same API that is used by the Desktop Execution Trace Toolkit. I intended it to use the highest resolution clock available on all of LabVIEW's supported platforms. On Windows this means QueryPerformanceCounter, which, in modern versions of Windows, takes into account multi-core/processor issues as well as variations in clock rate due to power management. (Up to date and authoritative docs on this are hard to find, but from the googling I've done, I believe my claim is correct.) This I discuss some of the behavior of HRRS at this site at ni.com: https://decibel.ni.com/content/blogs/EvanP/2010/10/04/tick-count-us--microsecond-timing-granularity-on-windows (I notice some of the picture links are busted there - I'll try to fix them.) As some of you noted, the Wait (ms) primitive is the inaccurate/inconsistent culprit in the Mr. Balla's benchmark. It uses a less accurate clock API, but one that uses the same clock as the "Get Date/Time in Seconds" and "Tick Count (ms)" primitives. Rob Dye LabVIEW R&D

I just learned about this little guy at NI-Week this year, I have only tested it briefly so far, but I believe you get us resolution with this as well. /J

I've managed this. It deleted 100 files in only a few seconds (and put them in the Recycle Bin).