LabVIEW Idea Exchange

Post an idea

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)

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

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)

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.

Morning forum

Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).

This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (http://www.ni.com/example/30986/en/), upon deployment failure and image restoration, the damage has not been reversed.

Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.

Thanks and have a great day...

View All (1)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

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

Snapshot option flash image for RAD utility

App Builder should support file splitting

Mass Compile should not change other folders