Currently, "build path" function has input "base path" set as recommended. This can cause issue when you accidentally do not wire this input. By default there is empty path, which is not really helpful and even if there was any case when you want to wire empty path to build path function, you can easily create constant. Therefore, it would be much more user friendly to have "base path" input of "build path" function set as required by default.
can we have an option of loading only user-specified rows from a delimited spreadsheet instead of all rows, perhaps allowing the user to specify which and how many rows to read? this is potentially useful if the user want to read the select or latest few rows (typically at the last few rows due to write append) without having to load unnecessarily large amount of data into memory.
implementation wise, can use a row index and length input optional terminals defaulted at index:0 and length:-1, to yield all rows by default for the rows (note: terminal name changed) output terminal. index:-1 to specify from end of file and non-zero length:L for how many rows from the end of file (-L for reversed order, last row on top). if index:-1, the data read will be replacing elements within a fixed sized array of L elements until the EOF returns true. for example, index:-1 and lenght:5 would yield last 5 rows from file.
Error ring without file (request for an error-ring typedef that could be stored in the project's source code collection)
My suggestion here is most like the last - I'd like to suggest a file type like a .ctl (or perhaps via typedef, if technically better/more implementable) that can be added to a project, library or class and contains a list of errors.
Ideally, these errors should be only possible to throw from inside the library, but must of course be visible from outside of the library.
Implementing these at the project level restricts the possibility of use with PPLs, reusable libraries, etc, because the project file is a dev-only construct (as far as I understand), unlike classes and libraries (which are part of what you distribute in whatever form you choose).
The ability to store these files in a library or class also allows the possibility of scoping the error code, such that the handler can more easily identify the source of the error.
LabVIEW already categorizes it's errors into broad sections (LabVIEW, MAX, NI Platform Services) etc and so perhaps these could be used as the scope of the existing, built-in error codes, although I'm not sure if this would require significant work or not... I suspect many things seem easier when you're not the person who will implement the changes!
So this isn't a huge deal, but it would be nice if we could put an array of classes into To More Specific Class to convert all of them to the more specific class. There are handfuls of functions that work well on both arrays and single elements (the Math functions, Close Reference, etc).
Error Out would need to become an array as well. I can't think of anything at the moment that this might break, or any poor patterns it might enable, it would just save a For loop here and there. I made a quick example vim just to illustrate, but it'd be nice if it was part of LabVIEW core.
Traditionally LabVIEW has treated Strings and Unsigned Byte Arrays as being the same. This is nowadays a little unfortunate as all UI systems use some kind of encoding so Strings are not generally interchangeable with Byte Arrays anymore.
In trying to stay for binary data as much as possible with Byte Arrays instead of Strings, since that would be the sensible thing to do, the Unflatten from String (which should rather be called Unflatten from Stream) puts a totally unnecessary wrench into this.
I always had hoped that LabVIEW would change the default binary data stream format to a Byte Array at some point but this while it would be possible, is a fairly pervasive change that would require many backwards compatibility decisions that I unfortunately don't see NI going to spend time on anymore. This change however would be a very small change that has zero backwards compatibility concerns and almost no work to add to the existing LabVIEW software.
This same change has been for instance made to the TCP Write node some versions back already and could be also applied to the VISA Write!
When searching for text in a vi or group of vi's, the search isn't able to look inside an FPGA IO node/property /method and "find" a match if the text searched for is in the name of the item.
So if I have an FPGA DIO line configured as "MyBasicIO" and search for that text, it will not currently find any IO nodes for that item.
This is frustrating and time wasting if I want to find every instance of my setting a particular IO point.
So generally what I do is a search for an object of that type (for example, IO Node). Then it finds all IO Nodes, not just the IO Nodes for the item I'm interested in. So I have to manually scroll through the list to see which ones are for the point I'm interested in and which are for other points.
I would like to see an option or VI that save / load the state of a VI and there SubVI's at a certain time (all controls I guess).
In the development of measurement software it is important, in terms of reproducibility of measurement results, to implement an option that save all scalable objects at a certain time (device settings also program settings) which depending a measurement.
Save program settings:
I know there is a way to do this by calling the VI reference and get the control values with property node and save them. But I don't think that's an accurate way because you have to manually do this with every SubVI's reference if you won’t to save them too.
Btw: in LabVIEW NXG, which I really like, it seems no way to do this because there is no 'Get Control' property node?!
- two VI's which save/load all scalable program settings to/from file (hopefully in the standard data save VI Palette)
which has been declined in 2015 for too low priority reason, but since it is still annoying now (e.g. with LV 2018), especially when using VI server (dynamic VI calls, UI elements manipulation, VI Scripting...), I think NI should reconsider it.
The Tree- Control and the Multicolumn Listbox support the presentation of a Symbols per row. But there are a lot of cases where there is needed more than one symbol per row. One very common scenario is the display of various states (Calculation completed: Checkmark; Results written to file: Checkmark; Assigned Application to open file: App-Icon...). NI does this already in the "Example Finder" window, so it is obvious there is a need for this feature.
I think it is a good practice to hold a pool of symbols, attached to the control, like NI does currently with the Trees and MCLBs. And for performance reasons there could still be the possibility to determine the columns to be capable to display symbols.
So from the LabVIEW programmers point of view there could be added the following properties / methods:
Symbol-Displayable Colums (property, read/write), (1D Array I32): Gets or Sets the indices of colums, which can show symbols and reserve space when the property "Visible Items->Symbols Visible" is set to true
Active Symbol- Column (property, read/write), (I32): Gets or Sets the Column-No which has focus for the next "Item Symbols"-property operation.
Set Column- Symbols (method, takes an I32 as Index for the Column, takes a 1D-Array of I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by setting the Property "Item Symbols".
Get Column- Symbols (method, takes an I32 as Index for the Column, returns a 1D-Array of I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by reading the Property "Item Symbols".
This should provide compatibility to the current handling of symbols since the property "Symbol-Displayable Colums" defaults to , so if "Item Symbols" is read or written to, it is meant to use the first column, which is status quo.
It would be useful to have something similar to C#'s LINQ in LabVIEW. Basically a way to "query" array of clusters/objects (and for some nodes even array of strings/numbers/whatever) without needing to use loops. I imagine nodes similar to invoke nodes, something like the below examples:
If one wired an array of clusters one should be able to choose from the elements in the cluster, like an Unbundle By Name node. For the Where node one should subsequently be able to select how to filter based on the data type of the selected element. For example: Equals, Greater Than, Less Than, Greater or Equal to, In Range, etc. for numbers. Equals, Contains, Starts With, Ends With, etc. for strings.
i think it would be useful to have one VI which can check path constants whether they contains invalid characters or not.
A lot of VIs doing some file operations returns errors if the file contains invalid characters but it should be checked before calling the VI with the file operations.
I found the `Is Name Multiplatform VI` which can check it, but it is hard to find that this VI will solve this question, accepts strings as input instead of paths, and also it has a lot of unnecessary in and outputs.
I think it would be would be more useful if there would be a simple VI with just one path input and one boolean output to check the path against the current platform.
given certain circumstances, the auto-incremental function for labels may lead to entirely different meanings. maybe sticking a non-printable character or a delimiter next to autonumber can solve this?
for instance, delimiter "- " in this case would make it even worse, but a non-printable character maybe...
This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.
Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.
The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library.
I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).
C++ and C# default everything to private unless you declare public; I think that's true in most text languages.
But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.
In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.
* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.
** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.
I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire. I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal. I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:
1. Wire this specific VIM on error wires most often
2. Likely don't want the VI to stall in the event of an error
3. Would prefer to see that error propagated as quickly as possible like most other VIs do