I have wasted days weeks of my life tracking down why dependencies are loaded in LabVIEW.
This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.
In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.
It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.
It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.
For example, the node would return a value of:
1 byte when fed a U8 wire
2 bytes when fed a U16
4 bytes when fed a I32
8 bytes when fed a DBL
800 bytes when fed a 1D array that contains 100 DBL elements
9 bytes when fed a cluster that contains a DBL and a U8
9 bytes when fed an object that contains a DBL and a U8
18 bytes when fed an object that contains two other objects that occupy 9 bytes each
and so on
Notes
The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.
It takes me too much time recognizing to which class and library this opened VI is belonging to. This is espacially the case when working with LVOOP, having the same VI in different classes.
A subtle improvement would be to have bold colons or 1.5x space between colons and path components in order to improve readability.
By default, overrides of interface methods with the default dynamic dispatch connector pane (object in/out and error in/out) look like this:
This means that the default override of interface methods do nothing EXCEPT DROP INCOMING ERRORS, which is bug territory imo. Ideally, they would be scripted to look something like this:
Yes, I know I probably can mess with the project provider to get this. No, I don't want to have to do that! 🙂
It seems that if you have a VI (or function) inside of a disabled frame of a Diagram Disable Structure or Conditional Disable Structure then the Find and Find All Instances features in LabVIEW will not report them. I'm OK if this is the default behavior, but maybe the Find dialog should have an option/checkbox to search inside of Disabled Structures.
Note: This is really important for cross-platform and embedded target development where there's lots of use of Disabled Structures.
I use a lot of user events and often define the user event references in a typedef cluster before actually writing the create/generate/destroy code. It would be really helpful if the Create User Event primitive would change its input datatype based on the output (i.e back propagate the datatype), much like the Variant To Data primitive.
The compare tool is fundamentally broken which is somewhat shocking considering that such a tool is essential to any sort of large scale or long term software development.
Attached is a basic LV 2023 example which illustrates some of the many flaws with the tool. If you compare "old version" and "new version" vi without including cosmetic changes, the tool shows 33 differences, most of which are incorrect.
This is a really basic thing, but it would be helpful if the qualified name (as seen in VI Properties) was enabled so it could be copy and pasted into documentation.
When I'm writing detailed documentation to tell other developers how the software works I often use the qualified name as opposed to VI name. For example "Send Creep Command.vi" doesn't tell the developer where to find it, but "Motion Control UI.lvlib:Motion Card 2 Data.lvclass:Send Creep Command.vi" does.
I would be happy with the string being enabled (so it can be selected and copied), or a button that copies the string into clipboard.
At least not at first. The compiler could inline each prototype and when called repetitively, use normal recursion. But that would be next level, and maybe not even desirable.
The scalar string input is simply not a stable input for this malleable VI. It will always result in infinite recursive compiled code. So, this should break the caller.
Of course, it should be perfectly legal to have a disabled type specialization case that calls the same prototype. As long as it's not actually compiled, that's perfectly valid:
Let's say I have a class with a few public VIs, and several private VIs and typedefs:
Assuming I'm not working on a VI within the class, If I'm using this class on a block diagram, I can only use the public VIs.
However, if I right-click on the class wire, and go to the auto-generated class palette, it shows everything. This can be absolutely overwhelming with larger classes. Why not scope this palette appropriately?
Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.
Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:
The current process of moving one of these elements:
Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
Wire to the new element, and deal with deleting the old wire
Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu
This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:
Context menu with a "Move Up" and "Move Down" action (not so elegant)
A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)
Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.
TL;DR: the idea is please make building as fast in new LabVIEWs post 2023 Q3 as old ones when you have a clear compiled object cache and when your file timestamps have changed.
LabVIEW 2023 Q3 has improved cache behavior for packed project libraries and applications.
The first build will populate the cache, and then the subsequent builds will be much faster.
Great! It is pretty easy to confirm this and it works! Unless...
1. File timestamps change - such as when you clean a directory and clone project files in your CI job
Git does not make file timestamps match "commit date" - when you clone fresh all the timestamps are now o'clock, when you change branches all the files that change are reset to now
2. The cache is cleared prior to the build - such as when you want a repeatable build unaffected by prior state so you set your CI jobs to clear it before each build
3. You are doing a "first build" on a new project - such as when you use a container or VM disk image to reset the entire environment to a clean state prior to your CI job
In all my testing, any of these conditions pretty strictly cause builds to be slower in LabVIEW 2023 Q3 than in earlier versions: with a clear cache by typically ~60%, with new timestamps and a persisted cache depends on how much of the code has new timestamps.
In other words, I expect most everyone using CI will find building slower in 2023 Q3+ than later versions. So, the idea is: whatever optimizations were done, include an option to revert to the old behavior - build spec, config ini, editor option, whatever.
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?
Similar to Visible items>Radix right-click menu it would be highly beneficial to have the same possibility for showing (and switching) of Representation.
Many common functions include a "found" or "exists" output. Examples include:
Get Variant Attribute
Element of Set?
Config file VIs (Read Key, Write Key, Get Key Names, etc)
Chek if File or Folder Exists
Why then does Look In Map provide an inverted ("not found") output? Wouldn't it be better if it was consistent with other similar functions??
This is most frustrating when replacing existing code using variant attribute lookups with equivalent maps. "Look In Map" is pin compatible with "Get Variant Attribute" except for that one inverted output! This has caught me out on more than one occasion...
In LabVIEW project file XML some information are generated by LabVIEW. For example:
Dependencies
PersistantID
FPGA stuff
...
These information should not be commited to source code control system and having them within the LabVIEW project file makes it very painful to maintain a clean GIT history.
It could be very convenient to store these information into a separated file with a specific file extension so that we can easily ignore with .gitignore file.
