LabVIEW Idea Exchange

When creating a real-time app (.rtexe) intended to be run on multiple targets with target-relative references, the recommended technique is to create a build with a IP address of 0.0.0.0; then, using some other utility outside of the LabVIEW environment, copy the executable to the startup folder on the target.

Given that, it would seem reasonable to create a feature within the LabVIEW Project Explorer that allows for direct deployment to a specific RT target or targets from the right-click menu instead of having no option to select an alternate target(s).  If setting the IP address in the project to 0.0.0.0 is the recommended technique for creating a target-relative (versus absolute) executable, then LabVIEW Project Explorer should be able to key off of this value to take a different and more appropriate action.

The same would be true of the Set as startup and Run as startup right-click menu options.

When connecting to an RT target from the LabVIEW Project view, LabVIEW RT automatically makes changes to the lvrt.conf file's startup app settings. I’ve never really understood why it needs to do that. I suppose that for some users, maybe less experienced users, this action enforces some sort of consistency that may help to avert potential tech support issues in some scenarios. However, in my case, it is an annoyance that I have to manage.

In my opinion, the LabVIEW Project view should not alter the startup app settings in the lvrt.conf file unless you use the Deploy feature from the menu. (For PharLap-based controllers, it would affect the ni-rt-.ini file).  If you use the Deploy feature, then that behavior may likely make sense.

NI should consider either eliminating the automatic edit to lvrt.conf when connecting to an RT target from the Project view and/or editing lvrt.conf only if using the Deploy feature is used.  If for some reason NI feels that the behavior is justified for some technical reason (and I would be curious to know what that reason is), what I would like to see in lieu of that is a LabVIEW option (checkbox setting) that gives the user the ability to prevent that automatic edit.

Currently, the specific changes that connecting to an RT target makes to the lvrt.conf file are:

1. It changes the name of the startup app back to the default name of startup.rtexe.
2. It changes the value of the key RTTarget.LaunchAppAtBoot to FALSE.

Deploying a library to an RT target should also not alter the startup app settings.

If you want to select, say, a cluster inside an array, you have a really narrow range of pixels to target. If you click in the body of the cluster, it selects the array. If you have a cluster in a cluster, it doesn't select anything to click blank space inside the cluster.

Attached file indicates what I'm talking about. If you want the green line, that's pretty narrow. Many people may be able to handle that degree of precision. But some people may find it hard to point that precisely.

SO, it'd be nice if you could select anything in the containment hierarchy, and discretely adjust your way to the right thing. I suggest that tapping shift would select the parent of the current selection. Tapping ctrl would select the child of the current selection that the mouse is hovering over.

Like, select the inner array and tap shift, and the selection is now the cluster it's in.

Showing this as an option in the contextual menu, with the shortcut indicated to the right, would be a good way to introduce this to the user -  "select parent (shift)", "select child 'childName' (ctrl)"

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.