FPGA code allows I/O references to be used so that code can be re-used/abstracted, like this
This could/should be extended to cRIO C-modules so that code can be re-used on multiple modules. This would require the 'cRIO Device' property node to return an array of I/O Refnums that could then be passed to subVIs or other modular code.
For example, if I have code for an analogue input module (say, NI 9205) which filters and processes the data, and I wish to re-use that code in multiple experiments I have to manually change the module name in each IO constant or node (Mod1/AI0 to Mod3/AI0) if the module moves or I need more than one of the same type.
Conversely, if the cRIO Device property could provide the I/O references, the code could accept a cRIO Device constant and the reusable code extract the I/O references. The code would then adapt from Mod1/AI0 to Mod3/AI0 as the cRIO device was changed from Mod1 to Mod3.
It would be added to these properties.
When searching for text in LV 2014 (from 2015 DS1), it appears that the Window Title text isn't picked up by the search.
To verify this, I created a new VI, and modified only the Window Title (File -> VI Properties -> Window Appearance -> Window Title, Click OK, Save VI). Then press Ctrl + F, Select Text, type in a word in the Window Title. Not found .
We should be able to search on any text saved anywhere in the VI (in cluding VI properties like Window Title). Please expand the find capability to search Window Title and any other relevant fields.
I really could do with the Ethernet/IP toolkit to act as a scanner rather than just an adaptor. As an adaptor you can write code that will allow a PLC to scan and request data from you, which is fine if you only want a PLC to request data, but I have the requirement to have my Labview app act as the scanner and request data from several different adaptors.
User Colors 1-16 are now pre-defined by the default LabVIEW.ini file that leaves us developers with only two. Why 18 total? This needs some adjustments IMHO! It should be easy to implement but, can't be done without hacking the ini editor
Include a python script node that you can create and run python code, functioning exactly as the c script node does but using the python language, there is a growing support for python in the scientific community (I know of a good few university lecturers and professors who use python), and it is a great programming language for beginner programmers such as university students.
This could be included as a feature in labview itself or be a labview addon.
TensorFlow is an open source machine learning tool originally developed by Google research teams.
Quoting from their API page:
TensorFlow has APIs available in several languages both for constructing and executing a TensorFlow graph. The Python API is at present the most complete and the easiest to use, but the C++ API may offer some performance advantages in graph execution, and supports deployment to small devices such as Android.
Idea Summary: I would love to see LabVIEW among the "perhaps others".
(Disclaimer: I know very little in that particular field of research)
I created an application that talks to a SOAP webservice. Unfortunately the NI HTTP does not support https behind a proxy (using the connect method). See this thread. It is unfortunate, since the curl library underneath is much more powerful. I have to overhaul my code to implement another solution.
Encrypting http transactions with configSSL.vi is cumbersome as well. The documentation on this VI could be much better.
I just finished installing LV15 (and device drivers) on a new PC and I think the installer window could use an upgrade.
When expanding the different features you can install beyond 2-3 levels, they disappear out of the narrow tree-area.
It would be awesome if I could then just resize the entire installer and it would grow the tree (and description) so I didn't have to use the little horizontal scrollbar
Starting in LabVIEW 2015 we got a neat new function that can create a unique file path, and allows to not overwrite a file that might exist with a similar name.
This is such a cool function and I could think of a ton of places where I needed to save some temporary data and just wanted a unique name expecteing files to be cleaned up later. Or give the user a checkbox which wouldn't overwrite the existing data, and then not need to worry about generating my own unique name.
Alas this function fell short of my expectations. Why? Because it creates the stupid file, and returns a reference to it, instead of just generating a path that I can use. What if I want to use this with the report generation toolkit and generate a unique file name? Well you can but you need to close the file reference it made, and possibly delete the file. Same with if you want to use this on a TDMS file, or a Configuration INI file, or a zip, etc.
I suggest either adding another function (polymorphic?), or making an optional input to this function, which does everything it currently does except don't run the Open/Create/Replace function there by making the file, and returning a file reference. Every time I've used this function to date it has been followed up with a Close File, then a Delete function.
There has been always the need of opening the file/folder location in windows explorer, but I guess every application uses the trick of doing it through "System Exec.vi" or "Open URL" or Win32 API. There is no LabVIEW native function to directly open folder/files in windows explorer directly.
Below threads discusses various methods to achieve this...
It would be nice if LabVIEW comes with some native function like below
What if you need to run exe as admin mode?
Currently Build Specifications is not enought for doing it.
Here you are what you need to do:
1. Built the executable
2. Install mt.exe (https://www.microsoft.com/en-us/download/confirmat
3. Opened cmd as adminstrator and ran mt.exe -inputresource:"Application directory\application.exe" -out:application.manifest
4. Opened application.manifest and changed input="asInvoker" to "requireAdministrator".
5. Saved application.manifest
6. ran mt.exe -manifest:application.manifest -outputresource:"Application directory\application.exe";#1
Is it an effective method?
It would be better the following:
1. Create Manifest
2. Easy modification in My Application Properties
Hope it helps to do a more effective LabVIEW!
Currently enums can not be in a cluster that you want convert to JSON. It would be great, if this could be added.
Either the enum value could be converted to its internal representation (e.g. u16) or the value could be saved as a string (make it easier to read the JSON and parse it outside LabVIEW).
The unflatten should be able to handle the u16 easily to convert back to enum or take the string and search through the enum of the datatype that one has to connect to the vi. If there is no match the VI can issue an error.
Working in LV2011 right now, so it might have been changed, but here goes:
A wire gets information from the control or outgoing indicator of a sub-vi it's connected to. Looking at the wire, the Help windows shows this information e.g. "DataValues". When activating Label on the wire, wouldn't it be great if it had this info as a default label?
Wires should have the Data type of wire as default label.
Short and sweet suggestion. Kind of like me.
It would be nice to add an optional "open new instance" boolean input to the New Report.vi of the Report Generation Toolkit (effective for Excel and Word report). Currently this input is left unwired in the"new report subVI.vi and thus use the default false value.
This easy modification would help avoid error -41112.
I would like an autoscale option on XY graphs that would autoscale both axes under the restriction that the resulting grids be square. That is, there are three parameters, not four - X offset, Y offset, and pixels-per-unit-for-both-X-and-Y.
So, if I graph, say, a bunch of points along (x/5)^2+Y^2 = 1...
Presently, if I graph that, it will look like a circle.
It would be nice if the resulting ellipse would look 5 times wider than it is tall.