LabVIEW Idea Exchange

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

As discussed briefly here, the Type Cast function has a seemingly unecessary limitation that it does not accept arrays with more than one dimension.

 

Obviously, such arrays cannot be valid inputs for the "type" terminal (and thus the output), because of ambiguity (For example if we have a8 elements, LabVIEW would not know if we want a 1x8, 2x4, 4x2, or 8x1 2D array). However, having a multidimensional array as input does not pose any such problems and the result can be fully predicted. If such arrays are allowed as input, we could do cool things very quickly and with very little code:

 

Some examples (currently not possible! :()

  • Type Cast a 2x2 2D U8 array to a SGL or I32 scalar, for example.
  • Type Cast a 4x4 2D DBL array to a 1D CDB array of lenght 8.
  • Reshape a 3D DBL array to a 1D DBL array containing all elements (see image below for what we need to do today instead)

 

 

 

IDEA: The input of Type Cast should accept almost anything. In particular, numeric arrays with more than one dimension should be allowed and simply interpreted in memory order.

 

(Of couse certain things should probably remain disallowed as inputs, such as arrays of strings, for example.)

When defining a test case in a unit test you often need to import the connector pane or import control values.

 

This can take several seconds but there is no sort of indication of when the operation is running or complete. It would be good to at least have a busy icon for the duration if not some sort of progress bar.

Recently I've been trying out Labview's Unit Test Framework Toolkit and I like it enough that I'm proposing we purchase it for our core developers.  However, there are a few things that I think would improve the UI and make it much more friendly.

 

1.  Why does the VI Under Test tree control collapse every time I switch to a different test case?  The input and output list don't change for the different test cases, so if I have the tree expanded and I'm switching test cases it probably means I want to look at those tree nodes.  This is by far the single most annoying UI behavior I've come across in a while.

2.  How about the ability to add a notes field to each test case that so I could comment why that test case exists.

3.  If in addition to the notes field there were also a title field for each test case, then all the test cases could be listed in the Category pane as subnodes under the Test Cases node.  It would make it much easier to find the test case I'm looking for.  (And dare I ask for the ability to reorder the test cases as well?)

The new Sync.vim is one of my favorite new features, as it takes significantly less space on the block diagram than a flat sequence structure or other alternatives. However, whenever more than two wires need to be synchronized, additional instances of the vim must be added:sync vim 3 elements.png

 

 

 

 

 

 

I think Sync.vim would be an even better tool if the user could drag up or down to add additional terminals (like "build array," "build cluster," etc).

 

 

On these complex controls, there are specific popup menu
When you set your own popup menu, it is not possible to keep tags of the runtime.
You replace all items or you keep them all.

 

As for menus VIs, it would be very useful to keep some of the runtime optins as 'export ', 'scale x ', 'color' ... and remove other.

 

Nota : Of course it would be possible to develop these functions, but they exist in the runtime, so why redevelop?Sans titre-2.png

    How about adding a feature to a few of the LV primitives such that an error cluster can be optionally added to catch some common issues that right now require special checking:  For example, Divide by zero, returning an error as well as Nan, or Index Array where the index < 0 or > size.  THe error cluster would allow easier handling of these cases WHEN DESIRED, by wiring directly to a case structure, etc.

    (This idea evolved form a discussion at the CLA Summit during a talk by Nate Meohring.)

 

DaveT

Background:

 

I have a single pane that I was using to debug a state machine.  It is not clever at all, but it is useful.

Capture.PNG

I viewer of the Snip might not see what I did here, but I used the "Align Objects >> Left Edges" tool and the "Distribut Objects >> Vertical Compress" tool to get all the text tags and the order of the components to be "human readable".

 

fztvpepa479127866874303765.jpg

nrlsubih1015103514127206467.jpg

 

A human doesn't know that but the software should. 

 

When I hit "cleanup" I get this:

Capture.PNG

 

From this image you can observe that "fast, human readability" is lost.  I can hunt, but its not a simple up-down. 

 

I think that the "cleanup" should recognize the formmating, and retain it in this case.  It should do this by default.  The entire paradigm of LabVIEW is visual programming.  The diagram cleanup tool, in this particular case, has room for improvement there. 

As simple as that.

 

Instead of right clicking and then going to Visible Items->Label, just double click to edit the label.

It would be great if we could specify a set of VIs to run on LabVIEW startup.  It could be similar to the Windows Startup folder in which anything placed in the directory will start before the getting started window.  This could be useful for running certain tools at startup or personalizing the way the LabVIEW environment starts up.

 

LabVIEW Startup.png

 

The resizing function calculates the new position of controls based on the previous position.
But the position is an integer. So the calculation is rounded. If you resize several times a VI, rounding errors occur and position control shifts.
This is particularly true for complex controls (like a graph) that have been modified

Solution
Using the resolution of VI and position controls registered at the creation of VI and calculate the coefficient of expansion / displacement from these values.

 

Say a 1% discount on the annual DSRL fee for each unresolved CAR per company/organisation.

If you think 1% is too much, please suggest a percentage that you think would be acceptable.

 

If NI did this it would really show how much they care about the quality of their products and also that they value the feedback of their users.

 

It would also be an incentive for users to report issues and for R&D to fix them.

If one had to explain the architecture of a larger project to a new person that implements classes & interfaces without referring to a top level UML diagram, the eyes could quickly start to glaze. Adding simple functionality may prove to not be so simple.

 

Perhaps adding to the context help when hovering on the wire showing the hierarchy would be helpful as outlined below.

 

Note: Kudos to Piotr for making the code available. Thank you!

VIWeek 2020/Functional programming inspired object-oriented template in LabVIEW + SOLID

 
 

interface & class context help.PNG

 

Hello,

 

I'd like to humbly and respectfully suggest that "Internecine Avoider.vi" be rewritten or at the very least, refactored extensively.  (again)

 

This VI is found in "TCP Listen.vi", which is on the TCP palette.  It maintains a registry of existing listener connections and attempts to reuse them.

TCP.png

 

What's the big deal, you ask?  Well, when I'm having problems with listeners and need to figure out what's going on, sometimes I need to look into this VI.  Like a lot of NI code that I generally trust, I would ordinarily skip over this and disregard it as a possible source of problems.  The trouble is, every time I look at it I can't easily decipher the nuances of what it does, given its messiness.  Thus, though it may be perfectly functional, I don't trust it.

 

I realize the code could be a whole lot worse.  I also realize that someone has been in there since LabVIEW 2011 was released and has made some improvements.  Smiley Wink  Kudos to that individual for all the new free label comments.

 

Nonetheless, here are some factors that obfuscate this VI:

 

  1. There is no documentation under "VI Properties".  What does it do, at a glance?  (I know the answer because I've stared at it over a few versions of LabVIEW)
  2. "TCP Listen Internal List.vi" also has no documentation under "VI Properties"
  3. Without nitpicking, there are some sloppy practices employed in here that don't make a lot of functional sense.
  4. Deprecated "Retrieve Element" case in the internal list VI.  "Item Requested" is no longer a requested item, but the result of a search on elements.
  5. "net address" is confusing and ambiguous  Couldn't this be named, "Address of Listening NIC?" (Yes, I know it's documented under LabVIEW help for the TCP listener VI)
  6. "Conflict" is ambiguous.  This should be renamed to something more intuitive like, "Conflict: Multiple NICs Using Port" or something similar.
  7. Un-typedef'ed clusters in the internal list VI, with deceptive ordering of elements, combined with unnamed unbundler functions.

... etc.

 

I got to thinking... I know it works, or at least I think it does, but couldn't this be done more simply and elegantly?

 

I know, I know, "If it ain't broke, don't fix it."  ... but I think it could still use some work to make it more intelligible.

 

Respectfully,

 

Mr. Jim

 

InternecineAvoider.png

It would be nice to be able to select elements in the Front Panel and then be able to drag and drop them to were you want them in the navigation panel.  This useful when copying and pasting in the Block Diagram and having the resulting control appear in a far corner in the front panel.

 

Ex:

NavigationWindowImprovement.PNG

 

The control DUT SC0 2 is then moved to the area specified in the navigation window.

1) The problem :

