Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
I don't know really it is possible or not in analog domain but I am bit confident about this in digital domain.
I am facing this problem in my current work. Why not, we implement this as mentioned in the below picture in labview. If I am wrong with anything, please let me know.
I am just using labview from 2 months and I am not sure this is possible or not. I guess I can not use any filter here for separating exactly those peaks. May be in some systems, peaks shouldn't place always at the same frequency.
I hope you will understand after a look at picture. I just have taken that picture from my notebook. If it is not clear, I will try to give much clear picture.
LabVIEW provides an interactive front panel when running an RT application in the LabVIEW development environment. However, once you deploy this front panel is no longer available. I think it would be helpful to make the front panel look differently or somehow give a visual warning/indication that this is a debug feature and will not be available at deployment. (This could be something as simple as a watermark, similar to the evaluation watermark that LV employs). Many new users get confused and run into problems by using lots of front panel controls/indicators and then finding out later these are not applicable at deployment.
I have been recently tasked with porting a Windows DLL to Phar Lap. So, code is not my own, there's a lot of it, and the DLL is crashing with stack overflows. Recursion is not a problem here, so it's obvously a local variable space. The default thread stack size is 128k, which is a bit on the low side. An ini setting that would allow to increase this would be most welcome. Especially if you're not getting errors in your own thread, but in the LabVIEW ones.
RT Engine it does not include the front panel in built executables, see link. Control references are only supported when the development system is connected to the RT target. It would be nice if there was an option to keep the front panel in some of my VIs when built into an executable and run without a user interface. This can be a powerful tool. One could parse a cluster and creating files based on properties of controls.
If you use a VI to control a RT target via Web browser then only polling is possible to register user actions. Since: "RT targets support the Event Structure only with dynamic events." (LabVIEW Help 2010) You can program such graphic object events but they doesn't work.
The support of graphical object events would improve the capabilities for applications with cRIO and sbRIO without a LabVIEW-Host.
VI Server nodes are asynchronous nodes. I would like to be able to get the VI Name in a subroutine. This could be done now with an XNode. Or, it could be a compiler optimization. Since VI Server nodes are a shared resource, they can cause a priority inversion.