LabVIEW Idea Exchange

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

We use Queued Message Stage Machines a lot and often send messages through API calls. In a state machine I prefer using enums to determine the state and in the QMSM that would be useful too because sometimes a typo in a message in an API call stops it from working. 

 

However, the Message Queue functions accept string only. 

 

 

image.png

 

Even if we make changes to the message cluster or make the VI polymorphic but we would then need to do it every time we are setting up a new machine with LabVIEW. Would this be useful for anybody else? 

image.png

 

 

 

 

I work with large projects.  And I often need to move items around in my projects.  However...  while you're dragging an item in the Project Explorer, if the cursor is at the top or bottom of the visible area, the window does not scroll.  This means that the item you're moving, and its destination, must both be visible at the same time in order to drag and drop it.

 

I regularly have to un-expand items in order to be able to simply move a file.  This is time consuming and forces me to un-expand tree items that I would prefer to keep expanded.

Similar to Draw Line/Draw Multiple Lines function available for Picture, it would be good to have line styles(as mentioned in the attached image) for IMAQ Overlay Line, IMAQ Overlay Multiple Lines 2.

Now that NXG is going to be discontinued, I guess the NI employees who were working on it will be re-deployed.

There question is to do what??

 

A part of the LabVIEW community thinks the failure of NXG was partly due to the fact that the team working on it didn't have enough love for LabVIEW-CG and/or not enough experience using LabVIEW-CG in real world applications.

 

So my suggestion to help them understand better what makes LabVIEW great and what could make it even better is to encourage/force them to spend a fix percentage of their work-time contributing to LabVIEW related open source projects.

 

What better way to enrich the LabVIEW eco-system and make them feel for LabVIEW at the same time?

Sometimes, it can be useful to know the last event handled by an event structure.

 

LastEvent.png

 

When I try to select a word or more words I currently have two options. The first one is to hold down shift and select on letter by letter basis which is slow. The second one is to select with help of mouse, which is error prone.

 

Normally all text editors have options to move for 1 word left or right by ctrl + left arrow or ctrl + right arrow. The same goes for selecting a word (ctrl + shift + arrow). I would like this functionality to be supported by LabVIEW at least on block diagram, VI documentation, enum editing.

we correctly recommended that the SSS be removed from the Structures Palette.   Let's go one step further.   Default Block Diagram Cleanup to apply the existing "Replace SSS with FSS."

Problem: while handling file I/O functions , connecting the wires between File functions like Reference , Error etc. takes time.

 

Solution: some of File I/O function intelligent(auto) wiring by keeping function on top of one function and dragging the function.

 

File IO.JPG

 

I would like to watch the series of videos from 2012 about learning Advanced Architecture.  I would like to follow industry standards to ensure that I am building an architecture that will be understood by developers. 

 

I did a bit of research and somehow I managed to unlock the course as a student.  I went back to finish the course today and it switched to "you are not entitled to training courses".  I mean fair, but I feel pretty entitled to steer people away from LabVIEW if they come to me with interest in it...  

 

I'm not understanding how this model can possibly make more money than having more LabVIEW developers.  Easy access to training = more developers = more hardware purchases and certification puurchases right?  Am I missing something or is this model as bad for share holders.

 

 

I just noticed the Find VI's Callers option isn't available when trying to find callers for a vim file.

 

this_vi_callers_vim.png

 

So the idea is to allow this option for malleable VIs!

Hi community

 

"propose to extend hashing function to include string for hashing sensitive information (1-way)"

 

currently hash function is polymorphic and accepts only path as input, perhaps:

- input terminal can accept both string and path, determining type internally and change accordingly, and

- instead of polymorphic, enum terminal instead?

Sometimes it would be useful to get the index in the set. 

Could then replace Search 1D array in this :

gnilsson_0-1597300452773.png

 

The key input of the Map Get / Replace Value node of an In Place Element structure is not a required input. This can lead to bugs, where a developer may have forgotten to wire the key. All other Map primitives require the key input.

