LabWindows/CVI Idea Exchange

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

LabWindows/CVI lags behind the more recent developments in its programming language, C. At present, it only partially supports the C99 standard, not to mention the improved Unicode support of the current standard, C11.

Since odds are that Unicode finally will be supported in a future version of LabWindows/CVI, this might be a good opportunity to also ask for support of the current standard of CVI's programming language, C11, allowing the use of UTF encoded strings and also including updated libraries (e.g., supporting complex or long long) and debugging tools (data tooltips and variable view supporting complex numbers, for example). It also would help to improve C/C++ compatibility for programs that use complex floating-point values.

 

I really would appreciate it if the LabWindows/CVI project will show some strong signs of development and accompany us for the next 30 years, too.

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,

 

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.

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?

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.

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.

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!

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?

 

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.

I develop software for many older systems that can not be upgraded or are running windows embedded.  I just tried to create a new application and could not install it from my distribution.  I found out I had to go and edit the setup.ini.  NI Installer Requires Windows 10 64-Bit (Version 1507) or Newer.  I've been using CVI since the DOS days.  One of the advantages has always been that I could recompile and I generally didn't have to worry about Windows updates screwing up my software.  This change seems ridiculous all of a sudden.

 

Please add NI DataPlugin Capabilities to Labwindows/CVI. Of specific use to me would be the equivalent functionality of the following 2 VIs:


1. Convert to TDM or TDMS.vi


2. List DataPlugins.vi

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.

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-User/td-p/3044003)

 

 

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

 

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