LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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.

View All (4)

This application is used to track the Position of the person in the mall as the GPS will not work nicely in Indoor Area it can be help with Inertial Navigation System since all the current mobile phones comes with accelerometer and Gyroscope which are the basic parameters for the INS to be added with the last GPS fix will give more or less accurate position and with the essence this can also be integrated with RTLS tags and Cell Locate Algorithm and A-GPS inbuilt

Iam looking for Labview support on this so as the application can be completed quickly

Regards

Satish

View All (3)

Recently I've talked to companies that are already using LabVIEW and their organization has standardized on tools such as JIRA for bug tracking/project tracking as part of an organization-wide initiative. JIRA connects to other IDEs/programming tools such as VisualStudio, Eclipse, IntelliJ, etc. Atlassian (the company that makes JIRA) also provides tools that can part of a larger Agile process and can facilitate code reviews and other software development processes.

The idea up for vote is to offer more comprehensive LabVIEW interoperability with industry standard tools such as JIRA, or other software as part of an internal software design process. (feel free to specify a certain tool, if you have a preference)

Currently in LabVIEW you can have a top-level palette (Programming, Measurement I/O, etc) automatically populate based on .mnu files existing in the folder structure at <LabVIEW>\menus\Categories\. However you cannot do this with the sub-palettes such as Arrays, File I/O etc.

I propose to allow auto-populating palettes for all LabVIEW palettes so developers can place their own palette within the appropriate LabVIEW palette for their functions. One example is OpenG and MGI each have a palette of Array functions. They are currently placed in a top-level OpenG\Array or MGI\Array location. If we could sync these folders, we could place each of the array palettes under the Programming\Array palettes:

Simply by dropping their corresponding mnu files here:

Thoughts? Discussion on LAVA that spawned this idea is here.

View All (7)

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.

VI/Control Icon is File Browser Icon

I will go straight and may litter bit offend the guys working on developing labview in NI, that since labview 2010, there is less and less suppresses brought to the labview coding folks. But also since labview 2010, I've been 'pleased' most is that ni recognized that 'user driven' is one of the most eye attractting futures labview can provide to the developers. Why not you guys go further, release the labview sdk and turn product labview to platform labview. Then fans and geeks can improve labview developing experience along with the employees at ni directly and efficiently.

Here is my reasons:

FOR US:

1. A powerful and convenient developing environment benefits both labview developers and NI.

FOR PEOPLE:

2. Not only normal engineers, but also professional software engineers choose labview as their developing tool. Trust me, current labview will drive them crazy, like me(three years "torching"). You can never control the threads or memory under the graphic programming concepts, though sometime it mattered.

3. There are so many ideas users want and sometime maybe they can realize it by themselves easily under the access to the labview sdk. Then new fractures can be shared, sold or contributed.

FOR THE ECOSYSTEM

4. We deserve an ecosystem for labview. Roles are like: labview market, developers, users, ni, etc.

敬请拍砖, in English means welcome criticizing~~~

LVClass By Reference Features

Property nodes for LVClasses are a tease, this is what I really want:

