LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

Provide an option to display a QR (2-D) code in the product activation dialog.  The QR code should contain a web address that would return the activation codes for all selected products.  For those of us stuck out in a lab or factory with only our smart phones this would provide a slick, foolproof way to enter all of the data needed.  It would save us from either making a round trip back to civilization (with a pad full of info) or getting carpal-tunnel trying to type all that stuff in on a little soft keyboard (multiple times for multiple activations = hand cramp).  We would still have to type the resulting activation codes into the LabVIEW activation screen but that's a lot easier than all the rest.

 

Idea details:

1) Provide a http link as a QR code 

ExampleNIActivateQRcode.png

2) Have the target web page auto-generate the activation codes and display them (preferably in a mobile browser friendly format)

3) As an alternative, let the user upload a picture with the QR code to the NI activation web site for the same result (works for anyone with a camera not just smartphone users -- this would also let you show off IMAQ.)

4) Profit

 

(And, once you have the QR-code generation code available, add a VI for it to LabVIEW -- see http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Generate-Barcodes-in-LabVIEW/idi-p/1283912)

 

The Windows 7 file permissions in the Program Files directory are causing a lot of headaches, especially with *.ini files of existing applications. It would be nice if LabVIEW had an option where install file paths of these files could be set based on the system they are going on. For instance, if the installer is being run on Windows XP, the installer will know to put the ini files in <Program Files>\<App Name>\Config but on Windows 7 install the files to <User>\Local Settings\... or whatever we choose.

 

Right now it seems our only option is to build 2 installers and have a batch file decide which to run. Unless, of course, someone can tell me otherwise.

If you are going to call it a developer suite, put the developer tools in it. The following toolkits need to be added:

Of course this will increase the cost of the developer suite. I find it easier to convince my boss to approve a cost increase versus purchasing a new toolkit.

Hello,

 

I have recently installed a new PC under Windows seven with the complete 2010 developer suite ...

On this PC i have to run an old CVI application which use traditional Daq ... and it don't work for known compatibility reasons !

But i get this information after many web searches and NI support investigations ... 

 

It should be nice to add a compatibility icon in the developer suite and device driver installers, in order to view the compatibility of each product to install.

 

It should be a way to rapidly know if a product will work or not, or will perhaps work with no garanties ... on a specified Operating system.

The icon should be something similar with a traffic light : Green => The product is OK, Orange => The compatibility is hazardous, Red => No compatible at all ! 

 

Manu.net

 

 

This idea is about a new LabVIEW feature, the Packed Project Library.

 

To statically use a packed library as a dependency, you need to add the library to the LabVIEW project.  After that's done, all the callers link to the packed library.  If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.

 

But what happens if you're a packed library user and developer of the same library.  You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.

 

If you're a user and developer, it makes sense (to me) to maintain two separate projects.  One manages the packed library resource, one manages the application.

 

What if there were a way to revert the packed library to the LabVIEW library from the same project?  You could use the spiral development model and simply switch between the two types of libraries during development.  You could also (and this IMHO is the most important part) incrementally deploy and test the project.  If you're strictly a packed library developer, hopefully you're incrementally testing anyway.

 

My final pain point with the packed library is with respect to upgrading the application.  Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade.  If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp.  Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself.  I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).

 

This leads me to a best-practice for lvlibp: always use them as dynamic dependencies.  That way, you can maintain and develop the packed library in the same project that uses the packed library.  You'll simply reference the resources differently.

 

Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.

 

Thanks!

 

Steve

Hi, i wanted to suggest the creation of a separate utility software that would convert a VI from any version to any other version. This would save people a lot of time by not waiting to get it converted from their respective threads. Also it would serve for more people to able to reply on the forum(me included since i am using LabVIEW 8.6 and most of the posts contain VIs made in 2009 and 2010 even though most of the time the same functions are avalable in 8.6 😞 ).

 

 

PS: Sorry, got no pictures

 

Within LabVIEW Build Specs you can specify a version for an executable that is built.  You can presently see this from within the Windows add/remove program and there are some funky ways of getting this version with .net or WinAPI calls but you should be able to do this from LabVIEW similar to the app version as shown below.

 

appversion.JPG

 

This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.

While NI provides (thank you) reasonable support for OS X these days, the support for installs and updates "on line" are very far behind those for Windows.

 

For instance, there does not appear to be any option to download Labview 2010 for Mac but I can for Windows.

 

 

We just bought LabVIEW 2010 and I noticed that there is no utility avaible for converting a function panel (.fp) to a VI.  When will this utility be available?

HABF?

 

An acronym for one of my favorite Spolskyisms. Great article, read it.

 

Background

 

When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.

 

Problems with Current Issue Tracking Platform

 

