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:
The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
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. 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.
A web-based platform with the following capabilities:
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
Allow embedded video screen captures (such as Jing)
Allow uploaded files that demonstrate reproduceable issues
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)
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.
Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
Same username and logon as the Forums
Bonus: Visible download links to patches and other bug-related minutiae
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.
(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 toadd 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.
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.
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.
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.
There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode.
By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.
The level of alerts can be configurable, of course.
LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in. Add a header to the file to allow LabVIEW to open the file in the correct version. This will save a lot of time and lower frustration of accidently saving a file in the newer version.
Our facility runs only one version of labview at a time and that majority of time for installing a new version is spent removing the old version. A check box on the installer to remove or update the previous version would be a great addition. In recognizing that several companies must support multiple versions of labview removing the previous version should just be an option, not required. 2nd having the option to select all toolkits and addons to install from the first disk then just a prompt for the other install disks as needed would really speed up the install process as well.
This is not my idea, but I did not see it here and it is a good one so here goes. A lot of people used to deliver chunks of code as DLLs or EXEs but not use them as DLLs or EXEs. Instead they would use them like LLBs and make VI server calls to them. This was possible because when it came right down to it, these DLLs and EXEs were LLBs with extra stuff. This changed after 8.2. No worries because there is the source distribution. Except that the the source distribution is exactly what it sounds like. It is a copy of the source meant to be sent to some other developer. It does not do any of the compile time processing, such as remove conditionally disabled code, that the DLL and EXE builds do. Delivering drivers and other chunks of code as LLBs is a convenient way to distribute patches and so on. But if any of your code has conditional disables, it won't work. The suggestion is to allow the option in the Build menu to remove conditionally disabled code from the source distribution. Here is a thread that discusses the issue. http://forums.ni.com/t5/LabVIEW/conditional-disable-no-longer-works/m-p/1109759
I remember this in previous (pre-8.2) versions of LabVIEW - not sure why it was removed. I have a use case to use projects as templates (like when someone wants to write a plugin for a utility I've written, I want to be able to send them a zip containing a project, methods, etc). The project includes installer settings (so their files go into the right place under my util's plugins folder, but when they build and try to install their plugin, they get an error if another plugin bult using the same template has already been installed. This is because the "Upgrade Code" (stored in the lvproj file) is the same (it tells Windows that the two products are the same, so subsequent installs are seen as upgrades or replacements, not new installs.
My memory tells me that I used to be able to hit a "Generate" button somewhere which would give me build a new code - all I'm asking for is that back (I can add a step in my work instruction to hit that button before you build).
I don't currently have a workaround for this (other than having engineers manually edit the lvproj file) - if anyone has a better idea, I'd love to hear it for the interim!