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
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
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.
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.
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:
Thank you for your time.
The CVT library is very useful in automation applications especially combined with the TCE tag editor and CDL data logger.
At the initial phase of the development of a new project, it could be useful to try new values for parameters and after evaluation, it could be nice to save them back to the XML CVT file as new defaults.
For this reason, it could be nice to add a Saving method to the CVT library.
MET Srl - Milan (Italy)
One of the many attractive things about LabVIEW, is the fact that if you can think logically, most likely, you could write LabVIEW code. However, there are lots of coding opportunities in the world, that require code that is developed in C or C++, especially products that use embedded SW.
Since "G" is based upon "C", I was wondering if it would be feasible to create a development tool that would allow the user to develop in LabVIEW, but also convert or create equivalent "C" or "C++" code that could could literally be inserted into a program. I've used the .dll creation utility for C developers to use in various "test" type applications, but have yet to find a way to use that method constructively for embedded projects.
When we open and not making any changes we close the code refering to the API of components which version differs from the version was used to write the code we are getting the standard message do we want ro save or deffer the changes or cancel the operation.
When we hit the buton/link 'Explain the changes' as the result we are getting the 'not explaining a lot' message: 'External component has been changed'.
It would be very practical to have the information what exacly has been changed.
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:
This application is used to track the Position of the person in the mall as the GPS will not work nicely in Indoor Area it can be help with Inertial Navigation System since all the current mobile phones comes with accelerometer and Gyroscope which are the basic parameters for the INS to be added with the last GPS fix will give more or less accurate position and with the essence this can also be integrated with RTLS tags and Cell Locate Algorithm and A-GPS inbuilt
Iam looking for Labview support on this so as the application can be completed quickly
I will go straight and may litter bit offend the guys working on developing labview in NI, that since labview 2010, there is less and less suppresses brought to the labview coding folks. But also since labview 2010, I've been 'pleased' most is that ni recognized that 'user driven' is one of the most eye attractting futures labview can provide to the developers. Why not you guys go further, release the labview sdk and turn product labview to platform labview. Then fans and geeks can improve labview developing experience along with the employees at ni directly and efficiently.
Here is my reasons:
1. A powerful and convenient developing environme
2. Not only normal engineers, but also professional software engineers choose labview as their developing tool. Trust me, current labview will drive them crazy, like me(three years "torching"). You can never control the threads or memory under the graphic programming concepts, though sometime it mattered.
3. There are so many ideas users want and sometime maybe they can realize it by themselves easily under the access to the labview sdk. Then new fractures can be shared, sold or contributed.
FOR THE ECOSYSTEM
4. We deserve an ecosystem for labview. Roles are like: labview market, developers, users, ni, etc.
敬请拍砖, in English means welcome criticizing~~~
Apologies for being heretical to LabVIEW.
Even the text-based coding world has room to leverage a good driver-hardware ecology.
There is a simple way to trigger linescan camera acquisiton controlled by an encoder, as is shown in LL Trigger Each Line From Encoder.vi example.
However, it is not possible to do it for frame cameras in a similar fashion.
Therefore I suggest that there is a way to configure "IMAQ Configure Trigger3.vi" in order to acquire a frame from a camera every N ticks from the encoder.
[idea thanks to a customer's request]
What do you think?
Have a great day!
I have an application that tests three products at a time. When a product is put on test, the user enters the serial number of the product, which pulls up the Excel datasheet for that product serial number.
The datasheet always comes up in the last saved location within the Excel window. I would like to control if this file appeared on the left side (where it currently is), center position, or right positon. Please see the attached screen shot.
It would be nice to force the datasheet to open in a certain location in the window.
Allow user to preselect which libraries to load when inserting ActiveX Objects or .Net Control and same for constants.
Bring frequently used on the top or make it user favorites...
Would it be possible to write a driver for a Dionex dual gradient pump? We have a custom valve setup but are very interested in the capabilities that a Dionex ICS-5000 DP offers. The pump is operated with Dionex's Chromeleon software, which unfortunately won't operate our chromatography setup, which we currently contorl with LabView. The critical issue will be timing of the pump operation and switching of the valve setup.
Allow the configuration portion of DLL nodes to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).