LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Two more suggestions

There has also been a need for rising edge and falling edge triggers for boolean values instead of having to manually code this in every time. I know this would take extra memory space but could be turned on or off maybe in the control settings dialog.

I also have to manually code in time delay functions because everything I do is in loops with parallel code. The timers can't execute properly this way and would be nice to be able to use the built-in timing functions instead of hand-coding.

I really like the option to use indicators (connected to the connector pane) as the output for webservice methods. By default, Labview will serialize it to JSON, but text and xml are also options. It works quite well and it saves a lot of coding writing your own serialisation.
I have some suggestions for the serialize functionality:

1. order the JSON output by tabbing order when there are multiple output indicators. This prevents that you end up always clustering all controls into one, just to enforce order.

2. it would be nice if an enum could be represented by its string instead of its index.

3. support for maps

View All (2)

We are already using the shortcut Ctrl+i for opening the VI properties window.

But to open a VI's Icon Editor window, we do

Right Click on the Icon → select Edit Icon (or)
Double Click on the Icon

Think about the improvement in development speed if we have a shortcut Ctrl+Shift+i to open the Icon Editor window.

This will also come in handy if we are dealing with wider VI windows.

Current Environment takes ~2.5 seconds to open the Icon Editor

Move the cursor to the VI Icon (~1-2 seconds)
Two mouse clicks (double click) (~1 second)
(or)
Move the cursor to the VI Icon (~1-2 seconds)
Right click on (~1 second)
select Edit Icon (~1 second)

Proposed Environment will take ~1 second to open the Icon Editor

Press Ctrl+Shift+i (~1 second)

Switch until released radio buttons

Allow the mechanical action of radio buttons to be switch until released.

The way I make arrow buttons now is to put switch until released buttons in a cluster and watch for the value changed event of the cluster. When it changes, I convert the cluster into an boolean array, that array into a number, then feed that number to a case structure. Switch until released radio buttons, "No Selection" being a necessary default, would make that code nicer. The case selector would be an enumeration instead of a number.

Hi,

I want to find warnings in an opened VI. For example, a function has moved outside the case or loop structure and is not visible anymore. I call the error list STRG +L and give the show warnings a TRUE. I double click on the specific warning and I get the invisible VI or function highlighted, so I can move it back into the visible area by keys. The problem is, I always have to find the VI in a list of approx. 1000 VIs, which have a warning. It would be great if I would have a search by name function, or I could see the warning/errors of the active VI window.

I have attached an example picture of what I mean (I use a german version)

Cheers

RogerG

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.

View All (4)

It would be a great add-on if the graphs have got in-built measurement features/properties/methods like an oscilloscope;

Trigger
Basic arithmetic function like Ch1-Ch2, Ch1/Ch4, etc.
Event trigger based on plot value change. Example an event will be generated if Ch1 value is greater than a set value, an event will be generated if Ch2 value is greater than Ch4 value
In built average plots. Example add plots like 10SMA(Ch3), 30EMA(Ch1) etc.
Threshold based graph visual property change. Example configurable out-of-threshold or in-threshold plot color change.

Advantages;

Save time in development.
Integrated code will be efficient as no data unbuild/build/pass overheads.
Block diagram would be neat and easily readable.
Lightweight code.

Thank You

Adarsh

LabVIEW from 2006

CLA from 2014

I need "something" that is flexible and not necessarily defined during development... can be expanded or superseded over versions without breaking VIs.

currently using map, with main VI setting the keys and values and called VIs/subVIs processes only the keys specified (with default values) within the called VI itself. additional checks are required to prevent illogical or erroneous conversions during execution

something simpler/more elegant would be nice... the current ones are too "predefined" or "required to be defined'

any ideas?

View All (2)

When a folder is copied that contains (subfolders with links), the folders are not copied OK.

The copy command follows the shortcut/link and tries to copy that target.

https://forums.ni.com/t5/LabVIEW/Copy-a-shortcut-to-a-file-using-LabVIEW/td-p/97097?profile.language=en

(did not test it in detail yet, but I get a 'error 7' when copying a shortcut pointing to a no longer existing target. If the same behavior also is happening on 'move' or 'delete', following the shortcut may lead to very *unpleasant* suprises...)

Searched briefly but couldn't find any ideas about this.

I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.

Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way.

Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.

Note:

I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.

View All (2)

I find it rather depressing how so many of the new user questions contain code that is just a big Stacked or Flat Sequence structure.

I understand that we need to leave the Sequence Structure there for compatibility with old (poorly written) programs and the very few places we still have to use it...

But it's beyond time to deprecate it.

