LabWindows/CVI Idea Exchange

Community Browser
About LabWindows/CVI Idea Exchange

Do you have a feature idea for how to improve LabWindows/CVI? Submit and vote on ideas now!
  1. Browse by label or search in the LabWindows/CVI 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!
  2. If your idea has not been submitted click New Idea to submit a product idea. You should submit a separate post for each idea. Watch as the community gives your idea kudos and adds their input.
  3. Give kudos to other ideas that you would like to see implemented!
  4. NI R&D will review ideas that have been submitted and update the status.

Note: the LabWindows/CVI Idea Exchange is not the appropriate forum to submit technical support questions.

The LabWindows/CVI R&D team is committed to reviewing every idea submitted via the LabWindows/CVI Idea Exchange. However, we cannot guarantee the implementation of any LabWindows/CVI Idea Exchange submission.

Top Kudoed Authors
User Kudos Count
1
1
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Hi,

 

The CVI runtime engine calls the Windows API function SetProcessDPIAware() that tells Windows that the application is DPI aware in Windows Vista and later.  This seems to be forced upon all applications built with CVI, whether they are actually DPI aware or not.  Most applications built in CVI using the default tools are not going to be DPI aware out of the box, and setting Windows to another DPI setting than what the programmer used to create the UI will cause many graphical glitches and possibly make the application unusable.  The purpose of this request is to suggest to NI that the CVI Runtime Engine not call SetProcessDPIAware() so that the programmer can handle (or not handle) DPI scaling as they see fit.  If the programmer does nothing, the application will then, by default, be scaled using Windows DPI Virtualization.  This is not optimal, but it would leave the application usable and looking like how the programmer intended.

 

This is per this discussion here:

http://forums.ni.com/t5/LabWindows-CVI/Forcing-DPI-Virtualization/td-p/3079742

 

Thanks.

support of Unicode character set would be most welcome

I would like to have the possibility to store the uir-file not as a tui-file (old-fashioned ini file), instead as a xml file.

Hi,

 

Currently, when a CVI application is deployed on a PC with a DPI setting different than the development machine, the application will generally not look like how the programmer intended as the fonts get resized while the other UI elements do not, leading to overlapping text, awkwardly resized controls, etc.  One way that DPI scaling could be implemented in CVI would be to use the same functionality as the 'Scale Contents on Resize' option for panels, where internally CVI could resize the panel and use this scaling to rescale all the UI elements (including fonts) on the panel to the appropiate size per the Windows DPI setting.  This would make the panel look a lot closer to what the programmer intended and would generally make most applications usable with different DPI settings without any additional work from the programmer.  Per my other suggestion, I would request that the programmer has the capability of disabling this functionality so they can handle DPI scaling themselves should they wish to do so.

 

Thanks.

Hello,

 

usually I work on my projects on two different computers (home/work or development/lab). I would like to see a possibility to more easily move my project back and forth, say by providing two new menu commands

 

File / Import Project and File / Export Project

 

I imagine that the Export command generates a zip file consisting of all files required to build the executable (and a distribution) and also exports the editor preferences (probably without the window positions because different computers may have different screen resolutions) etc. The Import command then should load the *c., .cds, .cws, *.fp, *.h, *.prj and *.uir files, import the editor settings, adjust the library menu and load any instruments.

 

Thanks!

Is NI road map going to allow applications that are developed with CVI for Windows to run also on the Apple MAC OS as well as run on IPhone and Android Devices? The current alternative to develop the applications for the Apple MAC OS is on X-Code IDE where the code with Objective C (and Objective C++). The code that is developed with CVI cannot be ported over to the MAC OS because Objective C is not based on the ANSI C Standard. X-Code IDE is a powerful but also a clumsy IDE and can be unforgiving. NI also provides the drivers for most its hardware for the MAC. In my opinion the CVI IDE has a much better IDE than X-Code and CVI is more intuitive to use from a development perspective.  Since there is open source CLang Compiler for the MAC why can't NI import the CLang Compiler to work with the MAC and IPhone? Both Windows and MAC use the same Intel Microprocessor. Intel also has a compiler for the MAC OS that is separate from the X-Code IDE.

To develop the applications for Android devices requires the Eclipse IDE. Can CVI be adapted to develop software with the Eclipse IDE like an add-on?

