LabVIEW Idea Exchange

Quick Drop plugin VIs can currently be assigned to Ctrl-Key shortcuts.  This is a great way to quickly invoke the plugins that I use most.  However, it effectively limits the number of available plugins to 26, and it makes it fairly difficult to remember which Ctrl keys correspond to which plugins when there are a lot of custom plugins to choose from.  I would like the option to invoke Quick Drop plugins with multicharacter shortcut strings, the same way I can drop common panel and diagram objects with shortcut strings.  One possible way to do this could be to allow plugins to be included with the other shortcut objects in the Front Panel or Block Diagram shortcuts:

We are using IMAQ's C API to control a Camera Link camera. Our camera's .icd file supports changing attributes such as exposure time and capture bit depth. These parameters can be adjusted inside MAX, with MAX only allowing values supported by the camera. While the C API allows for getting/setting these attribute values (ex. with the imgSet/GetCameraAttributeNumeric functions), there is no way to determine the allowed or minimum/maximum values (or even that an attribute is supported for the given camera). It would be helpful to have API functions which could access this sort of data within the .icd file.

A similar issue exists when trying to start a new imaging session: there is no way to know programmatically which cameras (if any) are connected to the machine, and if so which interface ID they are connected to ("img0", "img1"...). This data appears to already exist in the .iid files used by MAX, so it would be useful to get at that info from within C (right now, our applications just open the "img0" interface and hope everything works).

Currently, any VIs including .NET code are shown as broken in Labview for OSX.

This is particularly annoying for people working in a cross-platform environment, specially considering that the Mono framework covers a lot of Microsoft's .NET implementation with the added bonus that it works in Linux, Windows and OSX.

Please allow users to choose which .NET implementation to use.

Greetings,

I recently took the NI Instrument Control class and we came to the topic of creating a VI tree.vi.

It didn't make sense that we needed to update the VI tree.vi AND the palette when we add or delete a VI.

I propose that there should be an option to auto-make a VI tree.vi or just a simple html page with the available VI's in your project/driver.

This currently makes sense since all the VIs should already be categorized in the palette.

Thanks,

-Jose

It would be great if LabVIEW supported the Python language, including any of its various packages such as numpy. Such computations would be much more transparent and easier to support than calling code in DLLs. They would also be much more open and flexible than the existing built-in computational solutions in LabVIEW, e.g., expression/formula nodes. Currently, I have to call Python scripts via System Exec.vi, which complicates data exchange. (NOTE: I am using an older version of LabVIEW: 2009 SP1.)

When using dll's or .Net assemblies, you always have to right click & hunt down which version gets used for the constructor.

It'd be handy to have the version shown in the Help. I already know it's a constructor node, that's not much help...

whenever a change of .NET dll is introduced, LabVIEW kept wanting to use the old dll. The change in a 3rd Party dll caused a full blown LV crash... 

A simple Uninstall of the entry in C:\Windows\assembly did the trick.

This was not mentioned in the following:

https://decibel.ni.com/content/docs/DOC-5921

http://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/assemblies_in_memory/ (only talks about runtime, which is helpful when creating the distribution)

This is not obvious nor an easy to find solution. An ability to pick and choose within LV the required dll (and version) would be helpful.

Hi!

Especially in multi monitor setups NView provides some very convenient functions. LabVIEW and NView, however, don't play well together. That is: I have to disable NView to use LabVIEW properly. That's very annoying, as you can imagine.

So my suggestion is: fix it

I suspect, that LabVIEWs scrambling of the alt+tab order is part of the problem. So I'd like to see that fixed too. I mean, you already have a shortcut to switch between Frontpanel and Blockdiagram (Ctrl+E). Why additionally scramble the alt+tab order to get FP and BD side by side?

Best regards,

pktl2k

P.S.: I'm sure, users of not-NVidia graphics have similar trouble with their respective NView counterparts.

LabView could use plugins (like Adobe!) for a lot of the features suggested by those on this forum, instead of implementation only with the latest release. For a lot of university computers that are running on old DAQ boards or simply cycle through their programmers quickly, upgrading to newer versions of LabView isn't an option, both from a price perspective and from a "reprogramming everything" logistics perspective. (I'm in this situation, with a lab using 6.1)

Plugins that I have in mind are:

• Block Diagram Cleanup Utility plugin for versions of LabView before version 8.6. Whatever algorithm the 8.6+ versions use would still work for wires and other objects strewn across the block diagram, so adding this shouldn't be too difficult.

• Zoom functionality for LabView, period. LabView is a graphical programming language, and anything graphical should have some sort of zoom utility. Whether it be to see a large block diagram in its entirety or to zoom in for people with poor eyesight, or simply a graphical readjustment to suit a different sized monitor, zooming is critical to any graphical process. Certainly, LabView wasn't created for artists, but I still think this is very important. Again. Not too difficult to create a plugin that works natively. Failing that, even an NI-supported zoom-in/zoom-out tool that wouldn't allow editing in those zoomed modes would be helpful.

• LabView canceling when opened. I believe I saw this elsewhere in the forum, but basically just something that would allow you to close LabView if it opened accidentally without going to Task Manager. On older machines it takes forever to open. Easy to implement; basically just a GUI change to allow closing earlier.

• An "Open Recent" option. I don't know if later versions have this, but it just allows opening the last project you worked on so much faster than what directory browsing allows. Again easy to implement as a plugin, I'd imagine. Some sort of cache'd memory and a new menu item.

Thank you for your time.