Leaderboard

That's one way of doing it. If I was going to make my own installer, I would build an EXE with LabVIEW 7.1 or older, so that the runtime engine can be included. I would put my real EXE (built with modern LabVIEW) in a subfolder along with any support files (possibly the required runtime engine as well). Then zip all that and convert it to an EXE that runs my 7.1 EXE after getting extracted to a temp folder. That way there is only one EXE to the user, that they run, extracts and runs a LabVIEW EXE and runs without any runtime engines installed, and from there can install my application or other components. Of course coding in 7.1 isn't impossible, but there are some functions that are taken for granted that I may have to code my self which were not available then. Also I'll essentially be including two run time engines. The 7.1 runtime engine was around 12MB zipped up so it won't add alot of space but still is extra code that won't be used after the install. I've never done this approach, because it is re-inventing the wheel and supporting a tool seems like a pain, for very little added benefit.

Indeed. In fact it's the same as trying to set the revision number less than the current revision for a VI where it will object with error no. 1077 (which maybe is what it should be for classes rather than 53). My opinion is that version numbers should be able to be set to whatever we want, however.

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

...but it's challenging to be a *good* software architect: http://t.co/DNqxMny