LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I searched but didn't see this idea yet. I'm surprised it hasn't already been suggested.

 

The idea is to add a "Build Set" to the Tunnel Mode menu:

 

BertMcMahan_0-1628094318032.png

 

 

Right now we have to build an array in the loop, then convert it with another loop. A native menu option, with the ability to keep the Conditional checkbox, would be very useful.

 

(Similar thread: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-native-functions-to-convert-between-1D-Arrays-and-Sets/idi-p/4019595)

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

 

AdarshaPakala_0-1627657945371.png

 

  1. Trigger
  2. Basic arithmetic function like Ch1-Ch2, Ch1/Ch4, etc.
  3. 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
  4. In built average plots. Example add plots like 10SMA(Ch3), 30EMA(Ch1) etc.
  5. 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

Just recently ran into an issue with XML namespaces where the LabVIEW implementation just didn't cut it. The AE had R&D confirm this too. The work around, after trolling through the vast sea of .NET XML features & forums, was there. Something this simple shouldn't burn up this much time.

The world around us uses JSON & XML extensively yet the examples are minuscule. It doesn't matter if new examples are .NET, Python or something else but we need to get to solutions quicker.

 

There are some good reasons to use the Diagram Cleanup tool, but there are also many to not use it. Increasing the flexibility and customization of this tool could help increase it’s popularity among users. Sometimes I do not use this tool because it messes up my label organization. Normally I keep labels on its default classic positions (top-left and top-right), but in some cases I prefer move labels (left-middle and right-middle) to stack a bunch of terminals that goes to a function that accept many terminals (Bundle, Unbundle, Build Array, Concatenate Strings, etc.). The current behavior move the label to the position chosen in the options. It’s a big hassle go to options, change options, select part of the code and apply the cleanup as many times as necessary, the return to the default desired setup in options.

 

My proposal is to have the option “Keep relative labels positions (except wires)” in Tools > Options > Block Diagram > Block Diagram Cleanup. With this option activated the elements will be moved with their labels keeping their relative positions to the owning elements. The exception would be wire labels because wires are normally reshaped in the cleanup process.

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?

By default, VI Server uses TCP to communicate between applications.  This stream of data is not encrypted and open to hacking and snooping.  

 

My suggestion is allow VI Server traffic to be encrypted, perhaps using SSL/TLS  or an AES algorithm.

 

The reasons are obvious.  There is an increasing number of cyber attacks in industrial control systems.  Many cyber attacks are perpetrated internally, so a firewall or air gap is only so helpful.  And in certain environments (ie military, medical) you can't even consider transmitting data without encryption.  This means VI Server is not an option for many users.

 

I see that LV2020 now supports SSL/TLS in its TCP functions (see here), so the logical next step would be to make use of this in VI Server also.

For the "VI Documentation" test, it would be great to have an option to skip controls (.ctl). We never add VI Documentation to typedefs or other controls. 

 

vi-documentation-skip-ctls.png

 

(cross-posted to VI Analyzer Enthusiasts)

Within  LabVIEW project, R'CLK on an autopopulating folder gives option to mass compile on that directory.


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.

 

 

In Unity (and also Blender I think, probably others) it is possible to adjust a numeric value by giving focus to the field and then dragging the mouse left or right. It works wonderfully.

 

Take a look at the video, it is pretty self explanatory. The nice thing is that when your cursor gets to the end of the screen it wraps around automatically (even if you have multiple monitors). It really works very well.

 

In LabVIEW it is not really possible to nicely scroll through a range of values of a control (at edit time or run time). This is the kind of thing that if you have never used it probably does not seem relevant. However it really does work nicely.

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

 

Before.png

Start wiring the new error, then click on the merge error node.

During.png

LabVIEW expands and connects the error wire

After.png

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

 

 

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

Bonus.png

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

 

How about Indexing cluster element by name or order number?

 

 

AdarshaPakala_0-1625234655052.png

 

This helps dynamic indexing or programmatically indexing the cluster elements.

 

 

Thank You

Adarsh

LabVIEW from 2006

CLA from 2014

Sometimes it is hard to open the FP and block diagram of the cloned/reentrant running VIs in middle of a debug to probe the wire value in a big size application.

 

How about adding this option?

 

Screenshot 2021-06-28 165725.png

 

Thank You

Adarsh

CLA from 2014

It's pretty nice that you can link VIs to custom help documentation.

 

I'd also love to be able to have links to more details in the context help window for front panel controls & indicators. In many projects, I have had uses for programmatically setting description & tip properties for front panel controls, and it is really convenient to be able to make that information available without dedicating fix screen real estate for it. And once users know about the ctrl+H shortcut and general behavior, it becomes very intuitive to mouse over elements and find out more details about them.

 

In some cases, there might be even more info than can reasonably be packed into the context help. For example, I'm working on a UI with a tree control that has some special behaviors (e.g. symbols and dynamic custom formatting to represent additional attributes) that I would love to be able to provide a legend for, but I don't want to have to waste real estate on a static legend. I could potentially add a help menu for the whole VI, but that breaks the *context* part of context help -- I'd like to have details about specific elements on the panel, rather than for the window as a whole.

 

Since it is supported at the VI level, it feels like it should be relatively easy to extend the functionality to controls and indicators (or all GObjects that have the "description" property?).

 

...Short of that, could we add support for highlighting text in the context help window to copy & paste, and then we could at least put the help URL in as text...

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!

So, I've recently transitioned portions of our code to LabView OOP. There really doesn't seem to be a feature which is equivalent to llbs in terms of how we use them, so I'm forced to build and release specific library .llbs for each class which uses dynamic dispatching. 

 

There are numerous annoyances with this, but one of the biggest is the severe reduction in the utility of the Compare Hierarchies functionality. Now, I get a all kinds of VIs which show up as "x", i.e. different, which when I pull them up show no differences at all (I always filter to show only noncosmetic block diagram changes, because who cares about anything else, really). 

 

Also, pretty much every version I get a raft of results where the only change is the path of a library/class dependency. Also, nobody cares. There should be a generation option of exclude VI path changes.

I wish LabVIEW had Official Container (Docker) Images.

 

With more and more users trying to use the docker in Continuous Integration, it would be 

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

 

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

 

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

 

Anyone else would support this idea or has anything to complement?

I'd like to see the Destination Path in the application builder have an option to be a symbolic path based on the project directory (the direcotry where the project file lives) rather than an absolute path. For instance, if the project path (in our case, a local Git repo) was "SS10 Src Repo" and there was a subdirectory called "Builds", it would be nice to NOT have to specify "C:\users\xxx\Desktop\SS10 Src Repo\Builds" as the destination path, but rather check a box to say "symbolic path relative to Project Dir" and simply specify "Builds". If the repo is moved or renamed, all those destination paths in each project file need to be edited.

 

One reason for doing this is to locate executable that are built from the project, and called from project files via System Exec.vi. At runtime you need to find the executables (assuming they are localized and not in the PATH) and  you can use the Application Directory file constant to figure out where your executables SHOULD be (relative to  AppDir). But configuration to specify their location in each project file using an absolute path is a b**ch...  it would be great to not have to edit all the dest paths in each .lvproj each time we check out the repo on a new machine, or by a different user...