LabWindows/CVI Idea Exchange

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.