LabVIEW Idea Exchange

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

LabVIEW contains a mechanism for storing custom metadata of any type inside of VI files as "tags" (e.g. the path of an Express Source VI's associated config dialog VI) but the methods for manipulating them are marked as private. I think this could be a useful thing to have as an officially-supported feature.

Usually, unsupported LabVIEW features can be enabled with nothing more than an undocumented INI key. The one exception that I know of is the integrated XNode development feature in the Windows version, which is instead controlled by the license manager. (This feature exists in the Linux and Mac versions as well, but on those versions it's an INI key like everything else.)

 

Despite not being officially supported, community-made XNodes are very much a thing. Even on the Windows version, one can still create them using a third-party editor, or hack their way into the built-in one somehow. And it's clear that NI (rightfully) doesn't put much if any continued effort into preventing third parties from making XNodes, as the same methods that were used over a decade ago still work just as well now.

 

I'm not asking NI to provide official support for XNodes necessarily, but I think it's for the best if they at least remove all unnecessary, artificial roadblocks, and open up the XNode development forum and perhaps some internal documentation to the public, so community-based developers can at least have the best shot at learning how to do it right. You've already done this with Project Providers; why not XNodes as well?

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

When manually analysing a project, we can set the target in which the VIs should be loaded. Unfortunately, VIs with RT code are often broken under windows, leading to wrong test results, or even worse, pop-ups asking for VIs.

 

Please add an Application Reference Input for the VIAn Run.v.

 

Maybe this option could also be useful set in the VI Analyzer configuration file?

Software development has moved on since a similar idea was declined in 2016

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-vers...

I would like to suggest just LVCompare is made available in all versions of LabVIEW.

If LVMerge was also available that would be great, but leaving in just in the Professional version would also work.

As a lone developer I use GIT even on very simple projects to give me the ability to rewind and see what changes I have made. Projects are often put down and picked up weeks later. LVCompare lets me see how far I had got. Its also very useful for picking up debugging that should have been removed. In short Software Version Control just make my life easier.

 

The title says it all.

In 2021 there was excitement about improvements to LVCompare and LVMerge, however there is still no way to compare classes or libraries.

I'm ok with not merging. I know that is a minefield. But at least show me what methods were added, what library or class settings were changed, which VIs moved from private to public and for classes, diff the private data and maybe show changes to the class heirarchy?

When integrating libraries written in C# a common scenario that occurs is the necessity to cast a method to a generic delegate defined in the class in order to, for instance, subscribe callbacks to events belonging to sub-classes inherited by the object instantiated by the Constructor Node.

 

So far LabVIEW efficiently allows to subscribe to events, registering a VI as callback in case the event involved is fired, but does not allow to cast a VI to a generic delegate and that's very limiting.

 

The only workaround existing is to wrap the C# library, adding an additional C# layer that instantiates the delegates on behalf of LabVIEW and then exposes plain methods, properties and events that are straightly callable by LabVIEW itself.

 

The idea is to allow  LabVIEW to instantiate generic delegates based on the definition of the delegate provided by the C# library and return the delegate object so that it can be provided as input to library's methods requesting it.

 

This feature would make the LabVIEW integration of C# dlls more solid and completely manageable within LabVIEW code without further wrappers needed.

Just recently ran into an issue with XML namespaces where the LabVIEW implementation just didn't cut it. The AE had R&D confirm this too. The work around, after trolling through the vast sea of .NET XML features & forums, was there. Something this simple shouldn't burn up this much time.

The world around us uses JSON & XML extensively yet the examples are minuscule. It doesn't matter if new examples are .NET, Python or something else but we need to get to solutions quicker.

 

I wish LabVIEW had Official Container (Docker) Images.

 

With more and more users trying to use the docker in Continuous Integration, it would be 

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

 

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

 

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

 

Anyone else would support this idea or has anything to complement?

I would be helpful if the Python nodes supported Python Virtual Environments. One of the powerful features of Python is able to setup multiple separate environments on a single computer, it would be LabVIEW's Python integration could also leverage this. TestStand already does have this capability, so hopefully it could be quickly/easily leveraged into LabVIEW. 😁

It would be great if one could pull FPGA Bitfiles/changed Xilinx IP without recompiling the code / re-configuring the IP cores.

 

Currently it seems that I need to copy the Xilinx IP via the Filesystem (e.g. network-drives) after pulling a new version from a git repository.

This works since git doesn't detect any change (no commit required), but the modification date is preserved. But it is very annoying.

 

For FPGA bitfiles this trick doesn't work for me, at least not if the path doesn't perfectly match.

The Matlab data plug-in supports version 7.0 files.

https://www.ni.com/example/29178/en/

 

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.

 

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

It would be helpful if the LabVIEW Python node natively supported Python dictionaries as LabVIEW Maps. This would make it simpler/easier to support a frequently use Python structure. You can work around but you have to do extra data preparation/formatting in both LabVIEW & Python. It would be nice if the node handled that converting to list of tuples and building the LabVIEW map or vice versa for us.

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

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

 

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?

If we can have instrument simulator VIs, we can test our codes prior to the actual hardware acquisition

 

The idea proposes device driver packages from IDNet to include a vendor instrument simulator VI that can be run prior to code testing. The VI can be configurable (VISA based on virtual ports created during runtime, file paths to read from to simulate measurements and responses to messages, etc) and started asynchronously (call & forget) at the start of the program and terminates when the caller terminates.

 

or as a template from the "New > Simulated Instrument" where user can modify according to the instrument that they are going to use.

 

...and that it covers NI and 3rd party instruments

In Enthought's python integration toolkit (PITL), the "Open python session" VI accepted as an input the path to the python.exe file to use for the python kernel. In LV2019  the "Open python session" accepts a string "2.7" or "3.6", and then labview searches the system path to find the python installation.  The LV2019 method is vastly inferior to the PITL method. Due to the way the LV python node requires one to manipulate the system path in order to find the desired python installation, I realized that this is a complete non-starter for sending compiled applications to end users, because the end user may have multiple python installations on their computer, and I can’t expect them to bend over backwards just to be able to use my compiled LV app.

 

I do not know how NXG currently handles this, but I hope that they emulate the PITL method. Furthermore, it would be great if NXG could handle arbitrary python distribution, such as Anaconda, rather than just the bare bones installation from python.org. It would also be great if there was more documentation about the python node in general--there is very little to be found currently. The Labview python node is shrouded in mystery (e.g. what the heck is NIPythonInterface.exe) whereas the PITL was very self-explanatory. It is a shame that NI displaced such a useful product and replaced it with an inferior one.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!