LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Most of the time the only part of a VI that needs protection is the block diagram but there are a few instances of why including the front panel in the password-protection would be needed. Someone can see the front panel of a subVI during run-time even if it is under layers of password-protected subVIs.

For instance, an encryption application. Except for the Top Level VI, all other VI's are password-protected.

During run-time, the Key for the encryption algorithm, which should never be known, is shown on the front panel of the Key Generation VI as well as the Encryption SubVI.

Of course one work around for this would be to hide all items on the front panel of each subVI but this will slow down further development in the future. The ability to just type in a password would allow a developer to instantly return to work.

Also, an alternative solution would be to allow password-protected Source Distributions.

Can anyone else think of an application in which the front panel of a VI should be password-protected?

Other Notes:

It is important to mention that it is possible to do things like Remove the Front Panel or Remove the Block Diagram, but this does not allow the VI to be recompiled for different targets. This is why a password-protected Source Distribution would be ideal.

The 'Context Help' window shows the use of each connection for a sub-vi, but in a multi-developer environment, opening a sub-vi is often necessary - especially for math & data analysis.

How about a button (selection like 'lock context help') in Context Help that enables the display of block diagram of the sub-vi below the connector pane?

Also, the author of sub-vi could pre-decide what part to include in this 'Context image' instead of complete diagram, thereby suppressing trivial parts.

it would be great if there would be a better platform for 3rd party VIs, for example instrument drivers. Something that allows you to see when the last updates where done, what has been changed (browse the code) and also something that would allow you to branch from the existing code, add changes and sent a pull request back in a way that other people can see that the VI has been branched, so that they don't need to duplicate their effort.Including an issue tracker with this would also be great.

This in my view provides faster turnaround for fixing bugs and adding new features. I had to fix a few bugs in some drivers, emailed the VI back to NI and since then nothing has happened to the driver at the least the last few times I checked and there is not a good way of tracking this. The idea is not new and there are lots of platforms like this around in the open source world. Here are some examples:

github http://github.com (version controlled history, branching, merging, issue tracker, per project wiki)

bitbucket http://bitbucket.org/ (similar to github)

Lots of linux distributions manage their source code this way:

OpenSUSE build server: http://build.opensuse.com (version controlled history, branching, merging)

Launchpad https://launchpad.net/ (version controlled history, branching, merging, issue tracker, code review, translation)

and there are plenty of other sites.

View All (3)

For Reports it is only possible to set one with for all columns. It would be nice if the polimorphic VI "Append Table to Report.vi" would support column with for multiple columns too. Several VIs would have to be copied and adapted.

For a standard report, the VI replacing "Set Table Column With.vi" would look like this:

The functionality to adapt to the page with if the column with is too big is lost when different withs are set. But probably NI could fix this too.

Greetings,

shb

View All (2)

'Lock Library' via scripting

View All (1)

Let's Encrypt support for NI web server

View All (2)

One of the things LabVIEW is best at is its innate parallelism. Parallelizing for loops with a right-click is something other languages wish they had. Having all code on the block diagram (or equivalent) innately run in parallel is something few other languages have even tried, much less succeeded at.

Crunching large datasets can be sped up through use of GPUs, and over the past decade or more, Nvidia has kept their promise of having a common interface to their hardware through CUDA.

Having a LabVIEW add-on that is well maintained, and that can give GPU parallelism in the same ways we've seen LabVIEW deliver CPU parallelism would be a game changer for many labs and manufacturing environments. It could also help LabVIEW be a leader in the AI space.

I suggest that you create this add on package using CUDA as the underlying GPU calls, in order to keep the code easy to manage, while also providing the package for a large number of supported GPUs.

LabVIEW talking to Gazebo through ROS

Companies around the world are trying to make it easy for robotics, for example NVIDIA is doing everything that they could get into simulation and and NI should have been in the front to support, just like NI had the tools for mobile interface in 80's, and never released to the public, if it would have happened then Android would not have born, just like that robotics once NI loses it to NVIDIA and python and other tools, it would be difficult so I am trying to create a simulation environment just like digit twin for robotics, where labview will simulate in open source for Gazebo, and then based on the simulation will control the actual robot.

Setup LabVIEW talking to Gazebo through ROS, if you are interested to be part of a group where we could get the software updated, please email me at jacobs.mathews@gmail.com

View All (3)

Report Writer BEFORE WIndows 10 was SUPER ROBUST! Now that Windows 10 came along there exist many "turds" left in the Registry when folks UPGRADE from Office 7 to Office 10.

What happens is the Registry NEVER NEEDED to be kept clean of extra junk because NOBODY EVER UPDATED Office.

Now every Joe on the planet updates their Windows 10 with the latest Office 10..

What happens if they do NOT FIRST UNINSTALL, is the Registry is left with "turds"

When Report Writer uses ActiveX to make calls to use Word, in the old days, there was a SINGLE key in the registry to allow the calling program to gracefully start Word or Excel, or whatever.