map_node_key_input.PNG

The idea is to simply make the key a required input.

 

(The map isn't a required input either, but has a documented default. It should probably be required too though.)

Please create a meaningful error message in case the application builder errors due to long path names.

 

The error below was ultimately fixed by shortening the output path in the build spec. It took me however more than half a day of fiddling around with alternative solutions to reach my end goal (https://forums.ni.com/t5/NI-Web-Technology-Lead-User/Hosting-WebVI-on-cRIO-following-KB-article/gpm-p/4061052/highlight/true#M282).

 

While explaining it to my colleague it hit me that the build output path could be too long, shortened it, built it, deployed it, and it worked.

 

 

Build error.PNG

When setting the inheritance of a class, you're only able to select classes that are currently loaded into memory:

carls___1-1590710186323.png

If you're not working within a project (which I do commonly to keep things zippy), chances are the class you're looking for isn't loaded.  It'd be great if there was a browse button on this UI.

 

(The workaround is to open the class you want to inherit, but that class can't be opened simultaneously because of the modality of this UI and that it'd need to refresh, so you need to close out of this window and the class properties window and then reopen both.)

The Clean Up Panel menu option in LabVIEW 2019 messes up the labels for Image Controls. I have only noticed this with image controls that don't actually show the image.  See the attached pictures.

Before Clean Up Panel is chosen:  Notice all this vi is is the two controls on a front panel.

CleanUpPanel Before.png

 After Clean Up Panel is executed.  (I had to scroll a bit to show where the labels ended up)

CleanUpPanel After.png

 I have only noticed this with image controls.  It may happen with others as well.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

There are some property nodes and methods that will fir the text in the indicator/control by resizing the control/indicator vertically.
This option is great but when you spend a lot of time organizing your front panel this option is not elegant nor suitable for your project and the user is not able to see the whole string

Like "Dequeue Element", but removes and returns the element in the back of the queue instead of the element in the front of the queue.

 

Like "Enqueue Element At Opposite End", but dequeues instead of enqueues from the opposite end as normal.

 

This would allow queues in LabVIEW to be used as double-ended queues (also called dequeues or deques, pronounced "decks"). It is already possible to enqueue elements on either end of a queue. It would make sense to also be able to dequeue elements from either end of a queue. 

 

It would also allow queues in LabVIEW to be used as stacks without having to use "Enqueue Element At Opposite End", which is useful when it is easy to modify consumer code but difficult or undesirable to modify producer code.

At present, using a malleable VI in almost any form alongside PPLs seems to be largely impossible.

 

Of course, a malleable VI is a template of sorts, and a PPL is the compiled form of some library. I can see this makes including the malleable VI impossible (at least without a predefined list of allowed types, at which point you could use the VIM as a private VI and define a set of public or private VIs, then call those from a public polymorphic VI).

 

However, it would be nice if we could define a VIM (either in, or alongside) a library in a project, and have it be placed in e.g. the Support destination (or specified destination via the Build Specification settings).

 

A quick attempt to do this resulted in the following:

  • Create a library with two VIs, one outputting a number and the other a string.
  • Create a VIM that has an input used only for type matching, and a Type Spec Structure for Assert Structural Match on string, int32, output the appropriate matching result type from one of the two (public, in this simple test) library VIs
  • The first case of the TSS is the string one (seems relevant to outcome).
  • Build the library into a lvlibp, with the VIM set to Always Included, and the destination set to Support.
  • The output files are A.lvlibp, Output String.vi, Get Value.vim.
  • A.lvlibp only contains Output Num.vi, not the string anymore.
  • The VIM is not loadable via project (although it opens broken alone), because it calls A.lvlibp:Get String.vi, which doesn't exist.
  • Get String.vi is unloadable, seemingly because it requires (perhaps it expects to be) A.lvlibp:Get String.vi...

 

Could this please be improved? 🙂

 

Ideally the VIM that is placed in the accompanying destination should link to the VIs in A.lvlibp, and none of the VIs should be missing in that PPL.