 |
|
||||||||||||
We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.
Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build.
I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO
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.
Hi,
what does the community think about configurable automatic type conversion between .NET and LabVIEW? We need to deal with a .NET API for a sensor which handles system time with nanoseconds since the 16th century. Don't know why they're doing this stuff.
To set the appropriate time you have to substract two .NET DateTimes. Everybody will know this will look like in LabVIEW.
You will have to use a method of the object to substract this. Now you're using DateTime.Substract. This means in LabVIEW.
Here it would be nice to have a checkable item in the right-click run-time menu for the invoke / property node to select or deselect the automatic type conversion so that the Substract() method would accept a DateTime class and not a LabVIEW timestamp.
Hope the idea is clear enough. I've checked the idea forum for this entry but didn't found it. If so, don't shoot me for a double post.
Tyler.
Vision Assistant creates code for raising an error if the coordinate system is invalid. The code would look much nicer when the VI "IMAQ TransformROI" would check for validity of a coordinate system. Or when at least the error would be checked in a SubVI.
The generated code currently looks like this: With the SubVI it would look like this: And with error handling in IMAQ TransformROI like this:
The SubVI would contain code similar to this one:
Have a LabVIEW Idea?- Browse by label or search in the LabVIEW 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!
- If your idea has not been submitted click
Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea. - Watch as the community gives your idea kudos and adds their input.
- As NI R&D considers the idea, they will change the idea status.
- Give kudos to other ideas that you would like to see in a future version of LabVIEW!
|
||
|
||
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. |  E-Mail this Page
|
||
|
||