In principle CVI supports external compilers for an optimized release version such as Intel's ICL and I managed to successfully compile release versions using ICL 11.1.

 

However, documentation on this issue is sparse.

 

It is even worse if one attempts to use an external linker which might be appropriate if one attempts to use e.g. Intel's MKL. Here I would love to see the support of external linkers in combination with an improved documentation.

 

Similarly, CUDA is becoming more attractive for more demanding floating point applications - I would consider it very useful if NI could provide e.g. an application note of how to do this in an easy to follow tutorial.

We use the our development and target installation PC's to support both new and legacy projects that were developed under earlier versions of IVI Compliance.  As the only current way to change IVI versions is to uninstall and re-install, we are stuck using the earliest one as a common denominator.   With hundreds of old projects to re-compile, frequent across-the-board updates are not possible.  Newer versions of instrument drivers such as HSDIO are only compatible with later versions of IVI. 

 

I would like to have a reasonably easy way to switch IVI versions, so we can support both old and new code from our development PCs.  Even a batch file and some registry edit instructions would be better than the way it is now.  However, that would limit its use in a secure environment where the users don't have general admin privileges.

 

From an NI business perspective, this may be blocking customers from purchasing upgrades or new NI products.

My 2000 dollar worth, run of the mill desktop PC has 4 teraflop of brute computation power hiding in 4 GPUs. None of which is accessible for my programs I develop in Labwindows.

Shame!

With the release of the new OpenCL it is possible to generate a "platform independent" GPU computing library. That would place Labwindows on the same or better footing than Labview that already has some GPU computing support.

The advantages are obvious: huge gain in data processing speed, real-time application with streaming data,  pattern-recognition (video) applications, image processing, data-parallel tasks in (technical) modeling arena.

I am playing with some optimization algorithms (genetic algorithms, evolutionary algorithms) that benefit and show amazing gains since they are ideal for data-parallel applications! Currently working on the specs for a new type of controller that would optimize several parameters to figure out the state of the tissue culture (expanding, producing, overgrowing, etc.) to maximize productivity and to calculate the optimal settings using evolutionary algorithms... Any complex process control could take advantage of this kind of applications -currently not available- because of computational limitations. Had a previous optimization task that would have taken 150,000 years to complete using a brute force algorithm on a "monofilament" CPU-based application. Converted it to a genetic algorithm and it gives me a good enough solution in 3-4 days on the same standard PC. Now, with GPU, that problem could be solved in fifteen minutes while expanding the evolutionary depth and finding better solutions using even more complex fitness functions.

Ask yourself what do you want: tinkering with the conveniences of the IDE that already does the job well enough; or open the door to new landscapes that could be conquered by using the simple elegance and effectiveness of LabWindows and the power of GPUs?

 

0 Kudos

The most recent version of the C runtime that comes with the Phar Lap ETS is msvcr90 from 2008. That really restricts the usage of more recent third-party libraries on real-time targets shipping this operating system.

 

Support for msvcr{100,110,120,140}, even with stubs for most of their functions, would be greatly appreciated.

0 Kudos

Hello,

 

I have a very elaborate Front Panel, developed in LabVIEW 8.6, which I'd like to import into my LabWindows/CVI 2013 development environment.

 

The background is that the new company colleagues are very proficient in C and want to use LabWindows/CVI to re-program the current state of the software and maintain and update only using LabWindows/CVI in the future.

 

This would be very usefull, since it would save a lot of time and keep the naming of the elements in the front panel as-is. For the customers it would mean, having the same tool they are used to work with and receive much faster and better service when it comes to changes or additional functionality.

 

If there is already a way to do this I'd be happy to have a step by step guide.  

 

According to the feedback from the forum, this still doesn't exist. (http://forums.ni.com/t5/LabWindows-CVI/Can-I-convert-a-LabVIEW-Front-Panel-into-a-LabWindows-CVI-Use...

 

 

0 Kudos

Hello,

 

Does anyone know if there are any plans for CVI and LabvVew Real-Time to support the Realtek NIC's? Supporting the Realtek NIC's would greatly expand the choices of boards that would be compatible with Real-Time modules.

 

Regards,

 

Tom Doyle

 

0 Kudos

I am unable to download and install the Import CVI Instrument Driver Wizard for LabView 2010.  

  • Portability