Hello,

LabView permits to import three different 3D file formats: VRML, STL and ASE.

So LabView can handle these file type, but is not possible to export any CAD format with LabView.

In example can not be exported to a CAD format simple x,y,z points generated by a mathematic process in LabView.

Next future will be possible to save CAD formats?

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.

Problem:

When you want to have the organization of your files within the project file different from the folder hierarchy on disk you are not able to connect to a vi dynamically through vi server because you simply do not know the path which the builder has created within the executable.

To rebuild and maintain the folder structure of the disk in the project file is time consuming and error prone.

Solution:

A small tool which extracts the actual paths within the executable so you can copy the correct path to your vi-server call would do the job.

I miss the ability to wire a cluster reference to (un)bundle by name nodes. If I have some parallel processes that share a common configuration bundle for my project, I'd really like to be able to only have one copy of the bundle in memory. This is possible if I use a reference to a cluster. However if I do that it gets really complicated to get access to the content of the bundle. If I use 'property node --> value --> unbundle' I load the bundle into memory anyway in an extremely inefficient way before extracting the control of interest. If I use 'property node --> controls --> index --> variant to data, everything is suddenly very fragile to cluster changes, not to say needlessly complicated.

If you could (un)bundle a control directly from the cluster reference you would have easy and very efficient access.

What should then happen for non control references? I'd say the same as 'property node --> value' with the name of the control displayed. It could even be possible to access variant data by using the variant --> cluster -->variant functions.

Of course this method is subject to race conditions, but that is always the case when you use references anyway.

I'm currently working on a project where I have 9-11 active parallel processes where each process needs access to the configuration cluster. Thus I have 9-11 copies of all my configuration data in memory all the time. I'd really love to reduce that number to one.

This is my first post here. I did check for similar ideas, but I didn't find one.

-Henrik, Denmark