LabVIEW Idea Exchange

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

I have been recently asked by NI to answer a poll about what feature I would like to see as far as data management and access and at that time, I didn't really think about mentioning something which is dearly missing in LabVIEW: cloud storage access.

The reason for this request is that increasingly, files used by collaborations cannot always be copied locally (for instance due to their size or because of frequent updates), or managing local copies and updating the central cloud repository is getting prohibitively time consuming and cumbersome.

 

There exist a few attempts in this direction (e.g. GDrive for LabVIEW, a third party skeleton of a toolkit to access Google Drive, or LabVIEW Interface for Amazon S3), but there are some glaring absent ones such as Dropbox, OneDrive, Box or iCloud to name the most popular ones.

As I mentioned before, GDrive is a starting point but is missing some basic features such as folder list, comments, etc.

I cannot comment on Amazon S3, as I don't use it.

Obviously, there is no way to predict which cloud storage solution will disappear in a few years from now or which one will pop-up tomorrow and become popular, but most of the work has been done by those vendors, who provide .NET API for their cloud solutions (maybe not Apple) or at the very least a RESTful API. These APIs could of course be made community projects (like GDrive is to some extent), but their importance would seem to justify a minimal investment from NI.

 

 

I'm surprised a search did not turn up anything about this.  NI should create a LabVIEW Amazon Web Services/Azure/Docker Image(s).  The sample case I am thinking of is having a Jenkins CI server running on AWS EC2 with a full LabVIEW environment installed.  This would allow off-loading the long FPGA or full RF suite builds during CI.

 

Apparently NI had this with LabVIEW 2012 on AWS

 

I would suggest to NI the following steps:

  1. Collect underpants
  2. create AWS LabVIEW image for cloud-based compiling - charge per use
  3. Use AWS to work out the kinks to get an efficient, speedy image created
  4. Open an NI data-center that does what AWS/Azure does but for the tech/engineering field and host all of their own software images
  5. Profit (or at least start to pay back that huge CapEx outlay)

Thanks!

Charlie

 

 

 

 

 

The creation method for Polymorphic VIs is too cumbersome. It is a lot of work to go through each field and manually enter the information; especially if there are lots of data to create. It would be much more time-saving to be able to enter it all in a spreadsheet, and have the creator read from this spreadsheet. People would be much less intimidated to use the creator. 

Yes, I want to inspect a vi's Block diagram on my Smart phone.  (Since I have no life and constantly troll the forums looking for people to help.)

Since I'm working with LV-DLLs there is a very very annoying Bug. I just made my first tries in LV 2012 (up to now I'm using LV 2009) and I recognized that the bug is still there but an information/warning dialog opens now when it takes effect. With other words: The bug became a feature ;-( So it's time to make a suggestion for changing in the LV behaviour.

 

Here are the steps you have to take to reproduce the problem:

1) create a new, empty LV project

 

2) first create a cluster, store it as type def and add the type def to the project

typedef.jpg 

 

3) create a new VI (called test) that uses this cluster as output (input will work, too). Add the VI to the project, too.

 2.jpg

 

4. Create a DLL-Spec with this VI as exported function (sorry, I’m using a German LV):

 3.jpg

 

5. Usually the default prototype is not the best. So we re-configure it like this.

4.jpg

Click to ok and store the project and all files.

 

 

6. Ok, last step: Building the DLL 🙂
 – Ups, we forgot to change the element “n” inside of the typedef-cluster to U16 (it’s still set to double).
But no problem – changing the typedef will correct the bug everywhere where the ctl is used.
Open the typedef, change and store it. Now re-build the bug-free DLL - finished! .. or not? No, you're not. Because you changed the type def LabView has reset the hard configured prototype to default *grmpfl* Smiley Mad

 

Now you might say: “Hey, where is the problem, just re-configure it.”

Currently I have a single project which uses up to 25 DLLs created in LV. All are using the same data cluster typedef. Each DLL has approximately 10 exported VIs. This makes 250 prototypes I have to re-configure if there is just one little change within my cluster!!!

LV resets the prototype even if a VI-IO changes from “required” to “recommended” – a change that does not have any effect to the behaviour of the exported VI.

 

So NI, please change this “feature” to a real feature as soon as possible!

 

Meanwhile I have to go on using variant elements to send data to my DLLs and back.

 

 

Appended you'll find a very similar example. Don't forget to save the VI after you've changed the type def.

 

I miss the ability to use the results shown in "Search Results" in scripting code. Programatically selecting some results is desirable.

 

This would allow to do some custom filtering, searching in results, do advanced replacement, ... with some custom tools.

 

Greetings,

shb

My mouse (Logitech) has a scroll wheel that also has the Left & Right scroll ability.  Labview does not natively support.  why?

The Matlab data plug-in supports version 7.0 files.

https://www.ni.com/en/support/downloads/dataplugins/download.ni-dataplugin-for-matlab--mat-files.html

 

The newest files are 7.3:

https://www.mathworks.com/help/matlab/import_export/mat-file-versions.html

 

Projects are beginning to require this newer format.

 

It would help to have an option to ignore Bad VIs errors when calling a mass compile via LabVIEWCLI. This makes the CLI MassCompile unusable for deploying code with NI Package Manager that has API Tree VI. It would help to have an option to ignore those errors so that NI Package custom execute could run successfully. I would think it could be defined as optional argument. My suggestion for the argument is -IgnoreBadVIs true|false with a default of false.

Incorporate NI Batch Installer Builder into the general application builder suite.

 

