Password protected VIs can be imported and saved to a newer version of LabView. However, the password protected VIs can't be saved to a previous version of LabView. I am suggesting for LabView to keep a copy of the old version of password protected VIs and give a warning during upgrading to a newer version in case one has to convert to an older version.
I have two controllers under the same project . and both will run similar application. so i use same source code for both the controllers. and i don't want to disable auto deployment of variables. apllication is deployed controller one and it's running. after that if i deploy application to controller -2 unfortunately target settings Target 1 also deployed while deploying application on target 2 . it should be rectified
Recently DMC developed a high speed vision inspection system using LabVIEW. This system inspects many different parts and each part requires different inspection criteria, so we needed to develop a user interface (UI) that could be used to configure the current products, as well as be flexible enough to configure new products.
The manufacturing machine was already running on a Windows CE device, so our UI would need to interface with the UI already on the system and run on Windows CE. For a faster development time we decided to go with C# .NET for Windows CE. Unfortunately, the .NET library and functionality for Windows CE is far less capable than the standard .NET library.
The Windows CE library was sufficient for most of our needs, but there were two areas that proved fairly difficult. The first difficult item was obtaining and decoding the custom TCP messages that contained the images and inspection results from the LabVIEW Embedded Vision System that was running the vision inspection. However, after spending some time encoding and decoding the images, the UI was able to access full-sized images from the inspection system. The next difficulty was that once these images were on the UI we needed to be able to zoom, pan, and draw inspection areas on the image. In a full .NET library this would have been really simple, but for a Windows CE device it required some custom work. The first step was to create a custom control and place just a picture box inside. Additionally, I set the SizeMode to StretchImage. By having the image take up whatever size the picture box was, I was able to zoom by increasing/decreasing the size of the picture box. Additionally, I was able to pan by moving the picture box relative to the custom control.
I have included all of the back-end code that I used to make the image behave as I wanted. The code I had was significantly more complicated, as I needed to be able to draw and pan rectangles that were used for inspection zones. I tried to remove all of that code to make the items I am explaining more clear; however, if anything seems odd, it is likely a remaining piece of the old code. If anyone is interested in the rectangle drawing code I would be happy to provide more information. Here is a link to the simplified code:
Many modules aren't compatible with Labview 2010 64 bit, but there is no warning of that before installing Labview 2010 64 bit. So the user goes through hour(s) to install the software, only to realize it won't work when he/she installs a module (Real Time Module for example), and then has to uninstall and reinstall the 32 bit version. If it isn't compatible, let people know so they don't waste hours!
I did a search and did not find this. Hopefully it is not a dupe.
The event structure has become an almost integral part of LabVIEW programming. It should no longer be considered an advanced tool that is only needed in the full development system and higher. Events should be included in the base package. Maybe it means slightly increasing the cost of base and slightly decreasing the price of full. I don't know. But there should not be a LabVIEW that does not include the event structure. I own (my company owns) the development suite so I get nothing out of this. But if I were to buy my own copy I could almost see spending $1,249 but definately not $2,599. I am not going to spend over a grand for events and I am not going to program in LabVIEW without them either. So maybe someday, if this idea is accepted, I will get something out of it. And so will National Instruments.
Give the user the ability to upgrade versions of Teststand or labview without bringing the test equipment down for several hours. Currently it is quicker to image the whole pc than install a new NI software version. Some of the software (from other vendors) we run has propretiary configuration and imaging isn't always feasible. I would like to be able to upgrade from Labview 8.6 to 2010 without stopping production, just upgraded from 8.2 to 8.6 and on 50computers, on a production floor, it was logistically difficult. It would be a while before I consider upgrading again, with the current setup.
I often need to build applications and installers that include VIs or .LLBs that have been built earlier on...but this is a major pain because as long as LabVIEW recognises the file type it will try to link the VI or VIs in the library to the other VIs in the project, it finds conflicts etc. There are ways to come around it yes, but not very elegant ones.
Basically what I want is for projects to be able to treat VIs and LLB files as non-LabVIEW files. Just like you can include a text file, a JPG picture or other files in your project and installers I want it to be simple to add "completed" LabVIEW files.
One solution could be to have another type of project folder. We have auto-populating folders...perhaps we could have a folder for pre-compiled / to be treated as external sources folder...? In most cases for me LabVIEW could just see that the file does not contain any source code and then treat it as a "dead" file..or at least give you the option to do so (if there is a potential conflict).
Living in the dark ages I do not have web access on my LV development PCs and so have to go to www.ni.com/activate to turn on LV after every update/install. If I am lucky I can sit my LV machine beside my web PC and type in the computer ID code and vice-versa with the resulting authorization code. If I am unlucky bits of paper, pens and walking become involved. Having to authorise on each PC is reasonable but if I need to authorize more than one product e.g. LV and Application Builder (I have the Pro version) then not only do I have to licence 2 things but I have to enter ALL the data twice - a simple 'activate another product' button at the end of the activation pages (with data like pc id and licence number and name etc retained) would make life easier. My appologies if there is one already - but if there is it needs to be more obvious.
We need the ability to manage multiple volume licenses from a single VLM instance. We have several groups from different cost centers that use LV; however, currently all the license administration falls on me. The only solutions available at this time are:
Merge all the licensing needs from each group into a single license. This is a nightmare for me. For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays. Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file. If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license. If a group wants to add products to their license, all requests get funnelled through me. This might be good for NI, but it's a royal PITA for me. (License administration is something I do in my "spare" time.) Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
Maintain separate computers for each VLA. From an ease-of-use perspective this is almost as bad as option 1. From a practical perspective this is worse than option 1. It's silly to have several different computers sitting around doing nothing other than running a license server. Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.
Neither of these solutions work very well. I don't mind the license administration part of the job. Creating installers, changing permissions, and stuff like that doesn't really take that much time. What is killing me is the account administration part of the job. The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all. What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements. When they get the license file they can send it to me and I'll install it in the VLM.
I envision each VLA having it's own root node in the tree diagram. Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc. (I have to be able to rename or annotate the root node for each VLA.) The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.