By programmation change the number of element inside the legend :

 

EXEMPLE :

Step 1 : We have 2 slop

Graph issue 1

 

Step 2 : by programmation we have now 1 slop

Graph issue 2

 

Step 3 : Now, if you want to re-increase the number of slot inside the legend, the tab is becoming automatically vertical without any possibilities for you to modify it :

Graph issue 3

 

2) Solution :

 

If it's possible, had a property node where you can choose horizontal or vertical tab for the legend or an option : "always vertical" and "always horizontal

 

 

Thanks

 

In vi.lib\Utility\file.llb the 'file open+.vi' throws an error when a file can't be opened. It doesn't tell which file it can't open.

 

One of the strenghts of LV is the source string in the error cluster that can be used to include a lot of extra information. For example which file couldn't be opened.

 

The change can be very simple, just add the file into the source string, also see attached file:

beuvink_0-1652104974240.png

This is probably true for some other files here as well.

 

(also checking out these files... would be nice if they are updated to some newer standards... still some very old styling here...)

 

Some background: https://forums.ni.com/t5/LabVIEW/Looking-for-feedback-on-the-Carya-PDF-toolkit/m-p/4229342#M1228046

 

 

 

 

 

Hello,

 

NI should provide any text label that can be rotated by custom user defined angle like 45 or 30 or -45 or -30 degree.

