While replacing the Property nodes with Invoke node, Call by Reference, Start Asynchronous call and Wait on Asynchronus call, the primitives are shifting the origin disturbing the wires. So a cleanup is reaquired all the time whenever the items are replaced. It would be very helpful and infact time saving if this is corrected.
Place a Property Node in BD with the Error in and Out connected
Replace the Porperty Node with an Invoke Node
Repeat the same with other primitives
The same behaviour is not found when the Call by Reference, Start Asynchronous call and Wait on Asynchronus call primitives are replaced with one another.
for a very long period in a graph, it's be difficult to analyse the period and if the signal depend of meteo evenement, we don't have the time. I purpose to have the possibility that have the time in a graph in a date and clock.
We use Ctrl+E all the time to toggle views between the FP and BD.
Now I use single 21:9 widescreen monitor with FP on 1 side and BD on other.
It would be great to have a keyboard shortcut to show the Project explorer.
We all know the limitation that the "Data Operations"-->"Make Current Value Default" operation when right clicking controls is limited to edit-time only.
I often find myself writing code to save the last value that a user has entered in some sort of ini file (ini, xml, .dat, etc...) so that the next time the code starts up, the last values are reloaded to those controls. I have written some generic code that handles this functionality by wiring in control references. It then monitors those controls for changes and it saves the values to "VI Name"+"_Last.ini". Upon startup it loads the last values from that .ini file. The two attached VI's show this functionality. One VI is a Daemon that spawns the main process asynchronously so that the coder doesn't have to handle it themselves.
It would be nice if this could be handled intrinsically in LabVIEW. What I'm envisioning is a checkbox for every control that, if checked, would function similarly to how the above code works: it would save the control value in a .ini file associated with the owning VI. Since this is built-in it should also have accompanying properties for the control property node so that it could be accessed pragmatically and fired programmatically with the "Value Signaling" property. That would be awesome!
Today, if you right-click and select Clear Chart, on a waveform chart with absolute time on x-axis, it will reset its time also. This means that if your LabVIEW loop started adding to a waveform chart once a minute two days ago, Clearing the chart will make the time restart back two days ago, even though you are adding new data now, not two days ago. I wish NI would implement this feature in the next version.
VI hierarchy should allow hiding shared variables (just like it can hide type defs, globals, etc...). Using hierarchy view for any project with comact I/O compact RIO etc... is not practical since all those shared I/O nodes hide the useful interconnection information.
When deploying a CAN db, an alias needs to be created to access the database. The writeup is deeply buried in 4-538 of the manual (1200 pages).
An example with a simple switch between the dev & exe should be added to help save time and trouble. Or simply add the functionality to an existing example.
In many cases where I use file path constant instead of control. For selecting a path either we can right click and select browse for path or paste a copied path into the constant.
So it would be a nice and handy option to have a browse button along with the constant as the control has. This button won't respond when the code is executing or while the BD is in run mode similar to the other Enum/Ring constants. This button can be enabled or disabled or made always to be enabled or whatever may be the best approach. This button may be disabled when "invalid path" is selected.
I have modified the Path constant suggestion and now I feel its not going to take more space.
Mouse turns to select pointed when hovering over the button.
Upon clicking the button the browse window appears
Digital controls on the front panel can be set to coerce user-entered values to specified minimum and maximum values using a property panel. This is very convenient. However, there's no obvious visual indication that this property has been modified from "Use Default Limits". A colleague inherited a SubVI where some front panel control values were being coerced through code on the block diagram. What he didn't know was that the control properties were also set to coerce, and to different values. It took him a while to figure out what was going on.
What if block diagram terminals had some visual indication that their control no longer has the "Use Default Limits" property set? For example, see attached sketch.
As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.
So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.
So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.
I think that will be useful to have acces programmatically at Ni-Visa Driver Wizard
to search all connected device and to have as output a list with all connected device with PID and VID.
And if you whant to be possible to create a driver for a specific pheriferal from this list.
I have a few front panel elements that I want to group.
As LV is a visual programming language, I expected to be able to just draw an array frame around the elements.
This is not possible with the "array constant" and I could not find anything else that does this.
I can't move elements into an array frame either.
I had to create the array and wire each element seperately.
This is a tedious task and the result is hard to maintain.
See attached image below.
Drawing a frame around elements or the possibility to place them into a frame would be a great thing.
[admin edit: Adding screenshot from thread below]
After spending time building a type def, it's so frustrating to click "Make Type Def" and lose all of the label format. I then have to spend time unhiding and repositioning the labels. Any chance that the "Make Type Def" function can leave the labels untouched?
I recently found out that LabVIEW uses the Wichmann-Hill (1984) random number generator.
...which in some fields is completely unacceptable for not being random enough (cycle length of 6.9536e12?)
A much better (and arguably a much more currently standard one) would be Mersenne Twister (cycle length of 2e19937−1).
"In Range and Coerce" function should have swap terminal option. The upper and lower limit shall get swaped.
So recently I learned of another feature that the In Place Element structure has, that the native functions it represents doesn't. The IPE structure support splitting arrays, and it can split multidimension arrays like 2D and 3D arrays. In doing so you can also specify the dimension that it can be split along by right clicking and choosing Split Dimension. So is there a reason why the native Split 1D array function can be made into the Split Array function with the same features as the IPE?
Attached is a snippet showing the current method of splitting an array with IPE and the primative for a 2D array.
I often find myself switching betrween different projects and their windows get very cluttered and it's difficult to discern a VI in one project from a VI in another.
For example, if I have Project A with A_Main.vi, A_sub1.vi and A_sub2.vi open, and then I close the project, the next time I open the project I would like all 4 windows (the project, the Main and both subVIs) to open as well. If one project has 15 open VIs and another has 25 open VIs, the screen can get really cluttered. If I could open and close projects and have LabVIEW put me back right where I was when I closed them, this would be immensely helpful.