LabVIEW Idea Exchange

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

When installing the driver DVD, it is possible to select a drive, but this still installs 3GB of data to drive c: . I know some things must probably stayy on C, but I imagine alot less than 3GB.

 

See image below.

 

Driver disk usage

 

Miha

I think the application builder should be able to generate a standalone applicationwithout the need to install the LabVIEW runtime engine, to reduce the user to install anduse the program to do the steps are too complicated or complex to install, or can becalled "hidden install" or "incidental installation", and will install all the files are placed in a program (such as VIPM installer). Best to install the non-LabVIEW files (like DOCdocuments, pictures, msi installation package, etc.).

When building an installer have the builder scan all .vi's in order to include all addition installers that need to be installed.

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.

 

 

 

 

 

 

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

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.

When you use "Labview Web server", you cannot access your Labview front panels using IE from a PC with no Labview Runtime.

 

To make it work you have to install a Labview runtime, or deploy manually some dll's ...

 

So, it would be nice to create a "light Labview Web client installer" in order to only install the minimum required.

 

Manu.

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:smileyhappy:

 

I like using Linux whenever I can, particularly when running large software like LabVIEW, since it tends to crawl on my XP systems. I was happy to realize that LabVIEW works on Linux, but soon after I was disappointed by the lack of usefulness of it when interfacing with hardware. I need to use the RealTime module to interface with my RealTime Compact-RIO. I also need Linux support for the FPGA module, as I need to program the FPGA attached to my cRIO. I'm sure I am not the only person who would like the ability to do this.

 

Without support for any of the hardware or LabVIEW modules I need, the Linux version of LabVIEW is entirely useless to me, and XP as an OS simply cannot perform up to par for me.

Trying to toggle back and forth between the instructions and the code for the online CLD exam was both distracting and difficult since most hot keys didn't work. Placing the instructions or goals in the block diagram would allow easier reference for those taking the exam. 

Hello forum

 

Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.

 

Thanks

hello forum

 

what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...

 

the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like

 

it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial

 

one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.

 

what do you think?

Yes, this is a corner case, but it has bitten more than once.  There's no way to deactivate then reactivate third-party plugin licenses for off-line (No internet) LabView development machines.  These machines need upgrading and they fail just as often as internet connected machines, yet third party plug-ins are often left in limbo when the computer ID's change.

 

