Nowhere in the Help for the Initialize Array function is it indicated that this is perfectly fine:
Unfortunately this situation could result from a Ctrl-B operation deleting a broken wire to the "dimension" input, and this could remain undetected for a while (and difficult to debug).
Since an empty array can be generated in other simpler way (for instance creating a constant), I am arguing that this "feature" of the function is more harmful than it is useful and should be replaced by a Mandatory Dimension Size input.
The Drag and Drop event Drop has an element named "Available Data Names". This is a needleslly very long element name and wastes a lot of BD space (the whole vertical area can't be used for a case structure, for example).
Something like simply "Data" would be enough..
I didn't find this idea immediately, perhaps something similar has been posted already?
I would like to propose an extension to the Index Array function, to accept an array of numbers or booleans on the index input. The picture below illustrates the idea. The new Index Array function would replace the for loops in both cases, making for a neater and more readable diagram.
I have often the case, that i have to display an array of cluster. It takes a lot of space on the front panel to show all the captions of the cluster elements, cause they will be shown on each array element. A better solution would be, showing the captions or labels just on the top visible element.
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.
Say a 1% discount on the annual DSRL fee for each unresolved CAR per company/organisation.
If you think 1% is too much, please suggest a percentage that you think would be acceptable.
If NI did this it would really show how much they care about the quality of their products and also that they value the feedback of their users.
It would also be an incentive for users to report issues and for R&D to fix them.
LVOOP, "Choose Implementation" dialog box:
I'd love if the items appeared in alphabetical order.
At the moment it's pretty hard to find the desired implementation when you have something around 50 child classes.
Currently, you can drop a control on a queue control to change the inner type of that queue
There's no such shortcut for network streams
I would like this shortcut to be enabled. Also, maybe have the network streams optionally show the type in the control:
Most modern hardware oscilloscopes offer a feature to do a limit test by defining a limit band from a reverence signal by applying a plus and minus offset in the X and Y direction to a reference signal.
With the “Configure Mask and Limit Testing” Express VI it is possible to use a constant for upper and lower limit or define a table to act as upper and lower limit.
With the new function “Def. from Ref.” you can create the table content from a reverence signal.
Mostly it is not enough to add a constant value to the reverence signal in the Y-Direction.
An extreme example is a square waveform.
By simply adding a constant value to the Y-Direction you got no tolerance on the rising and falling edges for time base jitter.
Such a function would be nice to see in a future version of the “Configure Mask and Limit Testing” Express VI.
I am struggling with my Event Structure event list and the corresponding list of cases in the parallel consumer loop Case Structure.
Both have currently over 100 cases each and finding one or scrolling down to access the latest one has become painful due to the lack of a scrollbar in these lists.
For instance, here is the Event Structure list:
Same goes for the list of controls in a Local Variable (and other objects, I am sure).
There is no reason why such lists do not have a vertical scrollbar when that corresponding to a Enum do have a scrollbar:
Or is there?
Suggestion: All long pulldown lists should have a vertical scrollbar
Left shift registers (For Loop, While Loop) can be either initialized or not.
In general, the programmer knows what is needed for the correct behavior of the code, but code modification (say a broken wire followed by a Ctrl-B) can change this status:
If this last step is performed without remembering that the shift register needs to be initialized for the rest of the code to function properly, an insidious bug can result.
My suggestion: Let the user specify whether a shift register initialization is required or not (just like a VI connection can be specified)
The idea of overloading methods is wide spread in other languages. Labview already supports this in a way with polymorphic vis.
The code snippet below has 2 classes, parent and child
methods are described in the image below.
The underline idea is that parent can define 1 method (poly.vi) that can handle multiple inputs (polymorphic) but does not have to implement the functionality for all the input types (it just needs to know about them) and the child class can override poly.vi and the interface it want to implement.
Even though the code above is correct, Labview gives an error.
"Dynamic dispatch VIs cannot be members of polymorphic VIs."
I dont see why not, since dynamic distpacthing will still have an entry point for both classes (poly.vi) and choosing which polymorphic vi to use will be define at design time.
I was thinking it would be nice to call the DETT programmatically, in particular:
1) Start and stop a capture
2) Save and load a configuration
3) Save the log file to a user-defined location
(4) Perhaps even compare log files, although this bit can also be done using existing technology
As we get used to more multithreaded programming ideas, such as the actor framework, the DETT will become more important as debugging with independently executing clones is not straightforward. One such really nice feature for the AF has been created by niACS (https://decibel.ni.com/content/docs/DOC-44158).
The next step to me now is to allow it to be called, for example, during a unit test, so that I can measure performance. There is clearly a chicken and egg problem, because the code in which I call the event may preload the code under test, but I can easily imagine being able to set up and tear down the test using different VI's.
How will this help?
1) We can do something correctly, record the trace, save the file and then diff a unit test against the good file, checking that it still produces the same output (if we fire user events as niACS did with the AF). This might not be the best way of unit testing (we ideally develop the test before the code, a la Test Driven Development) but we also should be allowed perhaps to look inside the process (white box testing) to see if more calls are used, say, than the last time the code was run.
2) We can create performance benchmarks for code with tests that are easily re-run. Sure, we ideally should use the same machine with no more software than the last time the test was run, But we can also
a) See variation across different machines, platforms, etc.
b) Assess code smells at a quantitative level
c) Assess upgrades across versions of Labview
I find myself wiring errors out of the loop using auto-indexing and then immediately using a merge errors on the array of errors. With the addition of the Loop Terminals for concatenating arrays and conditional arrays, please add one on error wire terminals that can do the merge errors in one step.
For Example, current implementation:
What I would like to have but would do the same thing in one step:
I faced to delete multiple elements form the array which is having 20 steps.
if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.
Want to have graph display a certain scale unless values go outside scale min or max and then do autoscale but only in direction which scale bounds were crossed.
Normally want graph to display X scale 0 to 10 to display to user:
If set same graph to autoscale would get the following graph that user could interpret as values are swinging all over the place but this could just be noise and I do not want to display this format to user:
So I want a solution that incorporates manual scale and autoscale by autoscaling only after scale limit is exceeded. Asume get a data point of 13 which is above the max scale range of 10, graph would do a single autoscale only in direction above 10 to change max to 13.
Would be Graph Scales property. Option disabled if Autoscale was selected.
I know can use property nodes to programatically do this in my program but it is much more involved having to constantly check to see if values have gone outside range and then issue a single Autoscale.