NOW< with Windows 10 there are FREQUENTLY multiple "keys" in a Registry that causxe the LabVIEW Report Writer to "Gag" and "Hang up" doing nothing.

The SOLUTION is for the Report Writer to PARSE the Registry for valid keys and allow the request to be passed to the propper called process.

If this is not clear, please look up the SR below. There are a TON of examples and videos explaining how to fix it.

I have been working with LV since Dr. G was roaming the halls on LV 3...

This is the FIRST TIME Report Writer has gotten "sick".

This is an EASY FIX for the devs and since Report Writer is a purchased plugin they sould be able to update it so it works well.

Currently, they have us fiddling with the Registry or telling customers to uninstall and reinstall Office. That is a BIG FAT NO-NO to big companies because Office WORKS COMPLETELY for them and even programs like SolidWorks and DXP that use Word and Excel for stuff.

My number 831-455-0418

DEVS:

Please see: Request #: 00994109] Can not get EXE BUilder to run on WIn 10

View All (2)

Idea is quite simple - add to instrument drivers project wizard template for switch/MUX/matrix devices.

Custom switching boards are commonly used, b/c for some simple purposes it is cheaper to make custom design with simple functionality (some micro processor which controls relays), and which could communicate by serial line. Then instrument driver - is ideal solution to create simple API in LabVIEW for its control; but unfortunately, there is no template for such types of devices in New Instrument Driver project wizard.

Hello Guys,

as we are transforming our Testing Application deployed as Executables to something more "state-of-the-art", I found the Remote Panels solution could suite our needs.

Remote Panels are a nice solution, but they rely on LabView RTE and Browser Plugin on the Client Machine. I don't think this is state-of-the-art, since the Web Technologies Wars have are over and Plugins lost the Fight.

I found some similar ideas in the Idea exchange, but none of them hit the point directly. So heres my Proposal:

Replace the reliance on LabView RTE and Browser Plugin with a HTML 5,JavaScript and Websockets solution, that runs on any modern Webbrowser!

This would bring the following Advantages:

- support for any client operating system (even IOS, Android, etc. possible)

- seamless support for Remote Panels in modern browsers (neither Chrome, Firefox, IE will support NPAPI in the future)

- take advantage of all the PROS of modern web technology (e.g. responsive UI to support Touch UI targets)

- since no Plugin is needed, Clients will have no Security concerns (remember Adobe Flash concerns at Apple)

- no need for any NI customer to build an own HTML5 remote panel solution to bridge this obvious gap of Labview Functionality.

I know there are solutions for Windows Remote Control like VNC, but this does not offer a target UI adjustment for the application. So for example a Ipad Target will not change its UI to be Touch-friendly for the User.

I hope you support the Idea! Best regards and thanks for the Attention, Philipp

Multi-Board FPGA Generator

To generate a VI or set of VIs with a general driver to get low-end FPGA boards to work with LabView FPGA. Parameters will only come from the users to make this dynamic, this would be the total count of I/Os FPGA type, location of I/O items (eg. buttons) in the FPGA board, etc. It would be a bit of work, but also would pay off at the end. Doing such is no more than an extension of LabView if done well, let's say written in an xml file plus it would be a very powerful tool for researchers, and would generate more sales to use LabView FPGA for more researchers, university students, and engineers who want to test a few things without full initial commitment to NI tools.

View All (9)

View All (2)

Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.

Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.

Hope to see these features in future versions.

Develop anTool Pallete Wizard

Make a tool pallete wizard that would make it easy to install custom software into the tool pallete. It should allow for the user to make the sub directories, Icons and everything that is need so it could be published without have all kinds of headaches. Making tool pallete menus has to be one of the worst things I have to do. This year with the FIRST libraries being added to the tool pallete a lot of them have no icons because of how hard this is. PLEASE make this easier to do!!!!

View All (2)

LabVIEW Idea Exchange

Extend Password-Protection of a VI to the Front Panel

Show Block Diagram image in Context Help in addition to the existing connectors

provide better platform for instrument drivers and other 3rd party vi's (history, diffs, branch,etc)

Different column withs for table in (standard) report

'Lock Library' via scripting

Expand config.lvlib: get path of config file from config reference

Standardising the color constants in Labview and Excel

Let's Encrypt support for NI web server

New Certification Suggestion - The CLG

Make CUDA integration a first-class add-on

PowerAutomate connector and Drop-In connector VIs

LabVIEW talking to Gazebo through ROS

Report Writer for Windows 10 with LabVIEW 2020 does not work with bad Registry keys that are VERY common

add adobe reader as option for installer build

Instrument drivers: add template for switch/MUX device

Remote Panel without Plugins / HTML 5 / JS / Websockets support

Multi-Board FPGA Generator

Unit Test Framework get Test Case Comment in Report or programmatically access to it

New additions in instr.lib folder to be defaulted to read-only

Develop anTool Pallete Wizard