LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Set exe to run as admin

I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.

When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.

Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?

Dear All,

Currently to use LabVIEW in a functional way you have to spend about $5000 to get the bells and whistles.

Large corporations don't have a problem, but there is a lot of normal people that would like to have LabVIEW but are not students and can't justify spending that amount on software that they may use only occasionally, but would like to have.

Adobe has moved away from the (legacy) model where you buy and own your copy of the software, to a subscription based model ($20 to $50 a month) where you get ALL the LATEST version of EVERY application they make, as long as you pay your monthly bill. I was reluctant to use that model but I finally subcribed, and let me tell you it saves me a ton of cash, and I get whatever I need at the latest version.

National Instruments high-level management and marketing department should seriously consider moving forward and making an AFFORDABLE monthly subscription scheme, like Adobe succesfully did. This would benefit NI by getting some money out of folks like me, and would ensure that the whole world would be using the latest versions of it's products.

Successful companies are the ones that make available the best products and services to the BROADEST range of people (e.g. Google, Microsoft, Adobe). Restricting access to technology based on income will hurt National Instruments in the long run.

With best regards,

Rollin McCarty

View All (2)

When you create an installer package with a default destination path that is not available on the machine where you want to install the package later, the installer stops with an error message. You have not the chance to install the package somewhere else.

So my idea is to show a warning only and let the user define a new location afterwards.

here I create a installer with the default destination path D:\...

When I run this installer on a machine that has no D:\ drive, I have no possibility to install the package. I also cannot select annother location.

Note: of course a bigfix for this problem is a default destination path that is available on every machine (e.g. c:\), but in some usecases you want to force the user to install the application in a defined folder like D:\tools\

The I2C Digital Waveform Reference Library is a good choice to test the I2C Interface with timings that

are outside the specification. This is important for the developers to invesigate what happens when a

new designed chip get a not specified I2C signal.

Citation from the readme file:

Supported Targets

This component is compatible with the following LabVIEW 8.6 (or later) targets

LabVIEW for Windows Vista/XP/2000

The API library and installed examples may be compatible with other LabVIEW targets, but they have not been tested.

---

Unfortunately the Library needs the LabView 8.6 Run-Time Library installed and it is not certain that it work with Windows 7 and

LabVIEW 2012. (I tested it and it works with this combination ) It would be nice if the Library can be updated and tested for

Windows 7 and LabVIEW 2012, to prevent that developers are uncertain if this "old" Library still works.

View All (6)

Hello!

For anyone who works on a PC that is not connected to the internet, but is is using a third party instrument, they could experience problems trying to view example VIs that ship with the instrument driver.

Currently with LV 2010, if one does not have an internet connection on a PC and navigates to Tools » Instrumentation » Find Instrument Drivers..., the NI Instrument Driver Finder Dialog Box will close after displaying the following pop up:

Please made the NI Instrument Driver Finder available for PCs not connected to the internet.

Since the customer already installed the driver for his third party device, the Agilent E8364C, I made him aware that all of the top level, demo VIs are located on his machine in the *.llb file of his driver under the instr.lib folder. This work around will suffice for this customer, but anyone without knowledge of our directory structure would struggle with this.

Thanks!

Shawn S.

View All (9)

Hi,

I am currently working on a quite large project, addressing different customers / users. Therefore I have in this project several specifications for executables and for isntallers. The point is, I would like to be able to right-click an installer build specification, choose build, and every executable used in the installer specification is built as well. Today, I have to remind and select all required executable specifications, and build them prior to installer building.

Front panel Text color change

View All (2)

How come you can't tell which version a .vi was created in until you open it? How come you can't just tell whether it was created for 7.1 or 2010? An idea is to have it save a different .vi extention, much like in Microsoft Office, for exampe, a 2003 version would not open a 2007 version, and you can tell before opening because of the .xls or other extension. For labview, it could be like for 7.1 it was .vi71 and for Labview 8.2, .vi82, and for 2010, how about .vi2010?

Maybe this could come in handy for those who are looking for certain vi's of a certain version.

I have used Labview for about 10 years, the last 4 years complete full time as my actual job requires it, several times I have gotten a tired sight which made difficult to read Labview code, I really wonder if there are plans to add some zoom functionality.

In fact it would be nice to have a magnifying glass on the tools pallet, with a sort of resizeble frame that let you follow the code. There should be an rights explanation, because I feel this idea is kind of obvious, and also I am sure that tons of new users quit trying because this lack of functionanlity.

anyway let me know your comments,

View All (5)

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

Too Many Updates to Run-Time Engine!

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 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.

View All (1)

View All (2)

I installed LabVIEW 2020 on my PC and my friend is working with LabVIEW 2016 every time I open his projekt now it gets upconverted and if I downconvert it to 2016 I can only do it via the special option, which does not even allow me to overwrite the original 2016 files. Iam stuck with 2020 since I did not buy SSP GREAT, how is this in any way userfriendly? Its worse then the compatibility of Word with Libre office.

That was Bryans original post 12 years ago, its still the same.

https://forums.ni.com/t5/LabVIEW/How-do-I-continue-to-save-for-previous-version/m-p/4143151#M1194547

When installing recent updates for LabVIEW 2018 an error message came up that said the installer needs access to "My Documents". However this location "file path" is not available. My company has a drive mapping package that has the my documents located on the server as well as my favorites so it is automatically backed up for recovery purposes. The installer keeps getting this error and forums state that the IT admins need to get involved every time to update & set my documents to local temporarily to install, then back to the server for automatic backups. This is very tedious and takes a lot of manpower. My colleague has the same issue with DIAdem 2018 as well. Looking to possibly have a fix where it gives the user a browse option to find the file path it needs for the install.

View All (4)

LabView Linux Installation

We like to keep the OS installation clean/stock. That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required. Typically the EDA vendors will have a script that checks that all of the Linux package required the application. If we find any dependencies we install on all machines. The LabView Linux installation script wants to be run as root and install packages. Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed.

For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually. The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.

View All (2)

It might be worth exploring the feasibility of having an online vi upgrade/downgrade service, where you could submit your vi, and receive back the new vi.

I realize this wold be a huge undertaking, however, a reasonable fee could be charged. It could be a second option, in case the customer:

Has tried to do this on their own and failed

Does not have the intermediate versions to perform the required jumps

Isn't worth their time considering the cost of the service

In the case of upgrading a vi, this could serve as an added incentive to invest in the latest version of Labview, especially if the customer is several versions behind.

LabVIEW Idea Exchange

Set exe to run as admin

Move to a Monthly/Yearly Subscription Model instead (Rental) instead of Buying the software

Improvement of the installer: Problem with not available destination path

Update of the "I2C Digital Waveform Reference Library"

Online Driver Installer Builder

Disk Space Estimation Based on Components Selected for Developer Suite Install

NI Instrument Driver Finder Dialog Box Closes if Not Connected to Internet

Building executables when required by installer

Front panel Text color change

Labview Version-Dependent name extention, not just .vi

Why Labview doesnt have ZOOM tools on the Blockdiagram side?

Optionally remove conditionally disabled cases from source distributions

Too Many Updates to Run-Time Engine!

Linux Support for RealTime RIO Devices

nipcibrd.sys SYSTEM_THREAD_EXCEPTION_NOT_HANDLED BSOD

Why is Labview so bad in downwards compatibility?

Stop using removable drives as a temporary location for installation

LabView Linux Installation

Fix the Horrendous Licensing/Activation issues in LabVIEW 2018

Online service to convert Labview vi to different Labview version