LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Allow a quick "Timing Probe" for Timing Metrics

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:




AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!


We need this:


 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.


 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Example Gatekeeper

I've thought about this idea for a while (and we've even discussed it within LabVIEW R&D).  This is one of the things I plan implementing as a plugin for the JKI Right-Click Framework (unless they already have it).



DNatt, LV R&D
Trusted Enthusiast
Proven Zealot


it's already possible with a custom probe. It's a bit circumstantial because you have to know the name of the second probe and insert it into a field in the first probe, but it's already possible. Maybe the name part can be changed (i work on it), but then it should do what you need.



Message Edited by MikeS81 on 06-16-2009 12:56 PM
This is one of the most boring things to have to do and most frequently necessary things to have to carry out.  This is one of the best ideas I've seen on here.  Why isn't it this easy to perform this boring routine task?  Please, NI, implement this ASAP.
Message Edited by InternationAL on 06-16-2009 06:42 AM
Proven Zealot

Just for info. The attached image shows such a custom probe. It needs a lot of time, but it's already possible.

The second probe has to be added directly after the first one. 





Message Edited by MikeS81 on 06-16-2009 04:21 PM
Knight of NI
I see problems due to the parallel nature of LabVIEW. Measuring timings like this can be way off, because other code can easily run in parallel and steal cpu cycles from the node under test.

LabVIEW Champion Do more with less code and in less time
Active Participant

I would like this as a build in function. Right click on any node and activate "Timing Measurement". The timing should be sent to a "Timing display window" (which must not be open during runtime nesseccarily). This would give the chance to use a timing below 1 ms.

Even a simple multiply would be of interest when  multiplying an array of CDB with 100,000 elements with another CDB.


Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
Trusted Enthusiast

I would also like to have this little stop watch to spread over the diagram just like a breakpoint.

However I would love to see it at  Tools/Profile/Diagram metrics with some more statistics involved.

A complete matrix might be overkill but nice to select the relations of interest and have last,min,max,mean,sdev and while we are at it: a histogram and export? :-)

And last but not least: the ability to store it (in the vi?) and be able to general enable,disable it. 




Message Edited by Henrik Volkers on 06-27-2009 04:03 PM
Greetings from Germany

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'

Active Participant

You could use something like this:


It is only 1 ms accuracy but in Windows, you can't really expect much better than that anyways.  Also it requires that one uses error clusters for sequential programming, but this is usually done in most code anyways.  


I've taken a similar approach, (also windows-only) but used the performance counter from kernel32.dll.


This gives at least 0.1 ms accuracy, I think! (darn overhead)
Nothing like a good dose of LabVIEW to cure what ails ya'.