This would be a method on a VI that puts all properties for all controls and decorations back where they were when the panel was saved including moving positions, sizing, making visible controls
visible and hiding invisible ones, etc. as well as sizing and scrolling
the panel to its saved origin. There's "Revert VI", but I don't want to unload the VI -- the VI might be running when I want to call this method. Indeed, most often I would want the VI to call this method on itself. This is a method that needs to work in the runtime engine.
The goal is to be able to restore an interface to some known starting position before allowing various plugins/3rd party VIs to modify it, and to be able to repeat that cycle. Since it is impossible to know all the things that those third party VIs might change, a single "reload the panel from disk" method would help a lot.
Curently, when we use the Open VI Reference node, there is a numeric "options" input for specifying how to open the reference. For example, 0x01 for "record modifications", 0x02 for "open templates for editing", and so on.
To my best knowledge, the theory here is that is makes it "easy" to combine options, e.g. 0x03 to "record modifications" and "open templates for editing". The problem I have with this method is that 90% of the time I cannot remember the number to go with the option(s) that I want - I end up opening Context Help->Detailed Help, etc.
An alternative way would be to copy the VISA Flush Buffer node: use a ring control for each of this input. that way you could just select the "record modifications" option, or, if you need multiple options, combine them with a OR or compound logic node (or even, take an array of these options as the input, allowing 0 or more options to be select). This to be would be much easier as we wouldnt have to keep on going to the context help.
While working with a complex configuration application, I found myself heavily utilizing in place operations. Throughout the process of contstructing the code, I found myself commonly having to create an In Place Indexing structure (pictured below). I thought it would be really nice if you could mark an auto-indexed array for in place operation. As always, I am open to suggestions, but thought this might be a nice creature feature:
Currently, when you use the Reshape Array primitive, if new elements are created, they are filled with the default data of the datatype. Alternatively, allow a terminal that defines the fill value.
A longstanding issue with the "active plot" property is that is throws an error if fewer plots currently exist. Conversely, if we wire data containing more plots, the graph automatically adapts to that.
The main problem with this is that the order of operations matters. We need to write the value first, followed by the active plot properties. Many times we already know what kind of plots we want (color, name, etc.), even if one of the plots is only added in a later step or the terminal is written a nanosecond later due to code scheduling. Workarounds mean excessive sequentialization because we need to enforce strict order: (1) write data (2) update plot properties.
The current behavior is annoying, and there are many forum examples where that was the cause of the problem (example).
Two suggestions can address this:
(1) if an active plot property is written, and that plot does not exist yet datawise, it should be created automatically and the node returns without error. (Of course all other missing plots up to that number need to be created too, they can have default properties).
(2) Maybe there should also be a property for "number of plots" than can be written to define the number of plots.
It would be really nice is the IDE, and my program were not the same process.
Especially when dealing with 3rd party DLL's, it would really be nice if a bad pointer or misallocated buffer in a DLL didn't crash my whole development environment, but instead just took out the running program.
LabVIEW should have a VI which accepts a path to a class and returns a 1D array of the names of all the classes it inherits from, similar to how the Call Chain primitive returns an array of the calling VIs. It should do this without loading it into memory (which can be very expensive).
This can be useful for determining whether a class inherits from another class without having to load it. See this thread for an example.
Additionally, there should probably also be a similar VI which accepts the class instead of a path, just for symmetry.
I’ve already put up ideas, about 7 weeks ago, for four development boards that could be LabVIEW targets:
1) LabVIEW for Raspberry Pi (current kudos 139)
2) LabVIEW for Arduino Due (current kudos 74)
3) LabVIEW for BeagleBoard (current kudos 49)
4) LabVIEW for LM3S9D96 Development Kit (current kudos 15)
I wanted to leave it at that to gauge LabVIEW community/user interest, however an exciting new board has just been introduced, which is too good to leave out. It’s the Texas Instruments Stellaris Launchpad.
It’s very attractive for three main reasons:
1) It is very easy to get LabVIEW Embedded for ARM to target this board (a Tier 1 port)
2) The microcontroller is powerful with many useful on-chip peripherals
3) The price is extraordinarily low.
The Stellaris Launchpad features are:
ARM Cortex M4 with floating point unit running at 80 MHz (100 MIPS)
256 KB flash
32 KB SRAM
USB device port (separate from the USB for programming/debugging)
8 UARTS
4 I2C
4 SSI/SPI
12 x 12 bit A/D channels
2 analog comparators
16 digital comparators
Up to 49 GPIO
and more
The most interesting feature is that it costs $4.99 including postage. Yep, just under five dollars! Including postage! I’ve already ordered two!
The Texas Instruments Stellaris Launchpad can be programmed using the free Code Composer Studio in C/C++ or the free Arduino IDE using Energia from github. Both great ways to program. It just needs LabVIEW as the third exciting programming option.
Wouldn’t it be great to program the Stellaris Launchpad in LabVIEW?
A common need that comes up is the ability to randomize an array, yet there is no primitive that handles this. There are of course a fewhomebrew solutions, but it's tough to beat a primitive that accepts any dimension or datatype in terms of syntax and execution speed!
Note: This is not an Idea to create an array of random numbers, it only deals with taking an already initialized array and scrambling the locations of the elements.
I never really understood why the default count value for Read From Binary File was 1. 95 times out of 100 I am reading the whole file (-1), the other times I am reading a fixed chunk size which is certainly not equal to 1 (and in this case I expect to wire a value). The 'default' or natural behavior is really to read one byte/word/long at a time? That is about as inefficient as it gets.
I propose that the Execution section of the VI property node include ALL of the options in the Execution pane of the VI Properties dialog.
This would allow programmatic changing of variables like Auto handle menus at launch that I would like to change programmatically across an entire project at once (since I didn't take the time to do so one-by-one as I developed my application). These should probably be False by default anyway , as commented here.
I currently have a program that sets Allow Debugging and Automatic Error Handling to True or False depending on whether I am developing or releasing software. I would also like to add Auto handle menus at launch to that list.
If you click on the calendar button of a date & time control all updates of the user interface and all functions that happen to run in the user interface thread are halted/blocked.
This is, as far as I know, because the calendar is really an ActiveX control...We need a native control that does not show such behaviour (especially considering the fact that things like the run method is running in the user interface thread...).
It is quite ugly that such a fundamental control as the date & time control depends on code that will block the GUI.
One other area where LabVIEW ignores extended precision is wire values in debug mode. To illustrate what I am talking about, consider this snapshot of a debugging session:
The result of my modified Bessel calculation (that reminds me I haven't suggested to implement special function calculation in extended mode...) returns a perfectly valid extended precision number, such as 5.03E+418, but LabVIEW doesn't recognise this as a valid value and returns an "Inf" value (which would be the correct reaction if the wire could only display double precision floating point values).
This wire is connected to the logarithm primitive, which happens to be polymorphic and hence accepts the extended type. The result is the correct logarithm of 5.03E+418, i.e. 964.15.
On the face of it though, it appears that the output of my VI is +Inf, and that LV went wahoo and estimated an arbitrary value of log(Inf)...
My code actually stores such values in shift registers, so when I debug problems with the code, I have 3 or 4 wires carrying an "Inf" value, which, when I am trying to understand the reason of overflow problem, is not exactly helpful.
Suggestion: display Extended Precision wire values correctly in debug mode.
Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to
save to disk
read from disk
display
See:
This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!
A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.
We could add a way, for example a parameter key in INI file of LabVIEW.exe, in order to run LabVIEW.exe silently, so without the splash screen and the getting started window, like a background process.
Example use case:
When you execute a build specification thanks to LabVIEWCLI (operation name: ExecuteBuildSpec, https://www.ni.com/docs/en-US/bundle/labview/page/predefined-command-line-operations.html), it runs LabVIEW.exe to complete the request. LabVIEW.exe is opened with the splashcreen and the main window. It's terrible, I want to use LabVIEWCLI to do some operation programmatically and silently (background mode) from my code/app.
There are a lot of issues that arise because you can't register for events using control references when VI's front panel is not open. Here is a practical example that illustrates a bunch of limitations:
We have a multi-window application, and most of the windows can be opened/closed on demand.
We want to be able to handle common user interactions on all windows--in particular, we have common right-click operations for all indicators on all windows.
We would like to have a single daemon that registers all indicators for right-click events
Ideally, each window VI would send it a list of applicable control refnums on initialization, and it would handle registering for events from all
(This will, of course, require some redundant registration, as you cannot append items in a registration--but I can understand why...)
The problem, however, is that we can't register for such FP events when the FP is not open. So that means we have to have an "Open FP" state in our simple state machines (if only there was an FP.Open event! but that's a separate idea...), and register for these events on first call in that state.
Plus, since we want a single event case to handle all those indicator refnums, we would have to reregister all refnums each time a new window is opened (as mentioned above). But that means if you registered events for a window, then closed it, then opened a different window...when you open the second window, the re-registration of events from the first will throw an error because its FP is no longer open.
Confusing, yes. Hope that gets the point across.
Our workaround is that we have a separate daemon instance dedicated to each window. Not ideal, but works for now. But there are other similar problems that have required more complicated workarounds. Would be best if the root cause were addressed.
One of the biggest problems I have with annotations is that they are always placed with a yellow color. This is fine on black backgrounds, but on white / light colours the annotations are almost invisible. The only way around this right now is to continually poll the Annotation List propertyand try to determine if a new annotation has been added and then set its color accordingly.
A *WAY* better solution would be to either be able to set the defaults ahead of time, or, as the title of this idea suggests, add an event called Annotation Change or something that could allow us to determine if somebody had added an annotation / changed an existing annotation, etc. This way we could catch the newly created, practically invisible, annotation creation and set it to a more reasonable colour, etc.
In one of my recent projects I had to call a custom made .NET Assembly in LabVIEW which provides several events to register for. As .NET support is generally available (within known limitations), there is but one unknown "feature" that caused big trouble to me and everybody who might want to do something similar:
#please notice that whenever I now talk about anything in .NET, I see the things from the view of C#
Let me give an example code in C# to demonstrate the implementation for use in LabVIEW:
using System; using System.Collections; using System.Collections.Generic; using System.Text
namespace SUPERSPECIALPROJECT { // delegates public delegate void myDelegate( object sender, myEventArgs e );
// the event args (plain example) public class myEventArgs : EventArgs {
// some member variable private string m_strMessage;
// the constructor myEventArgs(){}
// a public property public string Message { get{ return m_strMessage; } set{ m_strMessage = value; } } }
// the public object I want to use in LabVIEW public class myLVObject { // create the event for registration in LabVIEW public event onMessageChanged myDelegate;
/* * I don't want to write any more here, but basically the event above is * fired whenever my asynchronous process feels like it. */ } }
Okay, so now I...
- Build the .NET assembly
- Create an instance of myLVObject in LabVIEW
- Wire the class wire to the Register Event Callback and select the 'onMessageChanged' event.
- Create the callback VI and access the data of 'myEventArgs' within the property 'e', no problems.
So far so good.
However, even though my .NET object runs fine in C# (Yes, I tested it in C# first), LabVIEW does never ever run the callback VI. The reasons were hard to find and I actually had to call NI directly for this. We did some tests and I finally got a confirmation on my assumptions:
1) The asynchronous process does correctly fire the event, but for some reason the developer does not send any 'sender' (the object is just NULL). -> LabVIEW will not execute the callback VI 2) The asynchronous process does correctly fire the event, but for some reason a value of my implementation for 'eventArgs' is NULL (let's say the parameter 'm_strMessage' is NULL). -> LabVIEW will not execute the callback VI
As I have no access to the asynchronous process and have no chance that it will ever be updated for me, I wrote a wrapper that provides my own set of events that replace all null-values by empty values. (like m_strMessage will be "" instead of NULL) -> Finally LabVIEW will accept the love of my events
This behavior is confirmed by NI. The actual event is somehow compared to the callback VI, which will only be executed if the types match. NULL- Variables are not recognized and to LabVIEW it seems as a completely different data type. This will not be changed for future versions unless I get it through the Idea Exchange
The most annoying thing is, if there is any NULL variable somewhere within the scope of either sender or e, the event will fail executing in LabVIEW and LabVIEW only. I know NULL is not a very good practice, but there is no way to replace NULL if you don't have access to the sources (as in my case). The current solution by using a wrapper does work, but takes much time to implement and it has to be maintained.
Finally for anybody who kept reading so far:
I don't see any reason why this behavior could not be changed (LabVIEW does currently just do nothing) and therefore suggest two enhancements:
1) Allow NULL-Variables (auto-replace with empty variables) <-- might be a hard challenge 2) Warn me whenever a callback VI does not match the type of the connected event, as it is currently almost impossible to track properly.
The latter one might be the easiest to implement and would already cover issues with 1) partially. Anyways, we definitely need a better way to catch such issues in the future.
, as commented 
