LabVIEW Idea Exchange

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

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.)

 

 

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.   

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

 

 

Apologies for being heretical to LabVIEW.

 

Even the text-based coding world has room to leverage a good driver-hardware ecology.

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?

 


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?

 

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

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

I suggest that LabVIEW Call Library Function Node added automatically identify input and output port functions. And automatically named. This function can save the queryinput and output ports of the time, speed up the development process. Or the same as this Express function:

No "parameters" page.


That's my want!

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

 

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.

Allow user to preselect which libraries to load when inserting ActiveX Objects or .Net Control and same for constants.

Bring frequently used on the top or make it user favorites...

Assemblies.PNG

Add to Automation Open function option "Instance by Name" and "Instance by ID". Provide link between process and Automation refnum.

Automation.PNG

Workaround example.

Not so much a new idea as a request to maintain current functionality. LV2010 does not support importing of LabWindows/CVI function panel drivers, can we have it back ASAP please!

 

For more info see:

http://lumen.ni.com/nicif/us/gb_infolvinstdriver/content.xhtml

http://zone.ni.com/devzone/cda/tut/p/id/3164

 

 

Kevin Snelling

(CVI Certified, CLAD, Alliance Member)

There are methods available to covert from .sif files commonly used with InField to .tdm or .tdms but not the other way around.  It has been suggested by customers to provide a method for this conversion.  

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. 

 

 

To be able to use 3rd party version control tools such as Git effectively, you need to be able to have a program that merges files and can compare files. Unfortunately LVdiff and LVmerge are only available in the professional labview version, but being able to use a VC system of your choice is such a basic need that it should be available for everyone. That way  you would be able to use the basic VC features, better integration with labview could still be integrated in the professional package.

I often need to interpret JSON formated Strings.

Until now I use regular expressions.

 

A JSON-Parser (like the LabVIEW-XML-Parser) should simplify the expense for me drastically.

Hello, community


Since some years I'm using LabVIEW now (currently 2010). I'm working in the automation business branch and I see, that there are many HMI visualization softwares around. Nearly all of then support the inclusion of ActiveX plugins into the HMI surface. We are using LabVIEW, among other software, to control our machines. The HMI software we have to use is normally decided by our customers, so not always the same HMI software. Mostly we use Wonderware-InTouch or Siemens-WinCC. Using LabVIEW as HMI host system is not an option, as customers want to stick to their favorite tools and want to be able to manipulate the HMI by themselves. We would like to replace certain parts of our HMI by LabVIEW-VIs.


This can currently be done by

  • Compiling the VIs we want to display as standalone programs with HTML server included.
  • Installing a runtime LV on the HMI-PC (Windows based)
  • Running the VIs
  • Including a WindowsExplorer.ocx into the HMI project and displaying the VIs via Web connection.

This is very sub-optimal because it includes many superfluous things and induces a more than necessary amount of problem-sources.

What I would like to be able to directly build an .ocx file out of our VIs and so include our VIs directly as AvtiveX objects into the HMI (instead of Windows Explorer as wrap around).

What do you thing about an application builder able to produce ".ocx" output?

Regards,
Ralf