Leaderboard

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 have written a paper on the Strategy Pattern (with appendices on Interfaces and the Factory Method Pattern) in the hope that this will be a useful guide to others. We have published a PDF version of the paper: StrategyPatternWithLabVIEW and a zip file that also includes the source and model: StrategyPatternWithLabVIEW--WithModelAndSource. You can comment on the paper here, if you like. Paul

I would suggest that anyone currently working with SVN install TortoiseHg and use it as a client to Subversion. You don't have to convert your existing SVN repositories. TortoiseHg can be used with your SVN repo instead of TortoiseSVN. This also allows "offline commits" with your SVN repo. http://mercurial.sel...ki/HgSubversion http://mercurial.sel...gWithSubversion Just hg clone with the "svn+" prefix. For example: hg clone svn+http://svn.python.org/projects/python python-hg After you get acquainted to Hg, make the jump to Hg repos...

If I follow your question correctly, in your subVI if you select the value in the enum that you want as default and then right-click>>Data Operations>>Make Current Value Default this means when you call this as a subVI without wiring anything that is the value that it will use.

NI Week each year is held at the Austin Convention Center. The building has undergone some serious transformation to make it a much more environmentally friendly building, and that has lead to a significant reduction of operating expenses. The building is being held up as an example of the kind of green-envrionment-meets-green-finances success that more businesses might be able to achieve in the future. Part of their success comes from educating visitors about how to handle trash. In other words, when you visit Austin, please make sure you put stuff in the right bucket! :-) http://www.forefrontaustin.com/feature/forefront-two-solid-green-investments

Just so everyone is clear: Using the Not A Refnum function to decide to create a refnum is ok because the zero refnum cannot be destroyed/released in a parallel thread. But since the primitive does the extra work of validating the refnum, you take a performance hit on the cases that are going to succeed. Using the Not A Refnum function to decide to do an action or not is a race condition because a parallel thread could be destroying that refnum in between the test and the action. If you need to actually do an operation, do one of these: If you need the combined behavior of "if the refnum is bad, allocate it, and do some operation on it", then do this: What is an acceptable use case for the Not A Refnum primitive? When you're evaluating the status of one refnum before taking an action on another refnum! Or if you're just displaying information in a Custom Probe. Or if you have absolutely nothing happening in parallel (in which case, you might reconsider your use of references anyway). (For advanced users who suggest the use of semaphores to protect the access, that counts only as an OK usage because you still have a performance hit of unlocking and locking the refnum twice.) If you ever are tempted to file a bug report that the LabVIEW queue functions are broken, please check your use of Not A Refnum first. I guarantee I will when the bug report gets to me. 🙂 And, for the record, all of the above also applies to using "Get Queue Status" and "Get Notifier Status" functions. And any other similar "is this refnum still valid" functions that you are using to make decisions in code.