"Platform" is a generous term for the current reporting and tracking process:

 

  1. The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
  2. Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
  3. Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
  4. Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms

 

Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. Smiley Very Happy The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.

 

I want to see an analogue for Issue Tracking.

 

Proposed Solution

 

A web-based platform with the following capabilities:

 

  1. Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
  2. Allow embedded video screen captures (such as Jing)
  3. Allow uploaded files that demonstrate reproduceable issues
  4. Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
  5. Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
  6. Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
  7. The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
  8. A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
  9. Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
  10. An email-based alert system, letting you know when the status or content changes in bug reports of interest (:thumbup1:)
  11. Same username and logon as the Forums
  12. Bonus: Visible download links to patches and other bug-related minutiae

 

Additional Thoughts

 

  • I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
  • I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
  • Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.

 

BugFeature.png

(Picture first spotted on Breakpoint)

 

Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.

 

My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

I recently retired from my job as an electronics engineer. Prior to leaving I had been using LabVIEW to create a number of scientific instruments based on data collection and logging. I attended a couple of training courses in Newbury and was getting quite comfortable with the software. Unfortunately I no longer have access to LV and the educational discount option available from the company no longer applies for me.

 

However just because I have retired does not mean that I do not want to generate more projects using the knowledge gained during employment. My main area of interest is home automation, alt energy monitoring and control etc. I am finding it very frustrating that things I could do quickly and easily in LV have to be achieved using other software, this means yet another learning curve.

 

I downloaded SignalExpress LE a while back and was hoping that the software may go just a bit beyond data logging but it does not. There is no way to manipulate data in real time so again I have to look for other software.

 

The full version of LV is priced too high for my application and it occurred to me that there may be an opportunity for NI to provide a stripped down version of LV for consumer use. This version would need to include vesa, basic arrays, basic math, boolean and charting etc. The inclusion of drivers for 1 wire devices would also increase the appeal plus ready made vi's for the usb acquisition hardware. Pricing may be an issue but for non-commercial use it would have to be well below £100

 

Incidently I was contacted by customer support shortly after downloading SE LE and it was during our conversation he suggested that a post on this site may be appropriate.

 

 

 

 

 

 

When I build a LabVIEW application, I do not include the runtime engine in the installer.  Instead, I have a separate project that builds an installer for all the runtime components my applications need.  That way, my users can perform the runtime installation once and then update the app separately many times.  This keeps my installer sizes small and easy to distribute.

One issue I run into is when I move to a new version of LabVIEW.  I need to make sure all my users update their systems to the new runtime engine before they try to install and run my latest release.  Unfortunately there is no way to enforce this in the installer.  You can check for an installation of the LabVIEW development environment (see image) but that is not very useful.

So, my idea is to add the option to check for the presence of the runtime engine for the version of LabVIEW you are using to build your installer.

Additionally, it would be nice to have a way to check for other required components, such as .NET versions or other NI runtime components or drivers.  This is similar to an idea I posted a while ago here.

 

 

installer idea.png

There should be an option to choose which version of LabVIEW want to

build your application, so would only be loading the vi's corresponding to avoid

version compatibility problems.

 

Further updates NI LabVIEW should create, so each developer would install

 the latest version and any patches that were wanted to use.

 

If I owned the LabVIEW 2010 and would want to work with  8.6 would install

a patch for this version and not like today having to install the LabVIEW 8.6 whole

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

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.

The right side of LabVIEW Getting Started window presents links to resources can help the LabVIEW user to be successful in its application development.

 

With LabVIEW2009 links that update dynamically has been added under Latest from ni.com. I found very useful to be updated on LabVIEW News directly from the Getting Started window but I would like to see the news published by the local branch.

 

23228iDFFD4ED2A79110E5

 

If the link is localized, I can be updated on new events organized in my Country, on new products release and announcements written in my native language.

The Registry Settings within the Build Spec from an installer is using fixed values only.

 

It would be nice to have somthing like varaibles that contain the information that are entered on the page
"Productinformation" in the settings window from the installer.

 

Productname -> %productname

Productversion -> %productversion

User selected Path for installation -> %installdir

 

This would allow something like this:

 

22863iA75EB0F1A77A1685

 

The values {%productversion} etc. will be replaced during the setup with the real values. The %installdir contain

the selected installation dir from the user.

 

At my current work place we use proxy servers as an internet connection. With LabVIEW it makes it difficult not only while the NI software is being installed (to check for updates, connect with server for veryfication etc) but also during typical work it makes troubles with finding examples and drivers from a development enviroment.

 

I would suggest adding some advenced internet connection options for proxy settings etc.

 

Another little thing with a company computers is that, even when installing NI software on a D drive it still installs some example software on C:. It makes problem when your IT limited your C drive for absolute minimum, because with huge amount of NI software the amound of "additional" data is getting bigger and bigger.

 

Regards,

 

PacHOOk