This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite.  Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do).  It could be used for creating installers of multiple, cross-project user installers comprising a complete system.  To do this though, the current batch installer builder needs to be made more generic to be of use.

 

Specifically:

 

  • Add configuration options to control or disable license dialogs when non-NI provided installers are added
  • Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
  • Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
  • Add batch installer version properties to allow end users to create system versions
  • Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)

Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.

I would like to see an option to drop while loops in the code with different colors. Now it takes a couple of steps to change the color but it could be easily done in automated way.

 

It would make discribing the code and adding comments easier and faster. Especially for smaller designs.

 

Default Colors.png

Hi!

 

Especially in multi monitor setups NView provides some very convenient functions. LabVIEW and NView, however, don't play well together. That is: I have to disable NView to use LabVIEW properly. That's very annoying, as you can imagine.

 

So my suggestion is: fix it Smiley Tongue

 

I suspect, that LabVIEWs scrambling of the alt+tab order is part of the problem. So I'd like to see that fixed too. I mean, you already have a shortcut to switch between Frontpanel and Blockdiagram (Ctrl+E). Why additionally scramble the alt+tab order to get FP and BD side by side?

 

Best regards,

pktl2k

 

P.S.: I'm sure, users of not-NVidia graphics have similar trouble with their respective NView counterparts.

Creation of a VBScript Node, similar to the MathScript Node, allowing to run a VBScript.

Just like LabVIEW 2009 introduced Custom User Hooks for Data Member Access and Override VI LVOOP templates....

 

I would like Custom User Hooks for Dynamic Dispatch and Static Dispatch LVOOP templates as well.

Message Edited by jg-code on 11-26-2009 02:26 AM

Would like to target Labview embedded on a host of platforms. Specifically x86, lynuxworks, Vxworks and xilinx platforms - boards, SBCs, COMs, stacks, PC/104... Like PXI, the way to get the users onboard is to show that the industry supports this direction and you are not tied to one vendor. It would be expensive if in an iterative learning process (necessary but collaboration is also necessary with well established & matured platforms/standards) the users one chosen platform vanishes (maybe like fieldpoint?). Packaging options is also very important to achieve something like Adlink's MilSystem 800 that the application demands.

 

Pavan Bathla

I am making ever more webservices with labview, but I feel I have little control over the server. It can happpen that a webservice becomes unreachable. Sometimes I would be a crashed webservice application, sometimes it is the NI webserver. But no tools available to find out. I can imagine the following tools in the NI webserver API

- start/stop server

- disable/enable server

- enumerate active webservices

- start/stop or enable/disbale webservices

- redirect domain root endpoint to webservice

- set favicon

- some proxy options would be nice to redirect a domain to a specific webservice

Motivation: in my recent project I have got a request from the end user that it would be nice to store configuration data in the same TDMS file where we store measurement results. Of course, we can create this feature programmatically, like we parse through the typdef cluster, using label names and different data types, we can create a kind of API for a TDMS Cluster read/write. However, it is difficult to make it generic, and this is an extra work anyway.

So it would be nice to save my complex Typdef cluster into TDMS, where I store measurement results in a user readable manner (via the Excel plugin) inside different groups and channels. The stored configuration cluster does NOT need to be user readable!

Since TDMS does not have this feature, as a dirty and simple workaround, I will always produce two files during measurement/data processing sequences: a TDMS, and an INI file (via the OpenG Write INI Cluster), then programmatically ZIP them into a single file for data backup (for future reference, it is safer this way).

 

Would not be nice if we could just write a Typdef cluster to and read from a TDMS file directly?

Like what we can do with the OpenG Read/Write INI Cluster VIs. I understand there is a strong reason why TDMS files limit the data types we can write to them, and it is not allowed to use undefined data sizes, like Variants, strings. Well, we can write strings to TDMS files, but there are some issues/difficulties with this approach if we want to go through a Typedef Cluster->String->TDMS file storing route. Hoovahh had a post about these challenges 2 years ago, where he mentioned he might make it into an Idea, but I could not find it in this forum board, so I make it an Idea: https://forums.ni.com/t5/LabVIEW/Read-Write-Variant-to-TDMS/m-p/3334203 

 

I imagine, NI could implement such feature into TDMS in a similar way, like there would be an "internal part" of the TDMS file where the Cluster is stored as a Variant in binary format. I do not know how the internal things work in a TDMS file, but I imagine such new feature implemented as an extra data type for the TDMS Set Properties would not hurt the speed performance of the Group/Channel level things...?

This was issue number 7737579.

I wanted to be able to export and fill in the fields of a PDF Form.

There is already the ability to work with Word, Excel, and various other data bases, but a PDF Form is not supported.

I know there are other ways to skin this cat, but in my case, we have many PDF Forms already made that are test reports.

To have Labview run the test and insert values into the named fields of an existing PDF Form seemed like a no-brainer to me.

 

Anyway, that is my suggestion for you guys to chew on.

Thank you,

Michael

This is in addition to New LabVIEW Installation Retains Options

 

During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:

  • vi.lib (VI Package Manager installs packages to this location by default)
  • instr.lib
  • user.lib

Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.

 

This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.

I have several LabVIEW applications that I work on, and each of them has a Perforce workspace associated. Every time I switch to a project that is in a new workspace, I have to dig through the SCC configuration menu to switch workspaces, which takes a while.

 

It would be really sweet if LabVIEW recognized that a project file was in source control, and associated the workspace with the project file. (Especially because I could have two application projects open, each in its own workspace.)