LabVIEW Idea Exchange

Imagine that I have a UI with dozens of graphs all showing acquired time history data.  Time could be on the X axis, but it could also be on the Y axis depending on the convention of the UI.  The user wants to see what happened between 1 minute ago and 2 minutes ago.  The user needs to look at data on various graphs to make a determination.  The user wants to go to one plot and make a zoom operation on the time scale and have all other plots show the same time scale interval.

Why not have a properties tab on plots that allows the developer to define a named linked scale and assign a scale on the current graph to link to the global scale.  So the developer can drop XY graphs and set the time scale to link to create a standard time scale common between plots.  When the user changes the time scale on one linked plot, it automatically propagates to all other linked plots.  The common scales would be global across any VIs in memory.

This would be useful for linking time scales, but I also see it as potentially useful for linking other scales, say the Y scale is temp and the user wants all temp plots to match scale.  This would be harder though as some negotiation would be needed if autoscale is turned on where where all plots would have to report their min/max to a process that would then pass out updated scale ranges as some reasonable interval (1 hz, 10 hz, etc).

All of the above can be managed with resize events and programmatic handling of those events, but I waste many dev hours on that task.  I'd love for this to be an out of box feature.

I am extending on an old idea, but the implementation is different than the OP so I made this a new idea:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Decimation-feature-built-into-the-graph-indicators/idi-p/1109956

What I would want would be an XY graph with automatic disk buffering and on screen decimation.  Imagine this, I drop a super duper large data sets XY graph.  Then I start sending data in chunks of XY pairs to the graph (updating the graph at 10 hz while acquisition is running at +5000Hz).  We are acquiring lots of high rate data.  The user wants to see XX seconds on screen, probably 60 seconds, 120 seconds, or maybe 10 or 30 minutes, whatever.  That standard plot width in time is defined as a property of the plot.  So now data flows in and is buffered to a temp TDMS file on disk with only the last XX seconds of data showing on the graph.  The user can specify a file location for the plot buffers in the plot properties (read only at runtime). 

We decimate the incoming data as follows:

• Calculate the maximum possible pixel width of the graph for the largest single attached monitor
• Divide the standard display width in time by the max pixel width to calculate the decimation interval
• Buffer incoming data in RAM and calculate the min and max value over the time interval that corresponds to one pixel width.  Write both the full rate data to the temp TDMS and the time stamped min and max values at the decimation interval
• Plot a vertical line filling from the min to max value at each decimation interval
• Incoming data will always be decimated at the standard rate with decimated data and full rate data saved to file
• In most use, the user will only watch data streaming to the XY graph without interaction.  In some cases, they may grab an X scroll bar and scroll back in time.  In that case the graph displays the previously decimated values so that disk read and processing in minimized for the scroll back request.
• If the user pauses the graph update, they can zoom in on X.  In that case, graph would rapidly re-zoom on the decimated envelope of data.  In the background, the raw data will be read from the TDMS and re-decimated for the current graph x range and pixel width and the now less decimated data will be enveloped on screen to replace the prior decimated envelope.  The user can carry on zooming in in this manner until there is at least one vertical line of pixels for every data point at which point the user sees individual points and not an envelope between the min and max values.
• Temp TDMS files are cleared when the graph is closed. 
• The developer can opt to clear out the specified temp location on each launch in case a file was left on disk due to a crash.

This arrangement would allow unlimited zooming and graphing of large datasets without writing excessive data to the UI indicator or trying to hold excessive data in RAM.  It would allow a user to scroll back over days of data easily and safely.  The user would also have access to view the high rate data should they need to. 

TLDR: LabVIEW should be able to throw and catch exceptions like other languages.

I'll start by saying that I always leave automatic error handling turned on - please don't hate me! Yes, I am a CLA, and maybe I'm the only CLA in the world that does this - but I firmly believe that if there is an unhandled error out there in my code, I want to know about it! I don't want it to pop up in production of course, but in development the automatic error handling lets me know about any mistakes I have so that I can handle those errors properly.

Now - this led me to an even crazier idea. What if there was a way we could turn automatic error handling into a full feature that could not only help during development, but also be used in production.

Other programming languages have the concept of an "exception" which you need to "catch" to handle it properly. The idea is that throwing an exception is better than returning a value that indicates an error because then you have to rely on the person using the function to remember to check that output - but the exception will pop out at them and so they'll realize they need to handle it.

Okay so here's the idea for LabVIEW: If the automatic error handling catches an error that isn't wired out, that should be an event that programmers can "catch", either in a normal event structure or some kind of special new error event structure. That way, we can choose what behavior we want for an unhandled error (instead of the default NI dialog box), eg: maybe we just want to log it to file, maybe we want to display it in a smaller window, or handle it in some other way, depending on the application.