Currently we have following options only.

 

_aniket72_0-1589361098132.png

 

Best Regard & Stay Healthy,

 

After much frustration searching the Labview help and NI website I finally came across the reason why my project kept coming up with vi file conflicts and/or using the incorrect version of a vi.  Apparently when searching for a vi, if there is a windows shortcut (.lnk) in the search path, it follows it!  Now this is a very powerful feature but a dangerous one too.  Apparently this has been a feature of Labview all the way back to version 1.0 This fact is not mentioned anywhere in the Labview help but I did finally find this article: http://digital.ni.com/public.nsf/allkb/B43C655BA37AFFA0862575EC0051E936

In my case I have lots of example code on my PC. I often put shortcuts to similar code in the same folder with VIs and project as a quick way to reference alternate methods of accomplishing similar tasks.  No problem, I'll just turn off this feature in the VI Search Path page of the Options dialog, right?  Much to my surprise there is no way to turn this off.

 

Suggestion: Please add an option to disable this feature in the VI Search Path page of the Options dialog.  Even if this option is dismissed and not implemented, please at least add this information to the Labview help, perhaps in the Paths Page (Options Dialog Box) if not in several other places in the help. It would certainly have same me hours of frustration and lost productivity. 

I seem to spend a lot of my time in the LabVIEW IDE waiting. Waiting for LabVIEW to load dependencies, or do this or process that. For some projects with FPGA and CompactRIO I've calculated that I spend about 80% of my time just waiting for LabVIEW development environment to catch up.

 

Given LabVIEW's multi-core nature, it seems embarassing that I can create code to run blisteringly fast on a massively multi-core number-cruncher, yet the IDE itself is painstakingly slow. I wonder how much of these delays could be mitigated by a multi-core capable development environment? LabVIEW currently runs on just one processor, and with the increasing prevalence of multi-core CPUs as opposed to faster indivudal core speeds, I wonder if the chaps at NI are thinking of taking the plunge into a multi-core integrated development environment? I seriously hope so.

Sometimes I do dumb things. One example is that I often forget to stop running an executable before attempting to rebuild it. The AppBuilder eventually fails because the file is locked--it can't delete & recreate the *.exe file if it is actively running--but sometimes it takes several minutes before the AppBuilder gets around to checking that. It would be nice if it did the file permissions check earlier in the process, so my foolishness doesn't slow me down excessively.

 

Also, since the "cancel" button for builds doesn't actually do anything, even if I notice it immediately, I'm still stuck twiddling my thumbs for a few minutes until the AppBuilder *realizes* it can't complete the process....