LabVIEW Idea Exchange

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

I feel its quite difficult to check one by one in VIs property that VI is Reentrant or Not. In LabVIEW there should be some option to know all the list of Reentrant VIs in project.

 

Thanks and Regards
Himanshu Goyal | LabVIEW Engineer- Power System Automation
Values that steer us ahead: Passion | Innovation | Ambition | Diligence | Teamwork
It Only gets BETTER!!!

It would be really nice if we could build PPL for multiple targets. The LV help states:

 

"If a VI calls a packed project library compiled for one target and you open the VI on another target that has a different operating system, the packed project library fails to load."

 

We should be able to choose which target's compiled code shall the builder include in the PPL. This would make the use of PPLs in a multi-target system so much better.

I like using User Events.

 

I find them intuitive for (certain) communication between code modules.

 

One thing bugs me though.  If I decide to keep the Event private to a certain module and only release a pre-registered User Event (registered for each listener) careless code can bring the entire communication to a halt.  The bare User Event refnum (pre-registration if you wish) is exposed within the Event Structure.  I have yet to understand wha this is but whatever the reason, it essentially means that it's a serious problem for 1 to n communication.  If one of the n listeners decides to destroy the user event, communication to ALL listeners is destroyed.

 

Registered Event exposure.png

 

I wish we could set the User Event refnum to being private so that it would NOT be exposed within the Event Structure.

 

Shane.

While using Highlight Execution for debugging, we end up scrolling the code to know which part of the code is currently executing, and loose context of the code due to scrolling. We could avoid this by letting 'Execution Highlighting' do the scrolling for us. Execution Highlighting with Auto Scrolling can be invoked on demand. The default behavior of the Highlight Execution will not Scroll. We should provide mechanism for users to disable or enable this while executing the code.

 

Also in case of state machine,

  • Current Behavior - If one highlights in the middle of execution and when a sub VI is executing, then the highlight will reach the case only after the control returns to top level VI.
  • This feature should also address the above mentioned behavior by switching to the case(state) in which the sub VI is executing.

Anyone ever run a vi when you left a modal subvi opened burried somewhere in the huge pile of opened windows? Wors yet the moday subvi had hidden toolbar and shortcuts disabled (most likely since modals are used as gui vi and you dont expose this toolbar to users).  Now if you dont have your own vi task manager your are most likely stuck and have to force quit labview.  Cant there be an option to wanr me before this situation occurs.  AGAIN THIS WOULD BE AN OPTION,  if you dont like it turn it off.  The simple function when you click the run button, it world check the current sub-vi in memory and see if they are modal if so, they would ask if you want to close the modal subvis, ignore or cancel. 

 

I use labview all day everyday and find myself in this situation every so often - but maybe this is just me.

 

Yes I know I can make my own vi to do this but it would be easier if it was already in labview for each future version.

It is 2011, and everyone is either making the transition to 64bit, or have already done so. Yet LabView on Linux is still stuck in 32bit, and this means that for modern Linux installations you have to install a ton of 32bit support libraries just to run LabView. Not to mention missing out on all the 64bit fun that everyone else enjoys these days, such as access to more memory. Please do something about this.

