LabVIEW Idea Exchange

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

LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.

 

If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).

 

However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).

 

Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.

(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)

Now that NXG is going to be discontinued, I guess the NI employees who were working on it will be re-deployed.

There question is to do what??

 

A part of the LabVIEW community thinks the failure of NXG was partly due to the fact that the team working on it didn't have enough love for LabVIEW-CG and/or not enough experience using LabVIEW-CG in real world applications.

 

So my suggestion to help them understand better what makes LabVIEW great and what could make it even better is to encourage/force them to spend a fix percentage of their work-time contributing to LabVIEW related open source projects.

 

What better way to enrich the LabVIEW eco-system and make them feel for LabVIEW at the same time?

A native Icon Editor API seems a natural evolution for interacting with the new icon layers that appeared in LabVIEW 2009.

The current API is the only way (I know of) to interact programmatically with the Icon Layers.

This is a very handy API that should be polished up and included with LabVIEW. 

 

You can download the current version here:http://decibel.ni.com/content/docs/DOC-8647 

 

Direct to PDF reporting is an extremely important feature to provide customers.  It cannot be relied upon that the customer has MS Word or the like installed.

There are a couple of LV PDF toolkits supplied by developers.  However, the problems with these include that they are (a) not updated or well-supported (b) buggy (c) have out-dated dependencies such as .Net 2.0 (d) restrictive licencing for deployment.

Good reporting tools are essential and NI should develop and support a direct to PDF toolkit.

if only LabVIEW can read and write PDF files, since it is already an open format. needless to say for the function of writing in report generation, but reading from PDF can also provide: text, picture or even CAD data that can then be used from automated mass data entry, QC vision inspection (CAD vs fabricated), augmented reality visualization of measurements (temperature, stress, vibration, etc) and much more...

 

if only...

Many built-in functions have the growable ability. Essentially a function that accepts an array of data in scalar form, this saves the step of building an array prior to wiring a terminal.  I would like to select any  1-D array on a connector pane and mark as growable.  Then when the vi is used as a subvi, the icon would have the growable ability.  This could have been used as for example for making a growable error handler or implementing new compound math functions.  I know this is probably hard to do and might be possible with xnodes but I dont have time to learn this.  It is useful for making reuasble toolkits which look more like the native G functions

As software versioning becomes more and more popular also the automatic building of source code becomes more and more interesting.

 

Right now in our company we are using GIT and JENKINS for C-code material as our versioning and automatic build tool. As soon there is something being checked in and pushed to the main repository the builder gets notified and tries to build your source code having the output available somewhere.

 

As we are having many users around the globe these tools obviously run on a virtual machine or server somewhere.

 

Right now there is no option in buying the application builder seperatley and control it via command line. The only option is to put a complete development environment on there which is useless and a waste of money.

 

My request would be to sell the application builder seperatley for these purposes OR figure out an alternative way for doing this in a professional and neat way.

 

some usefull links:

http://jenkins-ci.org/

http://git-scm.com/

When you hit build, you can't edit code. Build takes a while, sometime hours. 

 

We would like to separate the compile process and free the editor, or target another pc/ip to offload compilation.

 

I would like a right-click option where a folder of packed libraries waiting to be compiled are queued and scheduled e.g 6pm or weekends and Labview is open. 

 

My colleague Bosko G has something on the latter (attached) and came up with the request. I am sure others have thought about something similar but I couldn't find a post addressing it directly. To be clear, the request isn't for a 3rd party cloud farm alone but also something we can setup on intranet PCs/Servers.

 

Thanks. 

 

Pavan 

Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

If NI were to make the following modification to the Word_Save_Document vi, we would be able to generate PDF documents directly out of the Report Generation Toolkit. This may only be applicable to later versions of Word.

 

What is required is to handle the PDF file extension and set the appropriate wdSaveFormat value for the SaveAs Method. It would also be nice to be able control the show PDF after generation option, but just being able to save as PDF would be very useful.

 

 

