LabVIEW Idea Exchange

I would like to propose the inclusion of the possible errors to the help menu of each function.

If you are new to LabVIEW or have to work with something you don't know, it would be nice to see all the possible errors, so that you can handle them appropriately. Also it is easy to forget an unusual error or one that is so common that one hardly notices it anymore (e.g. timeout, reading non existent array elements or division by 0).

This information is included in the APIs of other programming languages, e.g. Java, as well and saves a lot of time in searching and testing for an exotic error.

In some cases we may have functions called from DLLs, which cannot be not terminated in "normal" way due to some reasons.

When source code for DLL is available, then this is not a problem, but for third-party DLLs this may be terrible.

All what we needed is Timeout for External Code Call.

Let me explain. For example, we have code like this:

when such external code called from VI, then this VI cannot be stopped

Suggestion:

add Timeout option to the following dialog:

When enabled, then the following input will be shown:

And timeout can be programmatically defined on the block-diagram:

by default -1, of course.

I fully understand, this is dangerous thing, but in some cases we needed this. Suggested is something like TerminateThread function.

Back to the code above, when this code should be terminated, then we needed wrapper something like this:

Then this function can be called in separate thread:

And now we can terminate execution with TerminateThread function:

Then in LabVIEW it looks something like this:

Now we can "Abort" our infinite DLL call without any dialogs like "Resetting VI", etc.

Again, this is dangerous feature (but not more dangerous as TerminateThread itself), and may be is necessary in the most extreme cases, otherwise the only way to stop the application is taskkill.

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).

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.