I just used the space constant VI from the string pallet. (I don't really now why I use this one sometimes because you can easily create it by yourself, mostlikely because of the icon Smiley Wink)

 

When I then checked the VI properties of "Space constant.vi" I noticed that the "Inline subVI into calling VIs" checkbox was not marked in the execution tab. I don't think it will do anyone harm to make this VI inline, can it? I also came to think of it that there are most likely other small VI's from National Instruments which maybe should have Inline marked, maybe NI should take a look threw the small VIs?

 

Maybe, maybe it is even an idea the LabVIEW check the contents of a string and if it sees that it is a constant space, line feed, etc it changes to its respectable constant icon. 

After looking at the problem encountered here, it turns out that LabVIEW seems to make some insane choices when mixing a waveform with simple datatypes. Some behavior is good and intuitive. For example multiplying a waveform with a scalar applies the multiplication to the Y component only, because it would not make sense to e.g. also multiply the t0 or dt values.

 

It is less clear what should happen if multiplying a waveform with an array. Intuitively, one would expect something similar to the above, where the Y component is multiplied with the array. Unfortunately, LabVIEW chooses something else: It creates a huge array of waveforms, one for each element in the array. (as if wrapping a FOR loop around it, see image). If the waveform and the array both have thousands of elements, we can easily blow the lid off all available memory as in the quoted case. Pop! 😄 But the code looks so innocent!

 

 

I suggest that operations mixing waveform and simple datatypes (scalars, arrays) simply act on the Y component as shown.

 

(not sure how much existing code this would break, but it actually might fix some existing code!!! :D)

I love the new data type "Maps", I just wish there was one more primitive in the Maps palette to be able to retrieve elements using a regular expression search.

 

That would rock!

 

Hi:

       The size of NI Package Library is too large for it includes so many graphic programming information such as front panel.In our view,it is not necessary when the vi is used as function,but not UI.But the 'Remove front panel' Option in the Soure File Settings Config Dialog is disable for user to select.In our point,LabVIEW should allow users to decide each VI wheather to include front panel or not when building a package Library.

 

Project->build->Packed Library Properties:

Snap8.png

 

 

 

While the intrinsic Math functions all support EXT, DBL and SGL, few of the remaining Math (or Signal Processing etc) functions support anything except DBL.  For many cases, using SGLs is sufficiently accurate, while using less memory and often being faster to compute.  While some functions are implemented solely in G (and therefore it is easy to create an SGL copy, though not so easy to integrate in a "polymorphic" way into the existing menus), most functions call a DLL routine.

 

I suggest that SGL (and CSG where appropriate) be supported for all Mathematics functions, including Signal Processing, and the Advanced Signal Processing Toolkit.  Is there anyone else who would make use of these if available?

 

Note: two "addons" have been released by NI which begin to address this.

 

Single-Precision Basic Linear Algebra Subroutines (BLAS)

Extend the native LabVIEW queues to support network based queues. We have network streams which are very nice but they are point to point. Queues are extremely useful since they allow a many to one relationship. It would be nice if LabVIEW supported network queues. I have worked with a third party implementation which works reasonably well. However it would be nice if this was native functionality. Network queues are essential if you desire communication between different applications or for sending data from a TestStand environment to a LabVIEW front end GUI. They are quite powerful and would make it much easier for users to implement multi computer applications.

 

NOTE: I need to post an updated version of the Network Queue class. I have improved and extended this implementation.)

It would be great to be able to configure LVMerge options via the command line as described here

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q0000019c3VCAQ&l=en-US

 

There was a previous proposal to fix this that was closed

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LVMerge-Configurable-Load-Options/idi-p/1282252

 

 

Please kudos this so that that it is considered 😉

Hello,

 

It would be nice to add a new menu item in Labview IDE, which could close all executing VI's.

 

This could solve the problem of "running Modal VI's" which can "block" an execution.

 

This could also be helpfull to "clear" the execution context when you have bad closed "detached and assynchonous executing VI's".

 

The top, would be to get a report (a list of VI's in a window) of the forced closed VI's ... It would be helpfull for analysis.

 

Manu.net

 

 

When dropping a probe on a string allow the probe to be resized. In addition, allow the user to select the display format (hex, ASCII,  or codes).

When you hit build, you can't edit code. Build takes a while, sometime hours. 

 

We would like to separate the compile process and free the editor, or target another pc/ip to offload compilation.

 

I would like a right-click option where a folder of packed libraries waiting to be compiled are queued and scheduled e.g 6pm or weekends and Labview is open. 

 

My colleague Bosko G has something on the latter (attached) and came up with the request. I am sure others have thought about something similar but I couldn't find a post addressing it directly. To be clear, the request isn't for a 3rd party cloud farm alone but also something we can setup on intranet PCs/Servers.

 

Thanks. 

 

Pavan 

I like to keep my code tidy and aligned.

However, nearly every time when I need the select function, I 'd like to have the 'true case' at the bottom side.  Now I add an invert function to keep the code tidy.

My idea:

Add an extra select function with the True case at the bottom side or add an option to the current select function 'invert selector'.

 

AdjustedSelect.png

I came to discover that the new silver plots such as the silver graph in LabVIEW 2011 have anti-alias on by default.  I find this very unfortunate, since the new silver stuff is in all likelihood what most people are going to use (first choice and looks cool), yet the silver plots are used at the risk of creating immensely inefficient programs, even if the code structure is efficient.  This is of course not a good thing, especially under particular circumstances, such as multiple programs being run at once, more time critical tasks involved, slower machine used, plot area expanded, etc.  And most people are never going to realize what's going on (it was pretty much by accident that I did).    

 

Let's not go backwards people!

 

 

Thus, no need to add the "EXIT" VI, and no need to check if the VI is in Run-Time mode or developpement mode...

(for big application, it could be when no VI are running...)

 

For example, add an option in the application builder :

>> Close the run-time engine when the application is completed...

 Run-time shutdown