VI modification

It would be nice that if a VI documentation set is created into HTML with PNG as picture format a snippet option would be included.

This option would embed a VI snippet of the top-level BD inside the PNG instead of a static image.

This way it's possible to distribute the code inisde the documentation.

 

 

 

Perhaps a future LabVIEW version can include NI-defined common interfaces (with ~1 method each).

 

Examples might include "Initialize", or "Dispose" (to borrow from C#). "Shutdown" might be another option.

 

This could allow different developers to all base their code on a set of common shared interfaces, and then users receiving their code (via VIPM, GCentral, etc etc) could use it as a plugin more easily.

If an XControl is placed inside user.lib this XControl is not added to the palette.

 

This means that if you distribute an xcontrol you need to send a mnu file with the xcontrol which adds another folder inside the user.lib palette.

 

I think that an Xcontrol should be indexed like standard controls.

 

My request is very much similar to Rob Hingle's request posted in "Need custom column widths in Append Text Table to Report" thread here:

 

http://forums.ni.com/t5/LabVIEW/Need-custom-column-widths-in-Append-Text-Table-to-Report/td-p/1108404

 

I discovered the above thread while looking for a solution and I got very disappointed that the discussion in that thread did not lead anywhere...

Rob actually said it all; I can only second him here as my problem is basically the same. Nevertheless, I'm putting it out here for reader's convenience.

 

In my practice, I often need to create a LabVIEW standard report (for printing on paper) which would contain, among other things, one or more tables. The tables must have columns of different width. Some columns need to be just a few characters wide, while some other columns have to be quite wide. For example, a table of chemical compounds would contain a Sequential number and a Compound ID, and a few other columns. The first column needs to be three characters wide maximum, while the Compound ID has to be much wider (say, 30 characters wide). There is no way I can use the standard LabVIEW "Append Table To Report.vi", since it sets all the table columns to be of equal width. In the past (LabVIEW 7) I was able to do this by modifying the "Append Table To Report.vi" and its subVIs so that the VI would take an array of column widths instead of a single scalar value. It became quite difficult to achieve since NI reworked the Report Generation Toolkit... I ended up importing and using the old toolkit - now with LabVIEW 2010 and 2011, which is obviously not the best solution.

 

I'm surprised that this issue apparently did not draw more attention so far, since IMHO it's been a glaring deficiency of the Report Generation Toolkit for some time now. Why the Report Generation Toolkit was designed with the assumption that columns in tables can only be of equal width is just beyond my understanding... Generating printed reports with tables is a quite common task, and most of real-world tables have columns of different width - just take a look at a few tables in books, magazines, manuals... A table with columns of equal length is quite a special case of more generic form, and can be easily obtained if needed by specifying the same width for all columns in the table.

 

Please make the "column width" input of the "NI_report.lvclass:Append Table to Report.vi" an array... To provide backwards compatibility, the VI can be made polymorphic (I hope), so that either an array or a scalar could be used.

 

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.

 

 

As a new adopter of the Unit Tetst Framework I was keen to export my UTF Results from the Result dialogue for use in an external test report (Word document).

The Save button creates a datalog file only suitable for Loading back into the same dialogue. There's no immediately obvious way to export your results in a readable format.

 

After scrutiny and assistance I found that you can configure automatic creation of HTML, ATML and ASCII formatted reports by changing your Project settings. Hmm. Not quite what I want.

 

I want to be able to quickly and immediately export my UTF Results to Clipboard or File in my chosen format from the UTF Results dialogue please.

 

UTF_Report_Export.png

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

 

 

 

 

 

It would be great if you could easily add a license (public domain, GPL, BSD or your own) to a vi. This would be great especially for libraries such as device drivers, etc.

 

I think a good place for this could be File->Vi Properties. There could be a license tab where you either can choose from common pre-defined licenses or have a text entry box where you can add your own. If someone else uses the vi, that person can than easily find out if he can use this VI in for example commercial code.

 

Arun

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.