Warn users with a pop-up or the big red X like the old "Write To Spreadsheet vi" or something that this is an old outdated programming structure that should not be used in new programs!

View All (4)

View All (8)

I have long defended NI's decision to bind the lifespan of DVRs to their creator VI but, with the addition of malleability (totally awesome) and the fix in LV 2020 that allows "New Data Value Reference" to be called directly in an inlined VI (thanks, AQ), the ephemeral auto-cleanup behavior of DVRs is now a big blocker to a reference-based strictly-typed API.

I want to open a strictly-typed and malleable reference and keep that reference open until I choose to close it, regardless of whether the opener leaves memory. Without malleability, I could delegate the DVR creation to another thread/VI and get the persistent reference back by callback but I can't have the home-baked persistence and the malleabilty.

Please add a persistence/auto-cleanup flag to New Data Value Reference so I that reference can persist if I want it to. (I need both the persistence and the malleability to write some really cool code.)

Here's an old request for this feature that was declined, but things have changed a lot since then: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Persistent-DVR-s/idc-p/2856348#M27799

Superprobe

Provide a way to save and recall sets of probes for a running application. A developer could then provide sets of various probes that would help the end user. The superprobe would remember the VI paths and locations in the block diagrams of the application's SubVIs and automatically load VIs from disk or monitor existing re-entrant copies in memory. The superprobe would have a front panel layout, like a global VI, to look like a custom dashboard of important data values in the applicaton.

View All (2)

String functions with array input

PPL for multiple target

When writing a string key to a configuration file with the Config file "Write Key.vi" on the File I/O palette, the value will always have quotes around it because of the "Add Quotes.vi" in that particular method as you can see in this image.

Not all external programs handle ini files with quotes around strings as well, and this question was already asked and answered in 2010, but for some reason NI never added this VI or the option to remove the quotes to the actual palette.

I would like to have the option to have my string keys with and without quotes.

The built in web services are a handy way to expose a simple RESTful API to a LabVIEW executable. And it's nice that it supports hosting static content like HTML pages and javascript. But it would be extra nice if we could host directories with dynamic content, such as a folder of log files that we want to expose for troubleshooting purposes.

For example, if I have services that generate debug logs, I could do something like start up a python simple http server to host the log directory and make the files accessible remotely. As log entries are appended, or new files are created, they are automatically made available via browsers (or programmatic GET operations). It would be really cool if the native labview web services could do this, to avoid having to set up a separate process (and manage another port number). If I've already set up a web service for remotely interacting with this process, it feels natural that I would be able to extend it to host stuff like this.

View All (5)

Since LabVIEW 2017, it's possible to build application with a compatibility with future version of run time engine.

This option is set by default but can be disabled.

I just discover that this option is set for real time applicaiton and cannot be unset. I mean that if you build your application in with labview real time 2017, it will run with a system installed with a newer version of LabVIEW Real time.

This can be a good idea, but I'm a little bit surprise that I cannot have informations on that options for real time application and I can't control it.

Here is a way to test it. Tested on a real time desktop with pharlaps.

Install RT target with LV 2017.

Build an application and set it to run as startup. A simple application writting something in the console is enough.

Make sure your applicaiton is running at startup.

Update your system by only installing LabVIEW real time 2019.

Restart your system and your application is still running !

Because I faced an issue where LabVIEW 2020 broke my application build in LabVIEW 2017, I'm asking myself how NI can garanty that a real time system will work in any case if we upgrade the system to a higher version of LabVIEW real time version without recompiling the application.

Real time system can be used to control system that can be a secure system. If a user update by error a system, I want to keep my system safe for user.

So my idea is to remove this option or give access to the user to unselect this option to avoid any bad behavior.

best regards

View All (1)

LabVIEW Idea Exchange

Rising Edge / Falling Edge and timer delays

Some ideas for the webservice method with terminal output

Ctrl+Shift+i to Open Icon Editor

Switch until released radio buttons

Quick VI finder for warnings/errors in errorlist

Large Datasets XY Graph (with autobuffering and display envelope decimating)

In-built features in LabVIEW Graph

Not CCTV (class, cluster, typedef, variant)

VI Analyzer: Add option to "VI Documentation" to skip .ctl's

Copy shortcuts/links while copy file or folder instead of following short/cut link.

VI Analyzer Ignore Certain VIs Completely

Deprecate the Sequence Structure once and for all

Specify "friends" of community-scoped VIs on a per-VI basis

Persistent Data Value Reference (DVR)

Superprobe

String functions with array input

PPL for multiple target

Remove quotes in the Configuration "Write Key.vi"

Support hosting dynamic content with Web Services

Add ability to disable "Allow future versions of the LabVIEW Runtime" for Real Time application