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
2
1
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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]

 

instr1.png


[Alternative NI Instrument Driver Finder Menu Option Image]
instr2.png

 

 

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]

IDfinder.png

 

 

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

IDfinderexample.png

 

Cheers,


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.

  • Drivers

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

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.

  • Drivers
0 Kudos

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)

   niRFSG_WriteArbWaveformF32

   niRFSG_WriteArbWaveformComplexF64

   niRFSG_WriteArbWaveformComplexF32

   niRFSG_WriteArbWaveformComplexI16

 

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.

 

  • Drivers
0 Kudos

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.