NI should recommend and support third party deactivation for off-line machines (EX: https://support.softwarekey.com/index.php?/Knowledgebase/Article/View/28/54/how-do-i-know-my-client-entered-the-trigger-code-to-deactivate-his-computer) via softwarekey.ni.com.

 

Please can the installer be changed to stop using removable drives as a temporary location for installation files. I had a 2TB drive attached when I started the install and "safely removed" it part way through. The install then failed Smiley Frustrated

I assume it uses the largest attached drive available. If possible could it check for the fastest drive instead. My main drive is an SSD with an HDD as the secondary drive which is larger. The SSD would have been the best choice in this instance.

LabVIEW Projects can use an icon in the exe, but not when running in development, and not in the built installer. 

 

Add to the LabVIEW project to have a property to set a project icon. With the Project icon, when running in development mode, it can use that icon instead of the standard LabVIEW one. Extremely useful when trying to give demos, screen shots to send to customers and building an exe is not working, feasible or designing on the fly. There is a hack you can do using the shell32.dll that on open of any LabVIEW panel, it can rewrite the icon, but then code must be added for any and every panel to show the icon. Also if the window name changes, you have to call the same code again. 

 

The installer also does not inherit the icon from the executable being installed. Add an option to add an icon to the installer and have it embedded in the setup.exe. Also include the registry setting for DisplayIcon = Icon path to exe or to defined icon. I've currently been able to change the setup.exe icon using the Resource Tuner application (www.heaventools.com for $50). It's as simple as changing the IconGroup 128 with your own icon and save the exe. This embeds the icon to show up in Windows Explorer and as the icon when running the installer.

 

The wrinkle is that the installer does not have any pointer in the Add/Remove list for Windows for the icon. You have to know the ProductID and ProductCode which changes every time you build the installer, as it is in the setup.ini file at the bottom. Going to the 32bit or 64bit registry (depending on what you are installing), you have to add a new string key "DisplayIcon" and it can point to any icon file or the exe using the path.exe,0 to represent what icon to use. The path to the reg key is somthing like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{E851D69F-49EE-4B9C-BAE7-58AB782E801A}\DisplayIcon. I'm currently developing an exe to run after the installation to set the registry key properly. It takes command line arguments for the Product Name (search registry for the GUID), path to icon/exe to set. This way each installer uses the same executable (LabVIEW built) to set the icon in the add/remove list properly. 

To be honest, I am not entirely sure what that means. Only that my IT department says NI downloads do not have a valid signature and the firewall blocks them. Currently we are working through this "http://www.ni.com/white-paper/12402/en/" , but I am not convinced the answer is there for us. I am able to download files from any website that I currently use here at work so I don't understand why NI downloads would have a problem. By the way, this is using the NI downloader or using manual download, neither method works. Using other browsers yeilds nothing either. Cruising the internet for similar problems came up with "Software Publisher’s Digital Certificate", is it possible NI's isn't valid or something?

Anyway, seeing as how internet security is just going to get tighter and firewalls more strict, I don't want hokey solution that will just break with another update. Anybody got an answer for this delima?

Robert

Right now, we can build an installer which embeds other installers (e.g. the LVRTE).  So we can distribute the installer and allow our customers to install everything they need using one installer.  This is great.  But I find that it sometimes disturbs my customers when they see that my application is also installing other things (i.e. LVRTE, DAQmx, etc).  They are curious about the "3rd Party Components".  I totally understand this.  When I download an installer, and see things like "Click here to also install Google Chrome" or Google Earth or some other spyware garbage, I am immediately suspicious.  Or worse, when I am not even warned about.  Bundling other installers is a common way to spread adware.  

 

Problem:

- Bundling third party componenets into an installer is suspicious to many users. 

- Bunlding extra installers also makes the un-intall process more complex (you have to uninstall things the extra stuff in a different step).

- Current method of bundling extra installers does not inform the user about all of the components being installed

 

 

So my suggestion:  Allow these components to be bundled (i.e. hidden) in the application directory.  I believe this is already possible with other run-time engines like the Java Runtime Engime.  And I see that something similar is possible with LabWindows/CVI (see here), though I have never used LabWindows.

 

I guess another way to do this is just to somehow hide the extra stuff from the user.  Do a silent install of all the 3rd party componenets.  But I feel like that is a bit devious, and might piss off some customers.

Create two versions of the LabVIEW Run-Time Engine - 1 with dependencies (vi.lib, etc.) and 1 without dependencies.  If a LabVIEW Run-Time Engine with dependencies were to be created, it would allow you to bypass the TestStand Deployment Utility when deploying test software created using TestStand.  It would also simplify Application Builder because any native dependencies (code shipping with LabVIEW) wouldn't have to be packaged with a LabVIEW executable (only the user-created dependencies).

 

If maintaining two versions of the LabVIEW Run-Time Engine isn't acceptable, it would be nice to just include the dependencies in the LabVIEW Run-Time Engine.  Disk space and broadband Internet connections have almost virtually eliminated the necessity for a LabVIEW Run-Time Engine with a small disk or installer footprint, particulalry when NI hardwire driver installers take up 100s or even 1000s of MB on disk.

Current versions of Developer suite do not include Autmotive Diagnostic Command Set
 in the DVD's for installation onto a host PC, the toolkit has to be downloaded separately which can be difficult to find as it is not referenced on the support pages, for those interested the 1.1.1 release is here:

 

ADCS 1.1.1

URL:http://joule.ni.com/nidu/cds/view/p/id/3153/lang/en

 

My thought is that this should become more integrated into the release DVD's as it is a Labview add-on and should be treated the same as all the others.

When developing an unattended installation, creation of the specfile allows customized installation choices.

 

Due to the number of choices, I have rerun 2013DS1DVD1_ENG\setup.exe /generatespecfile more than once and NI Device Drivers DVD - February 2013\setup.exe several times to add or remove one or two options.

 

Adding the capability of loading a specfile when launching setup with /generatespecfile filename1 /loadspecfile filename2 would allow the easy editing/modification of the specfile by the installation creator reducing the time necessary to make a custom automated installation of the NI software.