Invoke nodes that correctly wire call dynamic dispatch by value VIs (this includes the ugly wireing of the "preserve runtime class" inside the in place element structure. Its ugly, just obfuscate it for me.

References to Data value references that correctly respond can use the "to more generic" and "to more specific" class so that I have the DVR to the more specific.generic class REFERENCE.

Justification for Invoke nodes:

I work with lots of different Classes, and libraries. I can quick drop alot, but I do not know all the publicly exposed functions in a give class especially since 90% of the time it is still in development. Generally a pallete won't see the light of day in internal development (somewhat of a pain to make/maintain, definately not a single click operation), so getting the correct methods involves paging back and forth between the project explorer, this is slow. I want to code quickly, if I can have the Public api exposed by an invoke node it means I dont' ever have to make a pallete of VIs (we can argue over this all you want, it just isn't simple/fast enough) and I can access the functions much more easily/quickly. Even if every class had a pallete, it would still be inferior to the invoke node solution because A.) I have to remember where every pallete is. B.) Sharing/installing pallete changes for other developers is PAINFUL. I want to give them a zip file that they can chuck anywhere. I sure do not want to make a scripting function to update there palletes, so it requires file moving/installation/making sure they actually put the class in the right folder (which someone will always do wrong and invariable cause me to right arrow enter 1000 times when I receive their project.)

View All (6)

Allow multiple event callback VIs

As described here, LabVIEW will call certain event callback VIs when certain things happen such as LabVIEW startup or shutdown, creating a new VI, or calling Edit > Create SubVI. The only problem is that there can only be one Callback VI per LabVIEW installation. My suggestion is to allow more than one callback VI to be called when the events happen. This can be useful if LabVIEW add-ons would like to implement the functionality without interfering with existing callback VIs.

This is similar to my previous idea, but generalized for all the callback VIs.

View All (5)

Add a Package Manager to LabVIEW

One practice which is increasingly debated in the community is the packaging of code for distribution and collaboration, and which tools to use.

I suggest that NI should define and maintain an open standard for distributing packages of LabVIEW artefacts (.vi, .lvclass etc).

And include a frontend to this in LabVIEW. This package manager should handle dependencies between packages and across LabVIEW versions and targets. The typical use cases would be:

The distribution (online or shipped with labview) of:

NI examples
NI drivers
NI toolkits

The distribution of third party species of the above

There should also be an API so that applications can use this mechanism to be modular and extensible.

Cheers,

/MArcus

View All (1)

Idea:

Create a free, stripped down edition of LabVIEW for general purpose programming (GPP). Let's call this hypothetical edition "LabVIEW Lite". By GPP, I mean programming tasks that have nothing to do with data acquisition, test, or measurement- tasks such as creating generic PC, mobile, and web applications. Former text-based programmers would flock en mass to LabVIEW Lite for GPP use cases if a free, stripped down IDE were available. Imagine the recent popularity of the Eclipse IDE and Java, only with LabVIEW Lite and G!

Rationale:

LabVIEW Lite would exponentially promote the paradigm of graphical system design.
Few (if any) structural dataflow languages are available for GPP.
Structured dataflow languages are insanely cool! Inherent parallelism, increased productivity, and hierarchical system design are only a couple of reasons. These are things other GPP programming languages can't offer.
16, 32, 64, ... core consumer devices are coming! LabVIEW is poised to exploit parallelism in a way that is hopelessly messy with text-based languages.
GPP use cases of LabVIEW Lite would spark user ideas for many non-GPP use cases, for which NI would receive full LabVIEW and NI hardware sales.

Implementation:

No measurement/test/data acquisition VIs or tools.
No FPGA tools.
Application (exe, dll) builder for stripped down applications.
The LabVIEW IDE we all know and love.
Primitive types, clusters, structures, loops, file i/o, etc. provided.

I think it's a shame that programmers today aren't using G! What do you think?

View All (4)

HTML Control

I would like a control/indicator which supports HTML formatting for display and documentation. There have been a couple of previous similar requests, here and here, but nothing specific to HTML (although jlocanis has been consistent in his comments on these previous requests asking for HTML formatting).

I would envision a control where you enter HTML and can change the display from the HTML to the rendered text easily, similar to the multiple modes available on current text controls.

Why HTML and not just more formatting options?

Why reinvent the wheel. HTML has been around for decades and works well.
You can mix fonts, localizations, superscript/subscript, symbols, etc. within HTML, allowing much more flexibility when documenting front panels.
HTML is platform agnostic

As has been said in other requests, extending HTML support to captions, labels, etc. would also be nice, but secondary.

View All (3)

Call Library Function Node

Hello everybody!

There is a simple way to trigger linescan camera acquisiton controlled by an encoder, as is shown in LL Trigger Each Line From Encoder.vi example.

However, it is not possible to do it for frame cameras in a similar fashion.

Therefore I suggest that there is a way to configure "IMAQ Configure Trigger3.vi" in order to acquire a frame from a camera every N ticks from the encoder.

[idea thanks to a customer's request]

What do you think?

Have a great day!

Zenon

It would be nice if you can define a webpage or email address for bug reporting in a VI or library, that you could set under File->VI Properties before you distribute a library/device driver, etc.

If this address is set, labview could automatically add a menu entry "Report Bug/Feature Request" in the Help menu that takes you to a webbrowser or a email client with some preforumlated text, e.g. subject: "[Labview Bug Report] <VI name> <VI version>".

This way one wouldn't have to start browsing the web frist to figure out where to report problems.

It would also be nice, if one could set this once for a complete project and all VI would inherit this from the project they belong to.

regards

Arun

View All (3)

Add Vi Property: license

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

I have an application that tests three products at a time. When a product is put on test, the user enters the serial number of the product, which pulls up the Excel datasheet for that product serial number.

The datasheet always comes up in the last saved location within the Excel window. I would like to control if this file appeared on the left side (where it currently is), center position, or right positon. Please see the attached screen shot.

It would be nice to force the datasheet to open in a certain location in the window.

There are many VIs located beneath the "<LabVIEW>\resource" folder that need to be called as subVIs of LabVIEW add-ons (e.g. project providers need to call provider API VIs located there). However, because the resource folder is not a Symbolic Path this introduces many challenges for LabVIEW add-on developers. LabVIEW add-ons that link to VIs beneath the resource folder cannot be moved to a new location (for example as part of a source distribution build step), otherwise they will not be able to find these resource subVIs (since they link via a relative path between the caller and subVI, rather than a relative path between the resource folder and the subVI). Note that NI doesn't really feel this "pain" since most of the add-ons NI develops are developed "in place" beneath LabVIEW and ship with LabVIEW -- they don't get "built" and they don't get "installed". However, for 3rd party add-on developers, it's critical that the resource folder be a symbolic path.

Note: This would make building packages of project provider plug-ins possible with VIPM.

LabVIEW Idea Exchange

Custom table column widths in Standard Reports

Traits - A better(?) alternative to Interfaces, Mixins, etc.

Designing Android Application with Labview to have GPS with INS compatibility to Map the Exact Location in Indoor Malls

LabVIEW Interoperability with Industry Software for Managing Issues, Projects, and Code Reviews

Allow sub-palettes to automatically populate with mnus placed in LabVIEW menus folder

Extend Password-Protection of a VI to the Front Panel

VI/Control Icon is File Browser Icon

NEW SLOGAN: opened labview platform brings you to the world of graphic programming.===>by RELEASE the LabVIEW SDK~~~

LVClass By Reference Features

Allow multiple event callback VIs

Add a Package Manager to LabVIEW

Where's the top level idea exchange for Measurement Studio?

Free, General Programming LabVIEW Edition

HTML Control

Call Library Function Node

Encoder triggering for frame cameras

easier bug reporting for (downloaded) VI's

Add Vi Property: license

Controlling sub window position in Excel

Make the LabVIEW "resource" folder a symbolic path