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.
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.
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
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
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)
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!
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
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.
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.
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.
I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.
There are so many good nuggets of Array manipulation code in OpenG. This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays. Lets start with the Index Array, one of the most commonly used functions.
Here we see the native function allows for an N dimensional array to be indexed. The OpenG function only supports 1D and 2D arrays. And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row. Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices. You can pass in an array of indices and pull them all out in the order defined. This can be used as a reorder function that takes an array and scrambles it the way you like. Adding this feature is already on the idea exchange.
Again when it comes to polymorphism the native function beats OpenG. The native delete supports deleting from N dimensions where OpenG is just 1D or 2D. But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns. This would be a nice addition to the native function.
A conditional auto index function doesn't exist natively in LabVIEW. You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful. This idea is on the exchange in multiple places, Link 1, Link 2.
Ever need to remove duplicates from an array? Or remove all zeros or NaNs from an array? These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette. A nice feature of the remove and filter are they output the indices that were removed. Combined with the fact that the delete, and index accept multiple indices make these very useful. Also the items to filter for the filter can be a scalar or array which is nice.
Ever want to sort an array and know how it was sorted? This OpenG function can do that along with specifying what order, ascending or descending to use. The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.
(This is different and less controversional than this related old idea)
Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.
As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.
If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).
Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.
IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.
The documentation states that the Tip Strip is limited to 255 characters, however the Documentation tab of a control Properties page does no checking against that limit. One will only find out if there are more than 255 characters during execution, when the tip strip is truncated!
Please enforce the character limit of the Tip Strip input box, at design time. Also, while at it, make that box taller.
I sometimes use arrays of classic frameless colorboxes to quickly display a color table.
Unfortunately, the minimum size of these elements is 5 pixels , making a 256 element color ramp 1280+pixels wide, showing redundant information in 5 adacent pixel columns each. If we display the color ramp vertically, it would not even fully fit on a common 1080p display!
This makes it too wide to correctly display them in the forum and forces a size reduction that makes all other text and diagram code illegible.
(Yes, we can right-click...open image in new tab, and click the image to display it 1:1 (in chrome), but that's more work and not everybody knows that)
It would be perfectly OK if we could make these elements only 2 pixels wide (or high), making the array display a much more reasonable 512 pixels and keeping the front panel to a more reasonable size.
The minimum size of the classic colorbox (frameless) should be 2x2 pixels (or even 1x1?) Currently it is 5x5, i.e. too big.
Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!
In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.
Here is a simplified example to illustrate the problem (see picture).
In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.
However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course ). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!
What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.
The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.
Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.
(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)
Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.
If You drag a tunnel of a loop, case structure or any other structure along the border over a corner, then
the connected wire becomes hidden behind the frame.
Sometimes, the wire looks alike it is connected to another wire instead - like in the example below.
I fell into that trap, because I've just seen the frame to the right and didn't expect, that the wire was
connected to the tunnel near the bottom.
Wouldn't it be great to break up the wire with a 90° corner and place it in the visible area?
More similar situations like this are posted in this thread:
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.