LabVIEW Idea Exchange

It would be nice to have the choise to clean up all wires options (All wires within a VI) when right clicking a wire. I know it works with clean up utility if multiple wires are selected, but I don't want to mark them with shift clicks all over. Just by right clicking any wire within one VI should get the all option.

Today (Before)

Futur (After)

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. 

When I'm browsing Properties and Methods, the single most important tool is Context Help. However, if I open up a context menu to browse through the Properties or Methods, then hit CTRL+H, Context Help will not pop up! I must clear out the context menu I'm browsing by clicking elsewhere on the diagram, open up Context Help, then re-open the Property/Method list. I'd like CTRL+H to work when those context menus are active.

It would be desirable if the event structure supported more than one timeout event. Ideally we could define multiple, independent timeout events. It could provide a fixed number (more than one) if this eases the implementation. Currently if you want multiple timeouts you end up with some type of state machine in the timeout event to control multiple events. Multiple timers would allow us to easily process different timeout events. Allow us to control them easily without special timeout management logic in the current single timeout event. Currently we can register/deregister user events. Let's extend this to timeouts as well.

Once upon a time one could distribute code that was reasonable in size. Now it seems all the runtimes are giga byte size.

It takes far to long to send someone a distribution with all the runtimes. Try uploading 1.7Gig of files...

Can this be reduced at all?

The FPGA compiler needs version 10.4, 11.5, 13.4. This directory is 19.5 Gig! If this directory is included in the backup, it too will take up a great deal of storage resources.

Can this be streamlined?