LabWindows/CVI Idea Exchange

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



I've used the serial port call back for many years, and it works great.


The XNET driver would benefit greatly for at least a receive call back function, and possible even a transmit call back function.


This would make communication with automotive ECUs easier to implement.




Terry Moss

Robert Bosch

Charleston South Carolina

I noticed that LabVIEW has two ways to download instrument drivers: direct downloads from IDNET and through the NI Instrument Driver Finder.


[NI Instrument Driver Finder Menu Option Image]



[Alternative NI Instrument Driver Finder Menu Option Image]



When downloading drivers directly from IDNET, the file must first be unzipped and then placed in the <National Instruments>/labview xxxx/instr.lib folder.


The easier option when working with LabVIEW, the NI Instrument Driver Finder, downloads the files, unzips them, and instantly gives you access to example code or palette of VIs for communicating with said instrument.


If possible, could we add a similar tool to LabWindows CVI?  It would be nice to have a menu option which would open a CVI Instrument Driver Finder.


The interface could then allow users to easily find a driver, download it to their Instruments Folder, see example code and start work.


Since probably 30% of all LabVIEW adoption comes from driver downloads and driver development, maybe this is an investment of resources worth looking into?


[Image of NI Instrument Driver Finder]




[Image of Instrument Driver Finder example code, project access, and palette access]




Shawn Shaw

+ Implement Modbus RTU master/TCP client protocol support in CVI

I woudl like to have a library for accessing any generic USB HID device.  The library would include functions to query the list of HID's, functions to communicate with a HID, callbacks for when any HID device is connected or removed, etc.

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.


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?


To export enum types with a dll there is a fine menu "Generate Function Tree...". Using the Help Buttom, one finds is a description on how to use it. It is mentiond not to nest the different comment type. "Avoid nested comments or combinations of comment styles ...... (backslashes, stars, etc.), what I understand. - Unluckily, if one uses comma "," or semicolon ";" within a comment, the tool fails with "I n v a l i d enum typedef.", what I consider is a bug. This makes the tool less valuable, especially if one resuses C source code from thirdparties.

In the RF Signal Generator driver declaration, (i.e. niRFSG.h), there are several instrument driver function declarations that generates arbitrary waveforms. Namely;


   niRFSG_WriteArbWaveform   (which should be named "niRFSG_WriteArbWaveformF64" for uniformity)






Although, some of them are only declarated but not installed yet.

I strongly propose to add to this list, a new function "niRFSG_WriteArbWaveformI16", which seems to be the most easiest and often used in many cases.

(I don't understand why it is not in the declaration in the first place.)


I kindly ask for your consideration.


Regarding NI Spy and its sequel NI I/O Trace,


Can we have a configuration option to set the length of exported strings?


Example: Current output of NI I/O Trace as shipped with NI VISA 5.1.2:


(.txt export)

149. viWrite (USB0::0x1234::0x1234::12... (0x073F41D0), "STATUS:QUESTIONABLE:E...", 26, 26)
(I've omitted thread/proc ID and timing information)

00000000: 53 54 41 54 55 53 3A 51 55 45 53 54 49 4F 4E 41 STATUS:QUESTIONA
00000010: 42 4C 45 3A 45 56 45 4E 54 3F BLE:EVENT?


(.csv export)

"viWrite (USB0::0x1234::0x1234::12... (0x073F41D0), ""STATUS:QUESTIONABLE:E..."", 26, 26)",Prozess-ID: 0x00001734 Thread-ID: 0x00001468,Startzeitpunkt: 16:59:33.749 Aufrufdauer 00:00:00.000,Status: 0 (VI_SUCCESS),


It would be extremely useful - especially for CSV export - to have a configuration option to let me configure how many characters to print before the string is truncated, so that I get this...

desired output in .csv or .txt file (untruncated string):


"viWrite (USB0::0x1234::0x1234::12345678::INSTR, ""STATUS:QUESTIONABLE:EVENT?"", 26, 26),process ID: 0x00001734 thread ID: 0x00001468,start time 16:59:33.749 duration of call 00:00:00.000,Status: 0 (VI_SUCCESS),"


Thanks for considering this.