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!
cancel
Showing results for 
Search instead for 
Did you mean: 

Higher precision for "Export Data to Clipboard" and "Copy Data"

Status: New

I am progressively removing pieces of code in my programs, formerly dedicated to exporting ASCII files of graph data, thanks to the (relatively) new "Export Data to Clipboard" contextual menu item.

However, recently, I have been bitten by a subtlety that is not documented (or not readily accessible): the exported values strictly stick to the data display format of the object (be it a graph, an array or whatever else).

 

Let's take an example:

 

XY graphs allow you to specify the precision used for scales, using a nifty contextual menu item on the scale legend. The problem is, the choice is limited to 6 digits. Now before you start laughing at me and demonstrate how ridiculous it is to want more than 6 digits of precision, let's examine this real life example: I am computing an autocorrelation curve from 0 to 1 ms in 1 us steps. In this case, I do need to choose a display precision of 6 for the axis, otherwise the exported data will be truncated to the specified precision. Of course the resulting data will be useless for whatever post-processing I want to do with another software. Luckily, I haven't needed to do the computation with 0.1 us resolution, because I would then be out of luck.

 

A side effect of this is that you have to specify a ridiculously high precision for export purpose, when for display purpose, you would be happy with much less, as shown below:

 

ScreenHunter_002.jpg<------------ I don't need 6 digits of precision for display!

 

 

So, in summary, at least for graphs, you can't specify arbitrary precision (suggestion 1: fix that) and you need to specify the scale precision for export purpose even though it might result in an ugly aspect (suggestion 2: disconnect the two settings).

 

The problem is compounded for other objects (scalar, arrays, etc) where you CANNOT specifiy the display precision at run time! If you miscalculated the precision needed to display a value, or chose the wrong display format and try to copy the data (or export it in the case of an array), you'll end up with truncated data. So here, same suggestions:

 

suggestion 1 bis: allow the user to change the display format of any numeric at runtime without limitations

suggestion 2 bis: differentiate between export/copy precision/format and display precision/format. I would suggest specifying this as a generic property for a given VI's FP objects, as well as individually via a Property Node. Again, I am not talking about display format, but EXPORT format.

7 Comments
Active Participant

Personally I think it's more correct to stick with WYSIWYG.The function could present a pop-up menu that gave the user more options for the export, or it could be a property you set on the graph, but both cases would complicate it a lot.

 

In your example I would suggest not to show the time scale in seconds, but milli- or microseconds. That would take care of the problem, and make the time stamps much easier to read on-screen anyway. If the user insists on seeing it as seconds, then that's his choice, with the consequences it has for readability and exportability.

 

Making your own customized version is relatively easy as well though. You can even use the same function as LabVIEW is running behind the scenes: "exportToExcel.vi". There used to be a bug in it in built applications when it came out in LabVIEW 2010, I have not checked if that has been fixed in 2011/12.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Proven Zealot

The option would be very nice.

Trusted Enthusiast
Trusted Enthusiast

@Mads: I figured the likely objection to my example just after I posted it. It happens that I also computed the ACF from 100 to 101 ms in steps of 1 us. So there you go... But the tip about the exportToExce.vi is good. Is there the equivalent for "Export to Clipboard"?

This being said, that only applies to Graphs, as the problem remains for scalars, arrays, etc...

Trusted Enthusiast
Trusted Enthusiast

To make it simple, why not export/copy data with the maximum precision for the data type? For instance, there could be an Option reading:

 

unchecked: use maximum precision for the data type

checked: used display format precision

Trusted Enthusiast
Trusted Enthusiast

Correction: it is possible to use Export to Clipboard with arrays of scalars, but as for graphs, the resulting ASCII strings have the precision of the array display format.

Trusted Enthusiast
Trusted Enthusiast

One other thing that the limited graph precision results in, apparently, is that two cursors located at the same location might have PosX values which differ by an amount of the order of the specified precision. Since by default it is set to 6, this means that you can have overlapping cursors with PosX values differing by, say, 5.1E-7 (value read recently from on of my programs). So comparing cursor positions with the "=" operator will fail. You have to include an epsilon which depends on the set precision...

Knight of NI

Sorry, I must have missed this idea earlier, but this is definitely a problem that needs to be solved. See also my old story here for an example where the current behavior blew up in my face. Kudos!


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??