LabVIEW Idea Exchange
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.
29 Comments
National Instruments will not be implementing this idea. LabVIEW R&D has researched the concept of a quick timing probe and concluded that, for a variety of reasons, it would be difficult to provide a robust "quick" solution. One of the primary reasons involves difficulty in determining when timestamps are gathered. Timestamps gathered at the moment of probe execution happen when upstream nodes generate the data, NOT when downstream nodes consume them. This can lead to confusion about what is being timed. For instance, if a user is trying to time a node by putting a Timing Probe on an input wire and an output wire, it is possible that the Timing Probe on the input wire executes before other inputs are ready. The resulting delta between that input wire and the output wire may be longer than the time that the node consumed.
LabVIEW R&D continues to research this issue, and we are exploring multiple alternative solutions, including:
For now, please see this forum post on Data-agnostic Smart Probes, which is a feature of LabVIEW 2016 and later that facilitates the implementation of a quick timing probe. Note that we have posted an example Timing Probe to that thread.