LabVIEW Idea Exchange

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

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

 

 Case Insensitive Equal.png

 

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

 

 
Case Insensitive Equality Comparison.png

When I Control+Right click and drag to expand a block diagram. The expansion should NOT effect all of the unseen case frames

 

I am really tired of stuff like this happening when I expand the diagram of another frame of the same case horizontally and vertically.

 

This "Short cut" actually creates a lot more work for me as now I have to go back and clean up all the other states in my state machine that are messy now.

 

CaseCapture.PNG

 

 

 

Problem:

I faced to delete multiple elements form the array which is having 20 steps.

 

solution:

if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.

 

 

Array element.png

 

 

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

Selector.png

It would be nice if the item-list would automatically "wrap" instead.  

Selector4.png

When debugging (and at many other times), I want to copy data from a probe or control into a text file, Excel, whatever.

 

For reasons that I am totally unable to fathom, it copies the control as a bitmap. Print screen provides this functionality already. I think copy data should copy text instead!

 

copy_data.png

 

I wasn't able to find this on the exchange, sorry if I missed it!

On project folder ... 

It would be great if in the project tree,

Just like any items that are called and not on project are in dependencies...

The other way would be for

- Update icons (grayed them out) for items in project without callers to be greyed out or have a different icon like an exclamation mark or similar...

 

that way it would be easier to know if an item is

dead code or not called by anyone

 

When cleaning or developing is common to forget which vis are no longer used or needed.

Pressing Shift and dragging an object with the mouse make it move only horizontally or vertically. Great!

 

Unfortunately Labview decides which direction to move (horizontally or vertically) based on the first pixel the mouse moves. So, if you want to move something horizontally, but while clicking your mouse moves one pixel vertically, you're stuck with that direction and can start over again. ☹️

 

"Normal" applications decide the direction to move based on the ratio of x/y mouse movement: If the mouse moved more in vertical direction, the user obviously wants to move that way, if the mouse moved more in horizontal direction, then that is the user's intent. This means you can switch the direction while dragging and you're not stuck to one direction!

 

PLEASE modify the annoying behavior of Labview accordingly!

The IDE would be more consistent if all the toggle-able features were collected together under the "Visible Items" submenu. Photoshopped example of a FOR loop below, but I'm sure there are others. "Show Dynamic Event Terminals" comes to mind...

 

OneOfTheDans_0-1647968497756.png

 

I use the conditional disable structure in my projects to turn debug options on and off.

At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.

You can get around this by automating you build but an option in the build specifications would simplify this.

 

It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.

It's a little annoying to try to draw long wires to a terminal that's currently off screen -- you have to hold your mouse at the edge of the screen and LabVIEW slowly scrolls the window (Shift will speed this up a little bit).  Currently, neither the mouse wheel nor the touch pad work for panning/scrolling while a wire is currently in progress.

 

As an improvement, it would be great if the mouse wheel allowed panning the diagram while the new wire was still in progress.

 

See the attached video.

 

Currently the default front panel Alignment Grid Size is 12 pixels. It should be 10 pixels.

 

There is probably a reason why 12 pixels was selected many years ago, but is that reason still valid? Twelve pixels seems like an arbitrary number. Ten pixels would be more logical because is aligned with the decimal system.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

When wiring from inside a for loop to outside it, and the user lands the data on a singular data node (not an array or cluster), automatically set the tunnel mode to Last Value to prevent unnecessary code cleanup.

The Swap Values node only supports a Boolean input on the '?' terminal.

swap-values-error-cluster.png

It should also support an error cluster input, in the same way as the Select node (pictured) and many other nodes with Boolean inputs.

(Inspired by this discussion)

 

The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).

 

The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.

 

Right now if you have a string constant in a VI and you edit it and save it, LVCompare just highlights that the string constant has been edited. For small strings, not a big deal. However I have a bunch of big long SQL query strings.  In that case LVCompare is pretty useless. I know I changed the string constant, what I want to know is what did I change in the string constant.

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)

 

I've got some code on my diagram:
1.png

 

I need to wrap the code in a case structure, so I do:
2.png

 

Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.

 

There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:

 

If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:

3.png

(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)

 

If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.

 

With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

Digital display Misalignment.png

Digital display Misalignment solution.png

 

In the old days the digital display was automatically aligned with the plot legend (if I remember well). Now it is by default not.

It takes some manual alignment actions to get them right. But don't resize your chart!! You can start all over again.

 

I propose the option to align the digital display as shown in the last picture.

 

(BTW, looking for duplicates I found one comment in http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Assembly-of-the-graph-s-plots/idc-p/1085440)

 

Editing the Font Styles and Size of a text, can't it be Simpler? rather than a lot of mouse clicks each time??

 

Many had suggested the use of Key board shortcuts, but it may be used for some other things. But Why shouldnt we use a dialogue box instead?

 

The problem is lot of mouse clicks to go to Dialogue font, Styles/size and then to the respective selection like,

Problem.png

 

The Key board shortcuts are being used for other functions., But Why shouldnt we have solution like this??

 

remedy.png

 

I am not sure whether it can be done or someone already suggested., but i didnt come accross anything like this when i searched for.

 

Thank You..

Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.

As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.

 

So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)

I was thinking about two methods (see attached)

 mouse coordinates FP.png

 

1. Show coordinates along with the mouse

2. Show coordinates at the bottom of the pane

 

Thanks,

 

 

 

Struggling to replace R&S FSW-K70 by VST and RFmx for my customer, found 16APSK and 32APSK are not directly supported by RFmx DeMod.  The customer is currently using FSW-K70 and their current test scnearios require 16APSK and 32APSK modulation and demodulation.  

 

I found a thread mentioning about APSK support below.  

 

https://forums.ni.com/t5/LabVIEW/APSK-Modulation-Demodulation/td-p/4232293